K8s集群跑了大半年节点告警从最初的一天几十条到现在一星期也未必响一次。这个过程中踩过不少坑也沉淀了一套从指标采集、告警规则设计到通知链路、周期报告输出的完整方案。这篇就以节点级综合监控为主线把整个系统的设计思路、关键配置和几个印象深刻的故障复盘一起梳理出来希望能给你一点参考。1. 为什么节点级监控是K8s运维的第一道防线1.1 节点故障的爆炸半径从单点异常到全局雪崩先说一个很多人容易忽略的事实Pod故障和节点故障的影响范围完全不同。一个Pod OOM了被影响的是它自己顶多加上它所在的Deployment滚动一次但一个节点出问题托管在上面的一堆Pod全都跑不掉。轻则是几十上百个Pod被驱逐重建集群里的调度请求瞬间暴涨严重的情况是节点上的容器运行时直接卡死kubelet与API Server断开连接控制平面的节点心跳超时紧接着就是大面积Pending、Eviction甚至导致依赖这个节点的上层存储或中间件失联。我经历过最典型的一次某个节点上的containerd因为磁盘I/O卡死kubelet探活失败节点进入NotReady状态。控制器开始驱逐Pod而这些Pod里有一个是集群内的DNS副本DNS流量的重新路由引发了连锁超时一批服务的调用链全部变慢。这个时候你再去查应用日志看到的全是超时和重试真正的根因却在最底层——节点上的容器运行时已经僵死。这就是为什么我一直强调K8s的运维监控必须从节点这一层做起。节点是调度和运行的物理基座基座不稳上层所有的弹性伸缩、服务治理都是空中楼阁。先把节点监控做扎实再谈Pod、Service层的精细化监控这个顺序不要颠倒。1.2 节点监控与容器监控的边界划分新接触K8s的同学常常分不清节点监控和容器监控的区别。简单来说cAdvisor和kubelet内置的metrics接口提供的是容器视角比如单个Pod的CPU、内存使用量node_exporter提供的是宿主机视角比如整机的内存总可用量、磁盘总量、网络栈状态、文件系统inode情况。这两类指标不能互相替代。一个很常见的误判场景在容器里看到的某个Pod内存占用并不高但节点内存已经见底。原因是页缓存、系统内核占用、以及那些不在任何Pod命名空间里的进程比如sshd、docker守护进程、监控Agent本身也在消耗内存。如果你只盯着容器指标永远发现不了节点内存即将耗尽的问题。同理像文件系统inode耗尽、conntrack表满、时钟偏移这类问题容器视角是看不到的。它们属于宿主机内核状态但会间接导致容器发生超时、连接失败、写盘失败等种种异常。所以设计监控体系时节点指标和容器指标必须同时存在各自负责一个层面容器指标管应用运行质量节点指标管平台基座健康。1.3 从“能不能用”到“能不能忍”节点监控的度量视角节点监控的目标不是把曲线做得好看也不是单纯追求指标越低越好。我的定义是节点监控解决两个问题——节点还能不能用以及节点现在让应用有多难受。“能不能用”是可用性问题对应的是NotReady、磁盘只读、主机重启这类致命状态“能不能忍”是质量问题CPU长时间高占用、内存持续上涨、磁盘延迟变大这些不会立刻让服务挂掉但会让应用变得奇慢无比属于慢病型问题。两种问题的告警策略完全不一样前者要立刻通知、立即介入后者要设置合理的持续时间和趋势预判不能一过临界值就轰炸。把握住这个视角后面选择监控指标和设计告警规则的时候思路就会清晰很多。2. 监控指标体系哪些指标值得盯哪些只是噪音2.1 基础资源类指标与阈值设定节点监控最基础的肯定是CPU、内存、磁盘、网络这四个大类。下面是我在实际项目中一直沿用的指标清单和告警触发依据。指标类别核心指标采集来源建议告警水位CPUnode_load1/node_load5node_cpu_seconds_total聚合node_exporter使用率持续15分钟超过85%告警内存node_memory_MemAvailable_bytes / node_memory_MemTotal_bytesnode_exporter可用率低于10%立即告警磁盘node_filesystem_avail_bytes / node_filesystem_size_bytesnode_exporter可用率低于10%警告低于5%紧急inodenode_filesystem_files_free / node_filesystem_filesnode_exporterinode使用率超过90%告警PIDnode_procs_runningnode_pid_maxnode_exporterPID数量接近上限告警网络node_network_receive_bytes_total / transmit_bytes_totalnode_exporter结合速率阈值或同比突增内存和CPU的告警逻辑不一样这一点必须单独强调。CPU是可压缩资源短暂跑满是正常的业务高峰期CPU冲上去又掉下来完全不用紧张所以我给CPU设置了较长的持续窗口for 15m目的是过滤掉瞬时峰值。内存是不可压缩资源一旦耗尽就是OOM、Pod被杀的命运所以只要可用率低于10%我会让它立刻告警不加任何持续时长。磁盘这块要特别注意排除项。node_exporter默认会暴露所有挂载点的文件系统数据但像tmpfs、overlay、shm这类挂载点波动频繁直接参与告警会造成误报。配置告警表达式时一定要加上fstype和mountpoint的过滤条件只监控根分区和关键数据盘。具体写法后面告警规则部分会给出。2.2 状态类指标与事件来源每个节点的健康状态除了资源水位还有K8s自身的状态指标。这一块主要依靠kube-state-metrics暴露的指标重点关注这几个信号kube_node_status_condition这是节点状态的核心指标condition为Ready、MemoryPressure、DiskPressure、PIDPressure。只要status不是true就说明节点存在不同程度的异常。kube_node_spec_unschedulable值为1说明节点被cordon了可能是维护操作也可能是调度器因为压力状态主动规避。kube_node_info里面带了节点的内核版本、容器运行时版本、kubelet版本。升级过内核之后可以通过这个指标核对是否每台机器的版本都一致避免出现“升级漏网之鱼”导致的行为不一致。kube_node_status_capacity和kube_node_status_allocatable通过这两个指标可以算出节点的可调度余量做容量规划时很有用。状态类指标的价值在于它们直接反映K8s系统自身的判断而不是你在外部观察的猜测。比如内存明明还有剩余但节点上报了MemoryPressure说明系统层面的可分配内存已经紧张了这个时候要相信K8s的判断而不是自己的直觉。2.3 容易被忽略的“软”指标资源指标和状态指标之外还有一类指标平时不起眼一出问题就是大事这里单独列一下。时钟偏移。node_timex_offset_seconds反映节点与NTP服务器的时间偏差。K8s很多组件对时间敏感比如etcd的选举、证书校验、日志时间戳。如果节点时钟快了几秒轻则日志时间对不上排查困难重则影响分布式组件的协同。建议时间偏移超过100ms就告警。文件描述符。node_filefd_allocated和node_filefd_maximum文件描述符耗尽会导致节点无法新建任何连接现象就是“所有Pod都在但什么服务都连不上”排查起来极其困难。高并发集群要盯紧这个指标。打开的文件数。这个没有现成的exporter暴露我是配合textfile collector写脚本采的脚本统计/proc/sys/fs/file-nr的值。它和文件描述符的区别是一个进程可以把同一个文件打开多次打开的文件数可能远超文件描述符数。特殊硬件资源。GPU节点单独部署了DCGM exporter采集GPU利用率、显存占用、温度等指标。这块如果忽略GPU型号各不相同的混部集群很容易出现某个型号的卡先打满但整机指标看起来正常的场景。2.4 指标采集的技术选型节点指标的采集方案主流的还是Prometheus加各种exporter。我这里用的是node_exporter宿主机基础指标全节点部署采集间隔30秒。kube-state-metricsK8s对象状态指标部署一套即可从API Server拉取。kubelet内置metrics容器资源指标直接配置Prometheus的kubernetes_sd抓取kubelet的cAdvisor接口。textfile collector用来采集那些没有现成exporter的指标比如证书过期时间、自定义巡检脚本输出、GPU卡信息等。dcgm-exporterGPU节点专用。node_exporter的部署推荐用DaemonSet以hostNetwork和hostPID方式运行确保采集到的统计完全来自宿主机视角。还有一个实践细节node_exporter尽量保持默认端口9100不变很多大盘和告警表达式是按默认端口写的改端口之后维护成本会明显上升。3. 告警规则设计把误报和漏报同时压下去3.1 分级告警与表达式设计告警规则设计的核心不是“写多少条规则”而是“让真正该响的响不该响的别响”。我把告警分成三个级别critical、warning、info。critical是立即影响可用性的warning是质量劣化的info是提醒性质的。下面几条规则是我一直在线上的可以直接参考groups: - name: k8s-node-alerts rules: # 节点NotReady持续2分钟critical - alert: K8sNodeNotReady expr: kube_node_status_condition{conditionReady,status!true} 1 for: 2m labels: severity: critical annotations: summary: 节点 {{ $labels.node }} 进入NotReady状态 description: 节点 {{ $labels.node }} 已持续NotReady超过2分钟请立即排查kubelet状态。 # 根分区磁盘可用率低于5%立即告警critical - alert: K8sNodeRootDiskCritical expr: (node_filesystem_avail_bytes{fstype!tmpfs,fstype!overlay,mountpoint/} / node_filesystem_size_bytes{fstype!tmpfs,fstype!overlay,mountpoint/}) * 100 5 labels: severity: critical annotations: summary: 节点 {{ $labels.instance }} 根分区磁盘空间不足 description: 根分区可用率低于5%当前可用空间可能只有几百兆极易引发Docker/Kubelet写盘失败。 # 根分区磁盘可用率低于10%持续10分钟warning - alert: K8sNodeRootDiskWarning expr: (node_filesystem_avail_bytes{fstype!tmpfs,fstype!overlay,mountpoint/} / node_filesystem_size_bytes{fstype!tmpfs,fstype!overlay,mountpoint/}) * 100 10 for: 10m labels: severity: warning annotations: summary: 节点 {{ $labels.instance }} 根分区磁盘空间即将耗尽 # 节点内存可用率低于10%立即告警critical - alert: K8sNodeMemoryPressure expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 10 labels: severity: critical annotations: summary: 节点 {{ $labels.instance }} 内存压力过大 description: 内存可用率低于10%可能引发OOM请尽快定位内存消耗大户。 # 节点Load5持续15分钟高于CPU核数的80% - alert: K8sNodeCPUHighLoad expr: node_load5 / on(instance) count by(instance)(node_cpu_seconds_total{modeidle}) 0.8 for: 15m labels: severity: warning annotations: summary: 节点 {{ $labels.instance }} 负载持续过高写节点告警规则时有一个经验值得多说一句表达式里的过滤条件一定要写完整。之前我见过有人把磁盘告警写成node_filesystem_avail_bytes 10737418240结果每个节点的overlay、tmpfs全都触发告警大半夜一群人在群里问为什么磁盘警报炸了。用fstype和mountpoint把伪文件系统排除掉这类误报能少掉九成。3.2 时间窗口与“抖动”过滤Prometheus里for这个关键字决定了告警从“触发”到“发送”之间要等待多久。它的作用是过滤抖动节点负载偶尔冲高又回落不希望每条都发出来但NotReady这种致命的又不能等太久。我的经验值是这样NotReady的for不要小于2分钟。节点失联有时是网络瞬时抖动一两分钟内能恢复直接告警会制造噪音。但超过2分钟还没恢复大概率是真有问题了。磁盘低水位不用for因为磁盘空间是逐步下降的不太会出现“瞬间低水位又瞬间恢复”的抖动。CPU高占用给15分钟让业务高峰期的瞬时风暴自然消解。证书过期告警可以用for: 6h之类的长窗口避免一次性发出几百条又立刻恢复。设置for时要特别注意Prometheus的一个机制for是在同一个样本序列上的持续满足时间不是首次数值满足就立即计时。如果中间某个采集周期数值回到正常计时会重置。这既是优势天然过滤抖动也可能成为问题——比如某节点内存水位在9%和11%之间反复横跳告警可能永远无法触发。遇到这种情况不要一味加长for考虑用avg_over_time之类的聚合函数把一段时间内的均值计算出来用均值去触发告警效果会好很多。3.3 告警去重、分组与静默的真实教训告警一旦多起来去重和分组就成了刚需。Alertmanager的分组逻辑是把具有相同group_by标签的告警收纳到同一条通知里。节点监控的场景我强烈建议按node alertname分组。一个节点发生故障往往会连锁产生一堆告警比如NotReady、探针失败、Pod重启连环告警如果不分组值班的人一晚上能收到几十条信息真正的关键信息反而被淹没。分组配置可以这样定route: group_by: [alertname, node] group_wait: 30s group_interval: 5m repeat_interval: 4hgroup_wait是同一组内新告警等待多久才发送设置为30秒可以把同一节点上短时间内触发的多条告警合并成一条group_interval决定了新告警追加进已存在分组的检查频率repeat_interval是重复告警再次发送的周期设置为4小时比较合适避免同一问题每5分钟提醒一次。静默这里要提一个很常见的坑。我们团队曾经用FlashDuty做过告警屏蔽但出现了“明明屏蔽了告警还是发出来了”的情况。排查下来问题出在静默条件的标签匹配上。告警在Alertmanager里经过路由最终带着的标签和你在静默规则里写的标签有可能不是同一套。规则里match_re正则匹配的instance是node_ip:9100但Prometheus告警表达式里instance往往也带有端口或者经过集群内域名转换后不一致一个字符对不上静默就失效。所以创建静默规则前先确认实际告警里的标签集长什么样用amtool alert query或Prometheus的/api/v1/alerts接口查一下再决定match条件怎么写。4. 告警通知链路的工程化从Prometheus到企业微信4.1 Alertmanager路由树设计告警通知链路里必须有一个路由树把所有告警按类型、级别、接收方分配给不同的receiver。我的路由树设计思路是先按严重级别分岔再按告警类型归队。route: receiver: default routes: - matchers: - severitycritical receiver: wechat-critical continue: false - matchers: - severitywarning receiver: wechat-warning continue: false路由树设计有几个原则值得记一下控制接收范围。critical推送到值班大群加上核心运维成员warning只推送到运维工作群info级别告警静默处理或只写日志。避免重复通知。路由匹配命中后默认不再往下继续匹配continue: false能避免一条告警被发到多个receiver造成重复轰炸。为特定组件的告警设置独立路由。比如etcd、证书这类需要专门的专家处理的告警匹配alertname后扔到对应的专项接收组。4.2 企业微信告警机器人的集成方式国内K8s运维最常用的通知渠道大概就是企业微信群机器人了。Alertmanager没有原生的企业微信receiver但可以用webhook配合脚本实现。最简洁的方式是直接用现成的webhook适配器把Alertmanager的标准告警JSON转换成企业微信机器人的markdown消息。关键步骤是在企业微信群里添加一个自定义机器人拿到Webhook地址。部署一个webhook转发服务Python写个Flask应用即可接收Alertmanager发来的POST请求格式化后POST到企业微信的Webhook。在Alertmanager里配置receivers: - name: wechat-critical webhook_configs: - url: http://prometheus-webhook-wechat:8080/send send_resolved: true企业微信机器人有个接口频率限制每分钟20条。节点故障这种场景通常不会触发限制但如果是配置了大规模误报警的极端环境会出现消息发送失败的情况。所以转发脚本里建议加一个简单的本地队列把发送失败的消息暂存重试。消息模板上一条告警通知尽量把信息浓缩在几行内告警名称、节点、级别、当前值、持续时间、Dashboard链接。我见过有人把整个告警JSON原样推到群里全是labels和annotations字段手机上一长串滑不到底值班的人根本不知道发生了什么。4.3 告警升级与值班机制通知链路不能只停留在“发出去”。如果告警发出后半小时没人处理它就是一条无效告警。我给团队搭了一套简单的升级机制一个Python脚本监听Alertmanager webhook如果收到critical级别的告警先推送到企业微信群30分钟后未恢复脚本调用值班平台接口把告警升级为电话通知给当班人员。这个方案的关键在于“怎么判断告警是否已恢复”。我的做法是通过Prometheus的API查告警的最新状态脚本里调/api/v1/alerts?alertnamexxxactivetrue如果对应的alertnameinstance组合已经不在active列表里就取消升级。值班机制方面按星期几和时段配置值班人。核心原则是告警通知的目的是让人尽快介入而不是单纯把消息发出去。如果你现在的告警通知发出后经常无人认领先别急着买更多通知渠道想想是不是告警分类和级别划分出了问题。5. 监控数据的持续分析与周期报告产出5.1 用Grafana制作节点监控大盘告警解决的是“当下”的问题分析报告解决的是“趋势”的问题。我一直觉得一个稳定运行的K8s集群最花时间的地方不是处理告警而是看大盘、读趋势。我用的Grafana大盘分三层集群总览整集群的节点数、Ready节点数、CPU和内存总用量、总可用量、Pod总数。一屏看清集群的整体水位。节点明细每个节点的CPU、内存、磁盘、网络独立成行按使用率排序谁在吃资源一目了然。单节点详情点进某个节点看这个节点过去6小时、24小时、7天的资源趋势以及节点上各Pod的资源排行。其中节点明细面板建议用表格而不是折线图。一排一行列名是节点名、CPU使用率、内存使用率、磁盘使用率、Pod数量、状态一眼就能扫出异常节点。折线图适合单节点趋势表格适合多节点对比。大盘上还应该有一个“宿主机系统负载”面板把load1、load5、load15三条线放在一起。三个数值的差异能快速判断负载走势load1大于load15说明负载在快速攀升三条线都很高且接近说明系统长期处于高负载状态。5.2 自动生成PDF监控报告围绕“监控数据要有周期性沉淀”这个目标我搭建了自动PDF报告机制每周生成一次集群健康报告发给团队和业务方。这里要用到Grafana的Image Renderer插件和一点胶水脚本。环境准备上先给Grafana安装Image Renderer插件并用一个独立的容器跑渲染服务避免渲染图片时占用的系统资源影响Grafana主实例的性能。# 以独立服务运行grafana-image-renderer docker run -d --namegrafana-renderer \ -p 8081:8081 \ grafana/grafana-image-renderer:latest然后在Grafana的配置文件里指定渲染服务地址[rendering] server_url http://grafana-renderer:8081/render接着写一个Shell脚本用Grafana的渲染API导出指定Dashboards的PDF#!/bin/bash # 导出节点总览Dashboard为PDF curl -o /tmp/k8s-node-report.pdf \ http://grafana:3000/render/d/your-dashboard-uid?orgId1fromnow-7dtonowheight900width1600最后配置cron定时任务每周一早上8点执行脚本再把生成的文件推送到内部文档平台或者发到企业微信群里。使用时机上有一点要提醒PDF报告不要做太频繁。日报的价值其实很有限因为一天之内的数据波动不足以看出趋势周报和月报比较合适时间跨度能看到容量曲线的真实走向。5.3 从数据趋势反推容量规划监控数据的最高价值在于预测。我拿真实例子说明某套集群的节点内存使用率过去8周从55%一路爬到78%趋势非常稳定。按照这个斜率外推大约还有10周内存就会逼近90%的告警线。这个判断不需要多复杂的算法把Grafana上的周同比趋势拉出来看一眼就够了。基于趋势做容量规划我的经验数据是这样内存可用率按20%作为警戒线。内存不可压缩一旦耗尽就是OOM所以预留空间要比CPU更充裕。CPU可以接受短时高负载但持续两周的CPU使用率峰值超过70%需要考虑扩容或拆分业务。磁盘的容量规划要按“周增量”来预估。比如根分区每周增长3%那可持续使用的时间就是(当前可用百分比 - 5%安全余量) / 3%周增长率。这个方法屡试不爽。容量规划这件事其实就是把监控数据转化成决策依据。没有监控扩容靠拍脑袋要么浪费资源要么追着故障跑有了监控数据会告诉你什么时候该买机器、什么时候该调整调度策略。6. 典型故障复盘节点告警背后的真实案例6.1 案例一NotReady的隐秘元凶——内核与运行时联动有一台节点突然NotReady监控面板上CPU、内存、磁盘看着都挺正常SSH也能连上去。表面上看不像是资源耗尽那问题出在哪第一反应是看kubelet日志。journalctl -u kubelet刷出来一堆“PLEG is not healthy”的报错这是kubelet的内部健康检查失效了。继续翻系统日志dmesg发现了关键线索大量nf_conntrack: table full, dropping packet的记录。conntrack表满了新的网络连接全部被丢弃容器拉镜像、Pod健康检查、kubelet上报全都失败。根因是一个业务Pod里有人无节制地创建短连接把节点上的conntrack表撑爆了containerd的网络I/O完全卡住进而导致kubelet的探活请求也无法处理。传统排查思路只会沿着“资源→容器→应用”逐层往下推但实际是内核层的连接跟踪表耗竭。处理方案是两条线同时走紧急时执行sysctl -w net.netfilter.nf_conntrack_max262144临时调大上限重启节点上的containerd恢复网络根治时给业务Pod加上连接数限制同时在节点层监控中补上了nf_conntrack_count和nf_conntrack_max两个指标配置了使用率超过80%的告警。从那以后这类问题再也没发生过静默出现的情况。这个案例给到的教训很直接节点NotReady的原因不只有资源耗尽还可能是内核参数、网络栈状态和容器运行时之间的联动问题。排查时要习惯性把dmesg和kubelet日志放在一起看它们往往共同指向最终根因。6.2 案例二证书告警提前爆雷vSphere证书状态告警这个话题在我们的专项巡检中占了不少篇幅。K8s集群里的数字证书分布在很多位置kubelet的server证书、API Server的client证书、etcd的peer证书和client证书、镜像仓库的TLS证书随便哪个过期都是一个不小的故障。我们在节点监控里加了一套证书过期时间采集写一个巡检脚本用openssl x509 -enddate去读各关键证书的到期时间把剩余天数通过textfile collector暴露给Prometheus。脚本输出类似这样# HELP node_cert_expiry_days Certificate expiry in days # TYPE node_cert_expiry_days gauge node_cert_expiry_days{namekubelet-server,path/var/lib/kubelet/pki/kubelet-server-current.pem} 42 node_cert_expiry_days{nameetcd-peer,path/etc/kubernetes/pki/etcd/peer.crt} 126告警规则设置为剩余天数少于30天提示少于7天紧急告警。这块让我印象最深的一次事故就是依赖传统方式巡检导致证书提前两天才发现那两天里集群内组件开始互调异常我们花了一个晚上才完成全部证书轮换。自那之后证书监控纳入了节点综合监控体系关注的是剩余天数趋势这个问题再没有造成过失联。6.3 案例三磁盘告警触发却并非磁盘满另一个高频误判场景是Prometheus报警说节点根分区可用空间低于5%但登录上去执行df -h却发现还有30%的空余。告警和实际不一致监控系统在一线运维心里的信任度一下就崩了。这个现象背后的典型原因是node_filesystem_size_bytes统计的是块设备的容量但节点上可能挂着多个源目录的mount。如果根分区实际使用量不高而某个文件系统比如/var/lib/docker或/var/lib/containerd所在的挂载点已经满了告警表达式如果没有精确匹配到对应的mountpoint就会拿别的挂载点数据来评估。还有一种更隐蔽的情况一个进程持有某个已经被删除的大文件的文件句柄。df看的是当前已分配的空间这个文件虽然能从目录树里消失了但空间还没释放磁盘占用依然很高。这种情况下最有效的排查命令是lsof L1列出所有delete状态的文件找到对应的进程后重启或让它正常关闭文件句柄空间才会真正释放。现在我的磁盘告警表达式都会明确指定要监控的挂载点不依赖通配符匹配同时对可疑节点手上保留lsof排查流程这样既能保证告警精确又能在告警触发时用一套标准动作快速定位。从这套监控方案中沉淀的经验整套节点监控体系从设计到落地我感受到的最核心的一条经验是监控的价值不在于告警的数量而在于告警被处理的速度。节点层监控做扎实了K8s集群的稳定性就有了六成以上的保障因为绝大多数上层故障都能在节点状态变化里找到先兆。如果只给一个落地建议那就是不要一上来就追求指标大而全。先盯住NotReady、磁盘可用率、内存可用率这三条最核心的告警跑通Prometheus到企业微信的整条通知链路把值班的人拉进来形成闭环再逐步补充inode、conntrack、证书这类边缘但致命的指标。小步快跑比一次性铺开更容易沉淀出真正有用的规则。我现在的监控看板里始终保留着一条自定义的巡检脚本输出每台节点的kubelet最近一次成功上报时间距当前时间的秒数。这个指标没有出现在任何一本K8s书籍里但它是最早能反映节点“亚健康”的信号比任何PromQL推导都来得直接。监控这件事越贴近现场越知道该盯什么。 K8s节点监控与告警体系从指标采集到故障复盘的全流程实践
K8s集群跑了大半年节点告警从最初的一天几十条到现在一星期也未必响一次。这个过程中踩过不少坑也沉淀了一套从指标采集、告警规则设计到通知链路、周期报告输出的完整方案。这篇就以节点级综合监控为主线把整个系统的设计思路、关键配置和几个印象深刻的故障复盘一起梳理出来希望能给你一点参考。1. 为什么节点级监控是K8s运维的第一道防线1.1 节点故障的爆炸半径从单点异常到全局雪崩先说一个很多人容易忽略的事实Pod故障和节点故障的影响范围完全不同。一个Pod OOM了被影响的是它自己顶多加上它所在的Deployment滚动一次但一个节点出问题托管在上面的一堆Pod全都跑不掉。轻则是几十上百个Pod被驱逐重建集群里的调度请求瞬间暴涨严重的情况是节点上的容器运行时直接卡死kubelet与API Server断开连接控制平面的节点心跳超时紧接着就是大面积Pending、Eviction甚至导致依赖这个节点的上层存储或中间件失联。我经历过最典型的一次某个节点上的containerd因为磁盘I/O卡死kubelet探活失败节点进入NotReady状态。控制器开始驱逐Pod而这些Pod里有一个是集群内的DNS副本DNS流量的重新路由引发了连锁超时一批服务的调用链全部变慢。这个时候你再去查应用日志看到的全是超时和重试真正的根因却在最底层——节点上的容器运行时已经僵死。这就是为什么我一直强调K8s的运维监控必须从节点这一层做起。节点是调度和运行的物理基座基座不稳上层所有的弹性伸缩、服务治理都是空中楼阁。先把节点监控做扎实再谈Pod、Service层的精细化监控这个顺序不要颠倒。1.2 节点监控与容器监控的边界划分新接触K8s的同学常常分不清节点监控和容器监控的区别。简单来说cAdvisor和kubelet内置的metrics接口提供的是容器视角比如单个Pod的CPU、内存使用量node_exporter提供的是宿主机视角比如整机的内存总可用量、磁盘总量、网络栈状态、文件系统inode情况。这两类指标不能互相替代。一个很常见的误判场景在容器里看到的某个Pod内存占用并不高但节点内存已经见底。原因是页缓存、系统内核占用、以及那些不在任何Pod命名空间里的进程比如sshd、docker守护进程、监控Agent本身也在消耗内存。如果你只盯着容器指标永远发现不了节点内存即将耗尽的问题。同理像文件系统inode耗尽、conntrack表满、时钟偏移这类问题容器视角是看不到的。它们属于宿主机内核状态但会间接导致容器发生超时、连接失败、写盘失败等种种异常。所以设计监控体系时节点指标和容器指标必须同时存在各自负责一个层面容器指标管应用运行质量节点指标管平台基座健康。1.3 从“能不能用”到“能不能忍”节点监控的度量视角节点监控的目标不是把曲线做得好看也不是单纯追求指标越低越好。我的定义是节点监控解决两个问题——节点还能不能用以及节点现在让应用有多难受。“能不能用”是可用性问题对应的是NotReady、磁盘只读、主机重启这类致命状态“能不能忍”是质量问题CPU长时间高占用、内存持续上涨、磁盘延迟变大这些不会立刻让服务挂掉但会让应用变得奇慢无比属于慢病型问题。两种问题的告警策略完全不一样前者要立刻通知、立即介入后者要设置合理的持续时间和趋势预判不能一过临界值就轰炸。把握住这个视角后面选择监控指标和设计告警规则的时候思路就会清晰很多。2. 监控指标体系哪些指标值得盯哪些只是噪音2.1 基础资源类指标与阈值设定节点监控最基础的肯定是CPU、内存、磁盘、网络这四个大类。下面是我在实际项目中一直沿用的指标清单和告警触发依据。指标类别核心指标采集来源建议告警水位CPUnode_load1/node_load5node_cpu_seconds_total聚合node_exporter使用率持续15分钟超过85%告警内存node_memory_MemAvailable_bytes / node_memory_MemTotal_bytesnode_exporter可用率低于10%立即告警磁盘node_filesystem_avail_bytes / node_filesystem_size_bytesnode_exporter可用率低于10%警告低于5%紧急inodenode_filesystem_files_free / node_filesystem_filesnode_exporterinode使用率超过90%告警PIDnode_procs_runningnode_pid_maxnode_exporterPID数量接近上限告警网络node_network_receive_bytes_total / transmit_bytes_totalnode_exporter结合速率阈值或同比突增内存和CPU的告警逻辑不一样这一点必须单独强调。CPU是可压缩资源短暂跑满是正常的业务高峰期CPU冲上去又掉下来完全不用紧张所以我给CPU设置了较长的持续窗口for 15m目的是过滤掉瞬时峰值。内存是不可压缩资源一旦耗尽就是OOM、Pod被杀的命运所以只要可用率低于10%我会让它立刻告警不加任何持续时长。磁盘这块要特别注意排除项。node_exporter默认会暴露所有挂载点的文件系统数据但像tmpfs、overlay、shm这类挂载点波动频繁直接参与告警会造成误报。配置告警表达式时一定要加上fstype和mountpoint的过滤条件只监控根分区和关键数据盘。具体写法后面告警规则部分会给出。2.2 状态类指标与事件来源每个节点的健康状态除了资源水位还有K8s自身的状态指标。这一块主要依靠kube-state-metrics暴露的指标重点关注这几个信号kube_node_status_condition这是节点状态的核心指标condition为Ready、MemoryPressure、DiskPressure、PIDPressure。只要status不是true就说明节点存在不同程度的异常。kube_node_spec_unschedulable值为1说明节点被cordon了可能是维护操作也可能是调度器因为压力状态主动规避。kube_node_info里面带了节点的内核版本、容器运行时版本、kubelet版本。升级过内核之后可以通过这个指标核对是否每台机器的版本都一致避免出现“升级漏网之鱼”导致的行为不一致。kube_node_status_capacity和kube_node_status_allocatable通过这两个指标可以算出节点的可调度余量做容量规划时很有用。状态类指标的价值在于它们直接反映K8s系统自身的判断而不是你在外部观察的猜测。比如内存明明还有剩余但节点上报了MemoryPressure说明系统层面的可分配内存已经紧张了这个时候要相信K8s的判断而不是自己的直觉。2.3 容易被忽略的“软”指标资源指标和状态指标之外还有一类指标平时不起眼一出问题就是大事这里单独列一下。时钟偏移。node_timex_offset_seconds反映节点与NTP服务器的时间偏差。K8s很多组件对时间敏感比如etcd的选举、证书校验、日志时间戳。如果节点时钟快了几秒轻则日志时间对不上排查困难重则影响分布式组件的协同。建议时间偏移超过100ms就告警。文件描述符。node_filefd_allocated和node_filefd_maximum文件描述符耗尽会导致节点无法新建任何连接现象就是“所有Pod都在但什么服务都连不上”排查起来极其困难。高并发集群要盯紧这个指标。打开的文件数。这个没有现成的exporter暴露我是配合textfile collector写脚本采的脚本统计/proc/sys/fs/file-nr的值。它和文件描述符的区别是一个进程可以把同一个文件打开多次打开的文件数可能远超文件描述符数。特殊硬件资源。GPU节点单独部署了DCGM exporter采集GPU利用率、显存占用、温度等指标。这块如果忽略GPU型号各不相同的混部集群很容易出现某个型号的卡先打满但整机指标看起来正常的场景。2.4 指标采集的技术选型节点指标的采集方案主流的还是Prometheus加各种exporter。我这里用的是node_exporter宿主机基础指标全节点部署采集间隔30秒。kube-state-metricsK8s对象状态指标部署一套即可从API Server拉取。kubelet内置metrics容器资源指标直接配置Prometheus的kubernetes_sd抓取kubelet的cAdvisor接口。textfile collector用来采集那些没有现成exporter的指标比如证书过期时间、自定义巡检脚本输出、GPU卡信息等。dcgm-exporterGPU节点专用。node_exporter的部署推荐用DaemonSet以hostNetwork和hostPID方式运行确保采集到的统计完全来自宿主机视角。还有一个实践细节node_exporter尽量保持默认端口9100不变很多大盘和告警表达式是按默认端口写的改端口之后维护成本会明显上升。3. 告警规则设计把误报和漏报同时压下去3.1 分级告警与表达式设计告警规则设计的核心不是“写多少条规则”而是“让真正该响的响不该响的别响”。我把告警分成三个级别critical、warning、info。critical是立即影响可用性的warning是质量劣化的info是提醒性质的。下面几条规则是我一直在线上的可以直接参考groups: - name: k8s-node-alerts rules: # 节点NotReady持续2分钟critical - alert: K8sNodeNotReady expr: kube_node_status_condition{conditionReady,status!true} 1 for: 2m labels: severity: critical annotations: summary: 节点 {{ $labels.node }} 进入NotReady状态 description: 节点 {{ $labels.node }} 已持续NotReady超过2分钟请立即排查kubelet状态。 # 根分区磁盘可用率低于5%立即告警critical - alert: K8sNodeRootDiskCritical expr: (node_filesystem_avail_bytes{fstype!tmpfs,fstype!overlay,mountpoint/} / node_filesystem_size_bytes{fstype!tmpfs,fstype!overlay,mountpoint/}) * 100 5 labels: severity: critical annotations: summary: 节点 {{ $labels.instance }} 根分区磁盘空间不足 description: 根分区可用率低于5%当前可用空间可能只有几百兆极易引发Docker/Kubelet写盘失败。 # 根分区磁盘可用率低于10%持续10分钟warning - alert: K8sNodeRootDiskWarning expr: (node_filesystem_avail_bytes{fstype!tmpfs,fstype!overlay,mountpoint/} / node_filesystem_size_bytes{fstype!tmpfs,fstype!overlay,mountpoint/}) * 100 10 for: 10m labels: severity: warning annotations: summary: 节点 {{ $labels.instance }} 根分区磁盘空间即将耗尽 # 节点内存可用率低于10%立即告警critical - alert: K8sNodeMemoryPressure expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 10 labels: severity: critical annotations: summary: 节点 {{ $labels.instance }} 内存压力过大 description: 内存可用率低于10%可能引发OOM请尽快定位内存消耗大户。 # 节点Load5持续15分钟高于CPU核数的80% - alert: K8sNodeCPUHighLoad expr: node_load5 / on(instance) count by(instance)(node_cpu_seconds_total{modeidle}) 0.8 for: 15m labels: severity: warning annotations: summary: 节点 {{ $labels.instance }} 负载持续过高写节点告警规则时有一个经验值得多说一句表达式里的过滤条件一定要写完整。之前我见过有人把磁盘告警写成node_filesystem_avail_bytes 10737418240结果每个节点的overlay、tmpfs全都触发告警大半夜一群人在群里问为什么磁盘警报炸了。用fstype和mountpoint把伪文件系统排除掉这类误报能少掉九成。3.2 时间窗口与“抖动”过滤Prometheus里for这个关键字决定了告警从“触发”到“发送”之间要等待多久。它的作用是过滤抖动节点负载偶尔冲高又回落不希望每条都发出来但NotReady这种致命的又不能等太久。我的经验值是这样NotReady的for不要小于2分钟。节点失联有时是网络瞬时抖动一两分钟内能恢复直接告警会制造噪音。但超过2分钟还没恢复大概率是真有问题了。磁盘低水位不用for因为磁盘空间是逐步下降的不太会出现“瞬间低水位又瞬间恢复”的抖动。CPU高占用给15分钟让业务高峰期的瞬时风暴自然消解。证书过期告警可以用for: 6h之类的长窗口避免一次性发出几百条又立刻恢复。设置for时要特别注意Prometheus的一个机制for是在同一个样本序列上的持续满足时间不是首次数值满足就立即计时。如果中间某个采集周期数值回到正常计时会重置。这既是优势天然过滤抖动也可能成为问题——比如某节点内存水位在9%和11%之间反复横跳告警可能永远无法触发。遇到这种情况不要一味加长for考虑用avg_over_time之类的聚合函数把一段时间内的均值计算出来用均值去触发告警效果会好很多。3.3 告警去重、分组与静默的真实教训告警一旦多起来去重和分组就成了刚需。Alertmanager的分组逻辑是把具有相同group_by标签的告警收纳到同一条通知里。节点监控的场景我强烈建议按node alertname分组。一个节点发生故障往往会连锁产生一堆告警比如NotReady、探针失败、Pod重启连环告警如果不分组值班的人一晚上能收到几十条信息真正的关键信息反而被淹没。分组配置可以这样定route: group_by: [alertname, node] group_wait: 30s group_interval: 5m repeat_interval: 4hgroup_wait是同一组内新告警等待多久才发送设置为30秒可以把同一节点上短时间内触发的多条告警合并成一条group_interval决定了新告警追加进已存在分组的检查频率repeat_interval是重复告警再次发送的周期设置为4小时比较合适避免同一问题每5分钟提醒一次。静默这里要提一个很常见的坑。我们团队曾经用FlashDuty做过告警屏蔽但出现了“明明屏蔽了告警还是发出来了”的情况。排查下来问题出在静默条件的标签匹配上。告警在Alertmanager里经过路由最终带着的标签和你在静默规则里写的标签有可能不是同一套。规则里match_re正则匹配的instance是node_ip:9100但Prometheus告警表达式里instance往往也带有端口或者经过集群内域名转换后不一致一个字符对不上静默就失效。所以创建静默规则前先确认实际告警里的标签集长什么样用amtool alert query或Prometheus的/api/v1/alerts接口查一下再决定match条件怎么写。4. 告警通知链路的工程化从Prometheus到企业微信4.1 Alertmanager路由树设计告警通知链路里必须有一个路由树把所有告警按类型、级别、接收方分配给不同的receiver。我的路由树设计思路是先按严重级别分岔再按告警类型归队。route: receiver: default routes: - matchers: - severitycritical receiver: wechat-critical continue: false - matchers: - severitywarning receiver: wechat-warning continue: false路由树设计有几个原则值得记一下控制接收范围。critical推送到值班大群加上核心运维成员warning只推送到运维工作群info级别告警静默处理或只写日志。避免重复通知。路由匹配命中后默认不再往下继续匹配continue: false能避免一条告警被发到多个receiver造成重复轰炸。为特定组件的告警设置独立路由。比如etcd、证书这类需要专门的专家处理的告警匹配alertname后扔到对应的专项接收组。4.2 企业微信告警机器人的集成方式国内K8s运维最常用的通知渠道大概就是企业微信群机器人了。Alertmanager没有原生的企业微信receiver但可以用webhook配合脚本实现。最简洁的方式是直接用现成的webhook适配器把Alertmanager的标准告警JSON转换成企业微信机器人的markdown消息。关键步骤是在企业微信群里添加一个自定义机器人拿到Webhook地址。部署一个webhook转发服务Python写个Flask应用即可接收Alertmanager发来的POST请求格式化后POST到企业微信的Webhook。在Alertmanager里配置receivers: - name: wechat-critical webhook_configs: - url: http://prometheus-webhook-wechat:8080/send send_resolved: true企业微信机器人有个接口频率限制每分钟20条。节点故障这种场景通常不会触发限制但如果是配置了大规模误报警的极端环境会出现消息发送失败的情况。所以转发脚本里建议加一个简单的本地队列把发送失败的消息暂存重试。消息模板上一条告警通知尽量把信息浓缩在几行内告警名称、节点、级别、当前值、持续时间、Dashboard链接。我见过有人把整个告警JSON原样推到群里全是labels和annotations字段手机上一长串滑不到底值班的人根本不知道发生了什么。4.3 告警升级与值班机制通知链路不能只停留在“发出去”。如果告警发出后半小时没人处理它就是一条无效告警。我给团队搭了一套简单的升级机制一个Python脚本监听Alertmanager webhook如果收到critical级别的告警先推送到企业微信群30分钟后未恢复脚本调用值班平台接口把告警升级为电话通知给当班人员。这个方案的关键在于“怎么判断告警是否已恢复”。我的做法是通过Prometheus的API查告警的最新状态脚本里调/api/v1/alerts?alertnamexxxactivetrue如果对应的alertnameinstance组合已经不在active列表里就取消升级。值班机制方面按星期几和时段配置值班人。核心原则是告警通知的目的是让人尽快介入而不是单纯把消息发出去。如果你现在的告警通知发出后经常无人认领先别急着买更多通知渠道想想是不是告警分类和级别划分出了问题。5. 监控数据的持续分析与周期报告产出5.1 用Grafana制作节点监控大盘告警解决的是“当下”的问题分析报告解决的是“趋势”的问题。我一直觉得一个稳定运行的K8s集群最花时间的地方不是处理告警而是看大盘、读趋势。我用的Grafana大盘分三层集群总览整集群的节点数、Ready节点数、CPU和内存总用量、总可用量、Pod总数。一屏看清集群的整体水位。节点明细每个节点的CPU、内存、磁盘、网络独立成行按使用率排序谁在吃资源一目了然。单节点详情点进某个节点看这个节点过去6小时、24小时、7天的资源趋势以及节点上各Pod的资源排行。其中节点明细面板建议用表格而不是折线图。一排一行列名是节点名、CPU使用率、内存使用率、磁盘使用率、Pod数量、状态一眼就能扫出异常节点。折线图适合单节点趋势表格适合多节点对比。大盘上还应该有一个“宿主机系统负载”面板把load1、load5、load15三条线放在一起。三个数值的差异能快速判断负载走势load1大于load15说明负载在快速攀升三条线都很高且接近说明系统长期处于高负载状态。5.2 自动生成PDF监控报告围绕“监控数据要有周期性沉淀”这个目标我搭建了自动PDF报告机制每周生成一次集群健康报告发给团队和业务方。这里要用到Grafana的Image Renderer插件和一点胶水脚本。环境准备上先给Grafana安装Image Renderer插件并用一个独立的容器跑渲染服务避免渲染图片时占用的系统资源影响Grafana主实例的性能。# 以独立服务运行grafana-image-renderer docker run -d --namegrafana-renderer \ -p 8081:8081 \ grafana/grafana-image-renderer:latest然后在Grafana的配置文件里指定渲染服务地址[rendering] server_url http://grafana-renderer:8081/render接着写一个Shell脚本用Grafana的渲染API导出指定Dashboards的PDF#!/bin/bash # 导出节点总览Dashboard为PDF curl -o /tmp/k8s-node-report.pdf \ http://grafana:3000/render/d/your-dashboard-uid?orgId1fromnow-7dtonowheight900width1600最后配置cron定时任务每周一早上8点执行脚本再把生成的文件推送到内部文档平台或者发到企业微信群里。使用时机上有一点要提醒PDF报告不要做太频繁。日报的价值其实很有限因为一天之内的数据波动不足以看出趋势周报和月报比较合适时间跨度能看到容量曲线的真实走向。5.3 从数据趋势反推容量规划监控数据的最高价值在于预测。我拿真实例子说明某套集群的节点内存使用率过去8周从55%一路爬到78%趋势非常稳定。按照这个斜率外推大约还有10周内存就会逼近90%的告警线。这个判断不需要多复杂的算法把Grafana上的周同比趋势拉出来看一眼就够了。基于趋势做容量规划我的经验数据是这样内存可用率按20%作为警戒线。内存不可压缩一旦耗尽就是OOM所以预留空间要比CPU更充裕。CPU可以接受短时高负载但持续两周的CPU使用率峰值超过70%需要考虑扩容或拆分业务。磁盘的容量规划要按“周增量”来预估。比如根分区每周增长3%那可持续使用的时间就是(当前可用百分比 - 5%安全余量) / 3%周增长率。这个方法屡试不爽。容量规划这件事其实就是把监控数据转化成决策依据。没有监控扩容靠拍脑袋要么浪费资源要么追着故障跑有了监控数据会告诉你什么时候该买机器、什么时候该调整调度策略。6. 典型故障复盘节点告警背后的真实案例6.1 案例一NotReady的隐秘元凶——内核与运行时联动有一台节点突然NotReady监控面板上CPU、内存、磁盘看着都挺正常SSH也能连上去。表面上看不像是资源耗尽那问题出在哪第一反应是看kubelet日志。journalctl -u kubelet刷出来一堆“PLEG is not healthy”的报错这是kubelet的内部健康检查失效了。继续翻系统日志dmesg发现了关键线索大量nf_conntrack: table full, dropping packet的记录。conntrack表满了新的网络连接全部被丢弃容器拉镜像、Pod健康检查、kubelet上报全都失败。根因是一个业务Pod里有人无节制地创建短连接把节点上的conntrack表撑爆了containerd的网络I/O完全卡住进而导致kubelet的探活请求也无法处理。传统排查思路只会沿着“资源→容器→应用”逐层往下推但实际是内核层的连接跟踪表耗竭。处理方案是两条线同时走紧急时执行sysctl -w net.netfilter.nf_conntrack_max262144临时调大上限重启节点上的containerd恢复网络根治时给业务Pod加上连接数限制同时在节点层监控中补上了nf_conntrack_count和nf_conntrack_max两个指标配置了使用率超过80%的告警。从那以后这类问题再也没发生过静默出现的情况。这个案例给到的教训很直接节点NotReady的原因不只有资源耗尽还可能是内核参数、网络栈状态和容器运行时之间的联动问题。排查时要习惯性把dmesg和kubelet日志放在一起看它们往往共同指向最终根因。6.2 案例二证书告警提前爆雷vSphere证书状态告警这个话题在我们的专项巡检中占了不少篇幅。K8s集群里的数字证书分布在很多位置kubelet的server证书、API Server的client证书、etcd的peer证书和client证书、镜像仓库的TLS证书随便哪个过期都是一个不小的故障。我们在节点监控里加了一套证书过期时间采集写一个巡检脚本用openssl x509 -enddate去读各关键证书的到期时间把剩余天数通过textfile collector暴露给Prometheus。脚本输出类似这样# HELP node_cert_expiry_days Certificate expiry in days # TYPE node_cert_expiry_days gauge node_cert_expiry_days{namekubelet-server,path/var/lib/kubelet/pki/kubelet-server-current.pem} 42 node_cert_expiry_days{nameetcd-peer,path/etc/kubernetes/pki/etcd/peer.crt} 126告警规则设置为剩余天数少于30天提示少于7天紧急告警。这块让我印象最深的一次事故就是依赖传统方式巡检导致证书提前两天才发现那两天里集群内组件开始互调异常我们花了一个晚上才完成全部证书轮换。自那之后证书监控纳入了节点综合监控体系关注的是剩余天数趋势这个问题再没有造成过失联。6.3 案例三磁盘告警触发却并非磁盘满另一个高频误判场景是Prometheus报警说节点根分区可用空间低于5%但登录上去执行df -h却发现还有30%的空余。告警和实际不一致监控系统在一线运维心里的信任度一下就崩了。这个现象背后的典型原因是node_filesystem_size_bytes统计的是块设备的容量但节点上可能挂着多个源目录的mount。如果根分区实际使用量不高而某个文件系统比如/var/lib/docker或/var/lib/containerd所在的挂载点已经满了告警表达式如果没有精确匹配到对应的mountpoint就会拿别的挂载点数据来评估。还有一种更隐蔽的情况一个进程持有某个已经被删除的大文件的文件句柄。df看的是当前已分配的空间这个文件虽然能从目录树里消失了但空间还没释放磁盘占用依然很高。这种情况下最有效的排查命令是lsof L1列出所有delete状态的文件找到对应的进程后重启或让它正常关闭文件句柄空间才会真正释放。现在我的磁盘告警表达式都会明确指定要监控的挂载点不依赖通配符匹配同时对可疑节点手上保留lsof排查流程这样既能保证告警精确又能在告警触发时用一套标准动作快速定位。从这套监控方案中沉淀的经验整套节点监控体系从设计到落地我感受到的最核心的一条经验是监控的价值不在于告警的数量而在于告警被处理的速度。节点层监控做扎实了K8s集群的稳定性就有了六成以上的保障因为绝大多数上层故障都能在节点状态变化里找到先兆。如果只给一个落地建议那就是不要一上来就追求指标大而全。先盯住NotReady、磁盘可用率、内存可用率这三条最核心的告警跑通Prometheus到企业微信的整条通知链路把值班的人拉进来形成闭环再逐步补充inode、conntrack、证书这类边缘但致命的指标。小步快跑比一次性铺开更容易沉淀出真正有用的规则。我现在的监控看板里始终保留着一条自定义的巡检脚本输出每台节点的kubelet最近一次成功上报时间距当前时间的秒数。这个指标没有出现在任何一本K8s书籍里但它是最早能反映节点“亚健康”的信号比任何PromQL推导都来得直接。监控这件事越贴近现场越知道该盯什么。