简介：面向正在使用Kubernetes集群的运维与开发人员，提供了一整套基于Prometheus和Grafana的监控系统部署方案。压缩包内含三个YAML格式配置文件，总体积仅5KB，分别对应核心监控服务、可视化面板和节点指标采集组件的部署配置，构成完整的监控底座。整套配置轻量易用，适合初学者边部署边理解各组件协同工作方式，目前已有836人学习使用。资源细化到Prometheus服务参数、Grafana数据源与仪表盘接入，以及Node Exporter对主机负载、磁盘、网络等节点级指标的采集，并预留告警规则与Alertmanager通知扩展，可实时反映集群健康状态、帮助运维人员及时发现异常。读者可据此掌握自动发现机制、指标拉取、可视化面板构建等核心操作，搭建从节点到应用的完整监控链路，为生产环境监控提供一套可复用的基础模板。
1. kubernetes部署监控系统prometheus和grafana：三个YAML文件把集群盯起来
现成的监控方案很多，但在Kubernetes里搭Prometheus+Grafana，最怕的就是网上找一堆配置，一梭子apply下去，Pod起来了，Target却在界面上红成一片。这份资源的核心就三份YAML——prometheus.yaml、grafana.yaml、node-exporter.yaml，它们把从指标抓取到可视化展示的链路直接打通，属于那种「清单拿来就能跑」的类型。对正在给K8s集群做基础监控的运维或开发来说，它解决的是最现实的问题：Node节点和核心组件到底该怎么采、Grafana面板长什么样、告警规则去哪配，不用再从零拼装。
2. 为什么要用Deployment+Service方式部署：从组件分工看监控链路怎么闭合
2.1 监控拓扑：Prometheus负责采，Grafana负责画，node-exporter负责给
K8s集群里的监控不是装一个软件就完事，它是一条完整的采集链路。这条链路最前端是node-exporter，它以DaemonSet方式在每个节点上跑一个Pod，把节点的CPU、内存、磁盘、网络这类宿主机指标暴露成一个HTTP接口。中间端是Prometheus，它通过配置里的抓取任务（scrape config）定期去拉这些接口，把数据存进自己的时间序列数据库。最末端是Grafana，它把Prometheus当作数据源，用仪表盘把查询结果渲染成图表。
这份资源之所以实用，在于把三个组件拆成了三份独立的YAML，而不是揉进一个大文件里。prometheus.yaml负责核心服务，grafana.yaml负责展示层，node-exporter.yaml负责数据源头。这样做的好处是升级和排查时可以单独操作。比如node-exporter挂了，只会影响节点相关指标，不会拖垮整个监控服务；Prometheus的配置改动也只需要动它那一份文件再滚动重启。
2.2 三个YAML的资源类型设计：为什么不用Operator和Helm
现在社区里更流行用Prometheus Operator来部署监控体系，因为它把告警规则、ServiceMonitor这些概念做成了K8s CRD，用声明式方式管理，确实省心。但这三份YAML走的都是传统路线：Deployment加Service。这种选择不是落后，而是为了降低上手门槛。Operator本身需要额外安装CRD和控制器，概念上多出一层抽象，对于只是想快速看到监控数据的场景反而显得重。用原生Deployment，任何自带kubectl的环境中，执行kubectl apply -f就能拉起整套监控，不依赖额外的控制器资源。
Service的设计也要看明白。Prometheus和Grafana的Service都是ClusterIP类型，这意味着它们只能在集群内部访问。实际使用中，通常配合kubectl port-forward或者Ingress来暴露Grafana的Web界面。这种设计的考量是把监控系统默认内网化，避免直接把Prometheus的9090端口暴露到公网造成数据泄漏。
2.3 Prometheus配置拆解：scrape interval、retention time和热加载
prometheus.yaml里的核心是一个ConfigMap，里面写着prometheus.yml的主配置。这份配置里有两个参数最值得调：global.scrape_interval是抓取间隔，默认15s，如果集群规模较大或者指标特别多，可以改成30s来降低压力；retention time参数值得单独看看，如果没在启动命令里指定，会一直累积数据直到磁盘撑爆。在这个工程包里，启动命令通常长这样：
args: - --config.file=/etc/prometheus/prometheus.yml - --storage.tsdb.path=/prometheus - --storage.tsdb.retention.time=15d - --web.enable-lifecycle这里的retention.time=15d表示数据只保留15天，超过的数据自动清理，防止磁盘被时间序列数据填满。web.enable-lifecycle这个参数一定要加，它允许通过HTTP接口热加载Prometheus配置，不用重启进程：执行curl -X POST http://localhost:9090/-/reload就能生效。后面接Target任务时，改完配置靠这个接口就能即时生效，不用反复重启Pod。
再看抓取任务的配置：
scrape_configs: - job_name: kubernetes-nodes kubernetes_sd_configs: - role: node relabel_configs: - source_labels: [__address__] regex: '(.*):10250' replacement: '${1}:9100' target_label: __address__这里的kubernetes_sd_configs是Prometheus的K8s服务发现机制，role: node告诉它通过K8s API动态发现所有节点。后面的relabel_configs做了一个地址替换：Kubelet的10250端口是采集Metrics用的，但node-exporter默认跑在9100端口，所以这里把抓取地址重写到9100。常见做法是这一步很多人会漏掉，结果Prometheus发现了节点，但抓不到数据。
3. 从三份YAML到可视化面板：部署步骤与参数调整实操
3.1 部署前的集群检查和命名空间规划
在apply任何YAML之前，先确认集群的基本状态。用kubectl get nodes检查所有节点是否Ready，这是前提条件。另外确认kubectl的上下文没错——很多人会把配置打到测试集群上，回头看监控数据全是空的才反应过来说打错环境了。建议在所有资源前面都指定命名空间，用kubectl create namespace monitor统一管理这三件套。
这份资源里的三份YAML需要按顺序应用，原因是依赖方向。先起node-exporter，让节点指标先有出口；再起Prometheus，它启动后马上能抓取到节点数据；最后再起Grafana，这时候配数据源就有真实数据可查了。如果一次性把三个文件全apply，由于K8s的调度机制，它们基本会同时启动，顺序问题并不致命，但首次启动时Grafana可能会因为Prometheus尚未就绪而报数据源连接失败，大概率需要手动在Grafana里重新保存一次数据源。
3.2 node-exporter部署：DaemonSet还是Deployment，区别在哪
打开node-exporter.yaml，关键点在于它的控制器类型。如果你的YAML里写的是Deployment，那要注意它可能只调度到其中一个节点上，无法覆盖整个集群。正确的做法是使用DaemonSet，确保每个节点上都跑一个副本。看清单里有没有这段：
apiVersion: apps/v1 kind: DaemonSet metadata: name: node-exporter namespace: monitor spec: selector: matchLabels: app: node-exporter template: metadata: labels: app: node-exporter spec: hostNetwork: truehostNetwork: true这个参数非常关键。它让Pod直接复用宿主机网络，而不是被NAT成独立IP。这样node-exporter监听在9100端口时，就是从宿主机视角暴露的端口，Prometheus通过节点IP加9100就能直接访问。如果不开hostNetwork，默认是每节点独立的Pod网络地址，抓取配置里的relabel逻辑可能对不上。这个参数很多教程版本里没有，部署完Prometheus的Targets里Node这项会有很多Down状态，原因就是网络模式不对。
3.3 Grafana部署：数据源配置和持久化卷声明
grafana.yaml里包含三块内容：一个Deployment跑Grafana服务，一个Service暴露3000端口，外加环境变量里的数据源配置。新版Grafana支持通过provisioning目录自动注入数据源，这是比手工在界面上点要可靠的做法，因为配置被写进了YAML里，重来一遍还是同样的结果。
来看看这部分的写法：
env: - name: GF_SECURITY_ADMIN_USER value: admin - name: GF_SECURITY_ADMIN_PASSWORD value: admin123 - name: GF_INSTALL_PLUGINS value: grafana-piechart-panel volumeMounts: - name: grafana-storage mountPath: /var/lib/grafana里面GF_INSTALL_PLUGINS是可选的，预装饼图插件这类可视化组件时用得到，如果你只用到基础图表，这段可以去掉。admin账号密码写在环境变量里，首次登录之后建议在Grafana界面里改掉。volumeMounts这段是持久化配置项，需要注意：如果只声明了volumeMounts而没有在spec.volumes里声明对应的持久化存储，那每次Pod重建，仪表盘和面板配置都会丢失。常见的方案是挂载一个pv或者使用云厂商的存储类，我这里一般会用emptyDir维持测试环境，生产则换成persistentVolumeClaim。
3.4 端口转发打通访问链路：kubectl port-forward的用法
三个组件都部署完成后，需要一种方式访问Grafana和Prometheus界面。如果集群没有Ingress控制器，最简单的验证方式就是端口转发：
kubectl port-forward -n monitor svc/grafana 3000:3000然后打开浏览器访问http://localhost:3000，用管理员账号登录，能看到Grafana的欢迎页。Prometheus同理，把service端口转发出来：
kubectl port-forward -n monitor svc/prometheus 9090:9090访问9090端口，在Status下拉菜单里选Targets，可以看到prometheus、node-exporter这些job的抓取状态，绿色的Up表示Endpoints可达，红色的Down则说明网络或配置有问题。这套验证动作的价值在于，它帮你区分问题出在Prometheus本身还是Grafana侧——Targets页面全绿，说明数据链路没问题，Grafana面板空白那就是数据源或查询语句的问题；Targets里有红色，那优先排查组件Pod的状态和网络策略。
3.5 面板配置：导入现成Dashboard ID和手写PromQL的区别
Grafana起来之后，接下来要解决面板问题。这份资源没有包含JSON格式的Dashboard文件，两种办法补齐：一种是在Grafana官网找社区分享的Dashboard ID，输入ID直接导入，社区里K8s集群监控常用的是315号和1860号；另一种是手动建面板，写PromQL查询语句。
手写PromQL需要点基础，比如查CPU使用率的语句是：
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)逻辑解释一下：node_cpu_seconds_total是node-exporter暴露的CPU累计时间指标，按mode标签区分为idle、user、system等不同状态。rate()函数计算的是5分钟内的每秒增长率，取mode="idle"的部分再乘以100，得到的是一段时间内CPU空闲的平均百分比，用100减去它才是CPU使用率。导社区面板的好处是这些查询语句别人都写好了，做出来的图表也多，省去自己造轮子的时间。第一次导入面板后，如果图表全是空的，多数情况是数据源类型没选对：Dashboard的变量里通常有个数据源选择器，要手动切换成你配置好的Prometheus数据源，这个问题在导入社区面板时非常常见。
4. 避坑实战：Prometheus部署中常见的五个坑，按现象到解决逐个拆
4.1 常驻坑位一：Targets页面显示Down，原因在RBAC权限缺失
现象：Prometheus配置的kubernetes_sd_configs是正确的，Targets里也能列出节点，但状态一直是Down。进入Prometheus的Targets页面，点开某个Down的节点，报错说连接是connection refused。
原因：Prometheus如果要在集群里做服务发现，需要访问Kubernetes API读取节点和Pod的信息。如果你的RBAC配置不允许这个操作，服务发现看到的列表可能是空的，或者访问被拒绝。connection refused的情况，多半是探活时连到了节点上的错误端口，由于RBAC没开，Prometheus无法正常运行它的service discovery，它拿到的节点列表不完整，或者配置里的relabel逻辑没法解析正确的endpoint。
解决：确认Prometheus的ServiceAccount有没有绑定合适的ClusterRole，通常需要读取nodes、services、endpoints、pods这些资源的权限。用下面这段内容检查：
kubectl get clusterrolebinding | grep prometheus kubectl describe clusterrolebinding prometheus-binding如果没有对应的binding，创建一个ClusterRole和ClusterRoleBinding，授予上述资源的get、list、watch权限。从那次之后，我每次部署Prometheus之前必做的一步，就是先把权限绑定和ServiceAccount提前创建好，顺序是权限优先于Prometheus本体，再也没因为RBAC问题折磨过Targets页面。
4.2 常驻坑位二：Grafana能登录但面板无数据，原因是数据源地址写错
现象：Grafana正常启动，登录后仪表盘也能打开，但图表全部没有数据，上方有红色的错误提示，说数据源连接失败。
原因：Grafana里配置的数据源URL写成了类似http://localhost:9090。这里的localhost指的是Grafana所在的容器，不是Prometheus的地址。它们如果不在同一个Pod网络空间，请求会直接超时。
解决：在Grafana的数据源配置里，URL要填写Prometheus Service的DNS名字加端口：http://prometheus.monitor.svc:9090。svc是Kubernetes集群内部DNS的固定后缀，prometheus是Service名称，monitor是它所在的命名空间。填这个地址可以跨命名空间访问Prometheus服务。如果grafana和prometheus在同一个命名空间，可以简写成http://prometheus:9090。这个问题是我见过最多翻车的情况，没有之一，改完整理数据源，面板数据会立刻出来。
4.3 常驻坑位三：容器一直CrashLoopBackOff，原因是启动参数与ConfigMap不匹配
现象：Prometheus的Pod反复重启，用kubectl logs看日志，报错信息是failed to load config, no such file或config file missing。
原因：config文件路径写错了。Prometheus容器镜像里的工作目录是/bin/prometheus，而配置文件被挂载到了/etc/prometheus/目录下。如果在启动命令里写了--config.file=prometheus.yml，进程会去当前目录找文件，找不到就退出。
解决：查看Deployment里args这一段，把--config.file的值改成/etc/prometheus/prometheus.yml，并且确认ConfigMap被正确挂载到了这个路径。对比一下容器挂载点和config.file的参数路径是否一致，保证二者匹配。一个快速排查命令：
kubectl exec -it prometheus-xxx-xxxx -n monitor -- ls /etc/prometheus/如果执行结果为空或者没有prometheus.yml，说明ConfigMap挂载失败，要查看Deployment的事件信息，找到挂载失败的具体原因。
4.4 常驻坑位四：node-exporter的Pod被驱逐，原因是默认资源配额没配合适
现象：node-exporter在每个节点上都运行，但部分节点上的Pod被标记为Evicted状态，节点内存告警。
原因：node-exporter的YAML没有设置resources.requests和limits，默认情况下它可能会被分配到高负载节点上，当节点内存紧张时，这些未设置资源限制的Pod可能被kubelet驱逐。另外hostNetwork模式下的Pod，端口与宿主机直接打通，对资源使用也比较敏感。
解决：在node-exporter的容器定义里加上resources字段，给它设定合理的请求值：
resources: requests: memory: 50Mi cpu: 100m limits: memory: 100Mi cpu: 200m这是node-exporter在生产环境比较够用的资源数值配置。另外可以给DaemonSet加上tolerations，确保即使节点有污点也能正常调度，如果发现某个节点一直跑不起node-exporter，优先排查节点是否允许调度以及NodeSelector的设置。
4.5 常驻坑位五：Grafana配置了持久化但重启后数据丢失，原因是PVC未绑定
现象：Grafana重启或Pod迁移之后，之前创建的面板、修改的配置全部还原成了初始状态。
原因：YAML里写了volumeMounts挂载到/var/lib/grafana，但没有真正创建一个PersistentVolumeClaim，或者PVC处于Pending状态没有绑定PV。
解决：确认Grafana文件里的PVC部分是不是空着，然后手动创建一个PVC：
kubectl apply -f - <<EOF apiVersion: v1 kind: PersistentVolumeClaim metadata: name: grafana-pvc namespace: monitor spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi EOF然后把Deployment里的volumes改成引用这个PVC，再滚动更新一次。如果你用的是云托管K8s服务，存储类会自动分配，没配置StorageClass的话会出现Pending状态卡住，那就先检查集群里默认的StorageClass是否存在。
5. 把监控体系补齐验证：告警规则、组件监控和全链路验证技巧
5.1 用端口转发加Curl命令验证Prometheus采集接口
整个系统部署完毕之后，最快的验证路径是：端口转发Prometheus，访问它的接口列表。在浏览器打开http://localhost:9090/api/v1/targets，这个接口会返回所有抓取任务的JSON格式数据，包含健康和最后的抓取时间。也可以用curl把返回结果接住来处理：
curl -s http://localhost:9090/api/v1/targets | jq '.data.activeTargets[] | {health: .health, scrapeUrl: .scrapeUrl}'这段命令把活跃Target的抓取地址和健康状态过滤出来，一眼能看清楚哪些地址被Prometheus探到了活。如果node-exporter的抓取URL里有10250之类的端口而没有转为9100，那就是relabel规则没生效，去检查prometheus.yaml里的relabel配置。
5.2 自定义一套Pod监控：让Prometheus采集业务侧指标
这套资源覆盖了节点层面的监控，如果你还想要监控某个具体业务应用，原理是一样的。创建一个带监测端口的Deployment，然后在prometheus.yaml的scrape_configs里追加一个job。以模拟项目X为例，它暴露了一个/metrics接口返回应用心跳数据。追加任务是这类资源最常见的扩展用法：
- job_name: app-metrics kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_label_app] regex: my-app action: keep - source_labels: [__address__] regex: '(.*):8080' replacement: '${1}:8080' target_label: __address__这里的action: keep相当于过滤器，只保留带有app=my-app标签的Pod作为抓取目标。这个配置加了之后，我们对Prometheus配置做一次热加载。一般我习惯在改动配置之后保存文件，然后检查Pod里主配置有没有同步上，确认无报错再reload。如果没有开web.enable-lifecycle，那就只能重启Prometheus的Pod让配置生效。
5.3 一个最轻量的告警规则示例：CPU使用率五分钟超阈触发
告警规则在Alertmanager成为单独组件之前，写法和验证是监控闭环的一部分。三份YAML里虽然没有明确包含alertmanager.yaml，但Prometheus原生的rules字段是支持的。创建一个ConfigMap来存放规则文件：
groups: - name: node_rules rules: - alert: NodeCPUHigh expr: (100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) > 80 for: 5m labels: severity: warning annotations: summary: "Node CPU usage exceed 80%" description: "Instance {{ $labels.instance }} CPU usage is above 80% for 5 minutes"然后通过额外挂载这个ConfigMap到Prometheus容器，再在prometheus.yml的rule_files里声明路径。执行apply和reload之后，访问Prometheus的Alerts页面，你就能看到这条规则在Active状态。用压测工具把CPU打上去，规则会先进入Pending状态，持续超过五分钟后就变成Firing，这时候如果接入了Alertmanager就会收到告警通知。
5.4 一套最终的验收脚本：三行命令确认监控体系健康
整个监控体系有没有真正跑起来，我习惯用三连命令来验收。其一查Pod状态，全部Running才算过；其二查Prometheus配置加载状态，POST /-/reload没有报错；其三是确认Grafana健康接口返回200：
kubectl get pods -n monitor curl -s -X POST http://localhost:9090/-/reload curl -s -o /dev/null -w "%{http_code}" http://localhost:3000/api/health三连检查都过，说明此路通。这套资源帮我把从一个集群没有任何监控，到数据面板、告警规则全都落在纸面上，整个过程成本很低。从那以后我给任何集群搭监控体系的时候，都习惯先把node-exporter的DaemonSet和RBAC权限准备妥当，再让Prometheus上马，最后配Grafana面板——顺序不变，坑少很多。希望这份拆解能帮你在自己的集群里少走几步弯路，直接看到数据跑起来那一刻。
本文还有配套的精品资源，点击获取
