Grafana 在 Kubernetes 监控体系中的角色不是数据采集器，而是把 Prometheus 已经抓取到的时间序列数据转换为趋势图、单值面板和表格。要让面板真正反映集群健康状态，先要理清两类指标：一类来自 kubelet 内置的 cAdvisor，面向容器与节点的 CPU、内存、文件系统、网络等运行指标；另一类来自 kube-state-metrics，面向 Deployment、StatefulSet、Pod、Node 等资源对象的编排状态，例如期望副本数与当前副本数的差异。只有同时接入这两类数据，面板才不会出现只看到资源消耗却看不到 Pod 频繁重启的盲区。
监控数据来源：Prometheus 如何抓取 Kubernetes 指标
Prometheus 在 Kubernetes 环境中的抓取依赖服务发现机制。通过 kubernetes_sd_configs 可以自动发现 Node、Pod、Endpoints 和 Service，无需每次扩容后手动修改配置。以抓取 kubelet 为例，kubelet 默认在 10250 端口暴露指标接口，但该接口需要 TLS 认证，因此通常使用 role: node 并通过 HTTPS 访问。以下配置展示了在 prometheus.yml 中添加 kubelet 与 cAdvisor 的抓取任务：
scrape_configs:
- job_name: "kubernetes-kubelet"
scheme: https
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
insecure_skip_verify: true
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
kubernetes_sd_configs:
- role: node
relabel_configs:
- action: labelmap
regex: __meta_kubernetes_node_label_(.+)
- source_labels: [__meta_kubernetes_node_name]
target_label: node
这段配置中，insecure_skip_verify 仅建议在测试环境使用，生产环境应正确挂载 CA 证书。kubelet 暴露的 /metrics/cadvisor 路径包含容器级数据，而 /metrics 主要提供 kubelet 自身状态，两者可以分别建立抓取任务。对于 kube-state-metrics，则需要通过 Service 暴露的 8080 端口抓取，并使用 role: endpoints 或 role: pod 来匹配标签，确保在 Deployment 滚动更新时仍然能持续采集。
另一个常见问题是时序数据量过大。如果集群规模超过数百节点，建议设置 scrape_interval: 30s 并开启 scrape_timeout: 20s，同时利用 Prometheus 的 relabel_configs 丢弃不需要的指标前缀，避免存储空间被低价值数据占满。Prometheus 的存储保留时间也需要规划，通常生产数据保留 15 天即可，历史趋势可以交给 Thanos 或 VictoriaMetrics 这类长期存储方案。
Grafana 数据源与 Dashboard 的落地配置
Grafana 连接 Prometheus 通常使用 Server 端访问方式，因为容器网络下 Grafana 与 Prometheus 往往位于同一命名空间或可路由网段。数据源地址建议使用 Kubernetes Service 的 DNS 名称，例如 http://prometheus-server.monitoring.svc:9090。如果 Prometheus 启用了鉴权，可以在数据源配置中附加 HTTP Header，不建议把 token 直接拼在 URL 中。以下是一个使用 Grafana Provisioning 自动创建数据源的示例：
apiVersion: 1
datasources:
- name: Prometheus
type: prometheus
access: proxy
url: http://prometheus-server.monitoring.svc:9090
isDefault: true
editable: false
同时，Dashboard 也可以通过 Provisioning 自动加载。将 JSON 面板文件放入 /etc/grafana/provisioning/dashboards 目录，Grafana 启动时会自动导入，避免手动导入后 Pod 重建导致面板丢失。生产环境中更推荐使用 ConfigMap 挂载 Dashboard JSON，并通过版本控制系统管理面板变更，这样每一次指标口径调整都有记录可查。
在权限控制方面，建议为只读用户创建独立的 Grafana Organization 或使用 Viewer 角色，防止误操作修改面板。对于多个集群的监控，可以在一个 Grafana 中配置多个 Prometheus 数据源，并在每个面板顶部使用 datasource 变量切换，而不是为每个集群重复创建大量面板。
核心监控指标与 PromQL 查询设计
CPU 使用率是最基础的面板之一。容器 CPU 累计值需要先做 rate 计算，再按 Pod 聚合。下面这条 PromQL 计算每个 Pod 在 5 分钟内的 CPU 核心数使用率：
sum(rate(container_cpu_usage_seconds_total{namespace!="",pod!=""}[5m])) by (pod)
该表达式排除了 namespace 与 pod 为空的聚合行，避免把系统级 cgroup 也计入业务负载。如果要计算 CPU 百分比，需要除以节点可分配 CPU 或 Pod 的 request 值。更常见的做法是使用 namespace 与 node 两重聚合，分别查看命名空间维度和节点维度。
内存方面，container_memory_working_set_bytes 比 container_memory_usage_bytes 更接近实际 OOM 判定标准，因为它剔除了 inactive file cache 的影响。Pod 重启频率可以用 kube_pod_container_status_restarts_total 的增量来表示：
increase(kube_pod_container_status_restarts_total{namespace="production"}[1h])
当该值持续大于 0 时，说明对应容器在最近一小时发生了重启，需要结合日志进一步排查。此外，kube_deployment_status_replicas_available 与 kube_deployment_spec_replicas 的差值可用于判断 Deployment 是否完成滚动更新，若差值长时间不为 0，面板应置为红色并触发告警。
节点健康状况不能只看 CPU 和内存，还应该关注 kube_node_status_condition。该指标中 condition="Ready"、status="true" 时为 1，否则为 0。对全部节点的值求和并与节点总数比较，即可判断是否有节点 NotReady。文件系统使用率则可以抓取 node_filesystem_avail_bytes 与 node_filesystem_size_bytes 的比值，并排除 tmpfs 和 overlay 等不关心的挂载点。
面板布局与告警联动的最佳实践
一个高可用的 Kubernetes 监控面板不应把上百个图表堆叠在一起。建议按层级组织：第一行放集群总览，包括节点数、命名空间数、Pod 总数和告警数量；第二行放资源消耗 TopN，例如 CPU 占用前 10 的 Pod 和内存占用前 10 的 Pod；第三行放控制面指标，如 API Server 请求延迟、etcd 领导者状态、调度器队列深度。这样值班人员打开面板后，能够快速定位是资源问题还是控制面问题。
告警规则应尽量写在与面板相同的数据源中，而不是依赖外部分散系统。Prometheus 的 rules.yml 中可以定义 alert 规则，并通过 Alertmanager 发送通知。面板上可以叠加 Alert 列表，把 ALERTS 指标用 Stat 或 Table 形式展示，方便直接看到当前活跃告警。阈值设置不能一刀切，例如测试环境 CPU 长期高于 80% 可能是常态，而生产环境超过 70% 就需要关注。
最后要养成定期检查面板数据完整性的习惯。Grafana 面板右上角如果频繁出现 No data，往往不是查询写错，而是 Prometheus 抓取目标失联或指标名称在版本升级后发生了变化。此时可以先在 Grafana 的 Explore 页面用 up{job="kubernetes-kubelet"} 检查抓取状态，再比对 kube-state-metrics 的版本兼容表。合理利用变量模板，例如将 namespace、pod 做成带 All 选项的下拉框，能显著减少重复面板数量，也便于不同团队按需过滤。
GrafanaKubernetes监控Prometheus修改时间：2026-08-25 21:19:40