集群节点巡检清单需将可用性目标拆解为可测、可判、可闭环动作，按控制平面、工作节点、数据面节点分层定义差异化检查项，每项含采集方式、阈值依据与影响说明，并嵌入自动化执行、结构化输出及动态版本化维护机制。
制定集群节点巡检清单，核心是把“可用性目标”拆解成可测、可判、可闭环的具体动作。不能只列“检查CPU”，而要明确“查什么、怎么查、超多少算异常、谁来响应、下一步做什么”。清单不是静态文档，而是随架构演进持续校准的执行契约。
按角色分层定义检查项
不同节点承担不同职责，巡检重点必须差异化：
- 控制平面节点（如K8s master、Pacemaker仲裁节点）：重点查etcd或Corosync通信状态、API Server响应延迟、调度器积压任务数、证书有效期（尤其CA和server cert）、leader选举日志是否频繁切换
- 工作节点（worker、compute node）：聚焦kubelet健康、容器运行时（containerd/docker）状态、CNI插件pod是否Ready、/var/lib/kubelet磁盘空间、cgroup内存限制是否触发OOMKilled
- 数据面节点（Nginx LB、HAProxy、Keepalived）：必须验证VIP绑定状态、VRRP优先级与实际权重一致性、后端真实服务探测结果（非仅进程存活）、连接数与max_connections比值、SSL证书剩余天数
指标必须带上下文和判定逻辑
单一数值无意义，每个检查项需包含采集方式、阈值依据、影响范围说明：
- CPU使用率＞90%持续5分钟 → 触发告警，但需同步检查是单核打满还是整体负载不均；若为kube-scheduler高占用，可能指向Pod亲和性配置问题
- 内存可用＜10% → 不仅看free值，还要看slab_reclaimable是否异常增长，避免误判为内存泄漏
- 磁盘I/O等待时间（await）＞50ms → 结合iostat -x查看%util是否接近100%，区分是存储瓶颈还是临时抖动
- 网络丢包率＞0.5% → 需定位到具体网卡（bond0还是ens1f0），并检查ARP表老化时间、MTU设置是否一致
嵌入自动化执行与反馈闭环
巡检清单必须能被工具直接调用，输出结果驱动后续动作：
- 所有检查命令封装为幂等脚本，返回码严格对应状态：0=正常，1=预警，2=故障，3=不可达
- 关键项（如VIP状态、etcd member list）输出结构化JSON，含timestamp、node_id、metric_name、value、threshold、severity
- 巡检失败自动触发预设动作：例如Keepalived权重下调、节点打cordoned标签、向值班人员推送带上下文的工单（含最近3次该指标趋势图）
- 每次巡检结果存档至少90天，支持按节点、时间、指标类型回溯对比
动态更新机制保障有效性
清单不是一成不变，需建立版本化维护流程：
- 每季度对照SLA达成情况复盘：某项指标从未告警，说明阈值过松；某项频繁误报，需优化探测逻辑
- 新组件上线前，必须完成巡检项补充评审，明确其健康信号（如Service Mesh中Envoy的cluster_upstream_cx_active）
- 重大变更（如内核升级、CNI切换）后48小时内，执行强化巡检，覆盖兼容性风险点
- 清单文件采用Git管理，每次修改附变更原因、测试记录、生效时间
