Kubernetes节点健康监控核心是检查Ready状态及控制平面组件可用性。通过kubectl get nodes查看STATUS，describe node分析Conditions，调用/healthz验证API Server、etcd等组件，并结合DaemonSet探活代理与云平台监控实现多维可观测。
监控容器集群节点的健康存活状态，核心是结合 Kubernetes 原生机制与外部可观测性工具，从“节点级”和“控制平面级”两个维度持续验证其在线性、响应能力和资源可用性。
节点就绪状态（Node Ready Condition）是第一道判断依据
Kubernetes 通过 kubelet 定期向 API Server 上报心跳，形成 NodeCondition。其中 Ready=True 表示节点可调度、网络通、kubelet 正常运行。可通过以下方式实时查看：
-
kubectl get nodes—— 观察 STATUS 列是否为 Ready；长期显示 NotReady 需立即介入 -
kubectl describe node <node-name>—— 查看 Conditions 区域，重点关注Ready、MemoryPressure、DiskPressure、PIDPressure等子状态 - 注意：偶发 NotReady 可能由瞬时网络抖动或 kubelet 短暂卡顿引起，不建议单次触发告警；推荐配置“连续 5 次检测失败”才触发告警
控制平面组件健康检查不可绕过
节点本身健康，不等于它能被集群正常纳管。需确认控制平面组件（尤其是 API Server 和 etcd）是否稳定，否则节点即使在线也无法注册或接收任务：
- 检查
kubectl get componentstatuses（已弃用但仍有参考价值），或直接调用/healthz端点：curl -k https://<api-server-ip>:6443/healthz（返回 200 表示 API Server 健康） - 验证 etcd 健康：
kubectl exec -n kube-system <etcd-pod> -- etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key endpoint health - 调度器（scheduler）和控制器管理器（controller-manager）也应有对应 /healthz 探针，建议在 Prometheus 中统一采集其 probe 指标
利用 DaemonSet 部署轻量级节点探活代理
在每个节点上运行一个专属探活 Pod（如基于 busybox + curl 或自定义 HTTP 服务），主动上报自身状态到中心系统，弥补 kubelet 心跳丢失后的盲区：
- 典型方案：用 DaemonSet 部署一个简单 HTTP 服务（监听 8081），返回
{"node": "xxx", "timestamp": "...", "status": "ok"} - Prometheus 抓取该端点指标；Grafana 展示各节点最后上报时间差（last_scrape_timestamp_seconds），延迟超阈值即告警
- 优势：不依赖 kubelet 是否存活，即使 kubelet crash，只要容器运行时还在，该探活 Pod 就仍可工作
云厂商监控与日志联动提升定位效率
公有云环境（如腾讯云 TKE、阿里云 ACK）通常提供节点层基础监控，应与 Kubernetes 原生指标交叉验证：
- 启用云平台的“节点健康状态”、“CPU/内存使用率”、“系统进程数”、“磁盘 inode 使用率”等指标告警
- 将 kubelet 日志、dmesg 输出、systemd journal（如
journalctl -u kubelet）接入集中日志系统，当节点 NotReady 时自动关联最近 5 分钟日志关键词（如 “failed to start container”, “context deadline exceeded”, “cgroup v2”） - 设置告警聚合规则：同一节点若同时出现 CPU >95% + kubelet NotReady + dmesg OOM 日志，则升级为 P1 级别事件
不复杂但容易忽略的是：节点健康 ≠ 应用健康。必须把节点状态、Pod 调度成功率、kube-proxy 规则同步状态、CNI 插件日志一起纳入视图，才能真正看清一个节点是否“活着且可用”。
