在运维ref="/tag/2020/" style="color:#EB6E00;font-weight:bold;">Kubernetes集群时，最头疼的不是部署服务，而是搞不清资源到底跑成啥样了。CPU突然飙高？内存莫名其妙被吃光？Pod频繁重启却找不到原因？这时候，一个直观的Grafana看板能救你于水火。
为什么非要用Grafana看K8s？
命令行虽然强大，但kubectl top node、describe pod这些命令来回敲，信息零散，没法一眼看出趋势。就像开车只靠后视镜和仪表盘的小灯，不如直接装个大屏导航来得痛快。Grafana就是这个“大屏”——把Prometheus采集到的指标可视化，节点负载、Pod状态、网络流量全摊开看。
怎么搭一套基础看板？
先确保你的集群里已经部署了Prometheus，用来抓取Kubernetes的各项指标。然后在Grafana里添加Prometheus为数据源，地址通常就是http://prometheus-server.default.svc:9090（根据实际服务名调整）。
导入现成的看板模板是最省事的。ID为1860的官方Dashboard “Kubernetes / Compute Resources / Cluster” 能展示整个集群的CPU和内存使用率趋势。另一个常用的是ID 10857，“Kubernetes Pod Metrics”，专门盯着Pod的资源消耗。
apiVersion: v1
kind: ConfigMap
metadata:
name: grafana-dashboards
namespace: monitoring
data:
k8s-cluster.json: |
{
"__inputs": [
{
"name": "DS_PROMETHEUS",
"type": "datasource",
"pluginId": "prometheus"
}
],
"title": "K8s Cluster Overview",
"panels": [...]
}自定义一个Pod异常告警看板
有次上线新版本，某个服务的Pod一直CrashLoopBackOff，但日志看不出问题。后来我在Grafana加了个面板，用下面这个查询语句：
sum by (namespace, pod) (rate(kube_pod_container_status_restarts_total{job="kube-state-metrics"}[5m])) > 0这一下就筛出过去5分钟内重启过的Pod，配合时间轴拖动，立马锁定是配置文件挂载失败导致循环崩溃。修完之后，那个红色的尖峰也平了下去，看着特别解压。
别忘了给团队共享
一个人看得明白不算完，把关键看板分享给开发和测试同事，大家查问题就有了共同语言。比如后端说“接口变慢”，运维可以直接打开网络延迟面板，一看是不是Node之间带宽打满了，还是Ingress控制器扛不住。沟通成本一下就降下来了。
现在我们组每天晨会前都会扫一眼Grafana大屏，谁也不用再问“服务稳不稳”，眼睛一瞄就知道有没有异常波动。监控不再是事后追责的工具，变成了日常协作的一部分。