K8s节点健康监控全流程解析

K8s节点健康监控全流程解析

       在kubernetes集群中，节点健康状态的监测、通知和响应是由多个核心组件协同完成的分布式过程，具体分工如下：

一、监测机制：由节点代理与控制平面共同完成

1、kubelet（核心节点代理）
    运行在每个节点上，是节点健康监测第一责任人。
    1）监测范围： 
        节点资源状态：通过cAdvisor收集CPU、内存、磁盘等系统指标。
        容器健康状态：通过probemanager执行livenessPorbe（存活探针）和readinessProbe（就绪探针），支持HTTP/TCP/命令三种检查方式。
        Pod状态：定期向API Server上报节点上所有pod的状态（如Running、Pending、Failed）。
    2）数据暴露端口：
         10248：健康检查端口（如/healthz）；
         10255：只读API端口，提供节点与pod信息（无需认证）。
  2、控制平面组件
    1）kube-controller-manager
      内含node-controller，通过API Server监听节点状态（如Node Ready），若节点超时未上报心跳（默认40秒），将其标记为NotReady。
    2）kube-scheduler
      依赖节点健康状态决策pod调度（如避开NotReady节点）。

二、通知机制：状态上报与告警

1、状态上报与告警  
    kubelet定期（默认10秒）向API Server发送节点心跳（Nodestatus），包含资源使用、Pod状态等。
    若节点故障，node-controller更新节点状态为NotReady，并写入etcd。
  2、告警通知
    1）内置告警规则：
      例如Prometheus监控集群时，可配置规则（如节点CPU>80%持续5分钟出发告警）。
   2）自定义通知：
      集成外部系统（如grafana、腾讯云可观测AI工作台），通过web hook/邮件/Slack等发送告警。

三、响应机制：自动化处理与人工介入

1、自动化响应
    1）Pod驱逐：
      当节点NotReady时，node-controller自动驱逐其上的pod（默认5分钟容忍期），并由调度器迁移到健康节点。
    2）资源回收：
      eviction manager在节点资源不足时（如内存耗尽）按QoS优先级驱逐Pod。
    3）自愈操作：
      若容器探针失败，kubelet自动重启容器（根据restartPolicy）。
  2、人工介入场景
    1）硬件故障、网络分区等需运维人员处理；
    2）通过日志（kubectl logs）或工具（如Prometheus/grafana仪表盘）分析根因；
   3） 使用诊断工具（如kubelet pod_analyze）定位问题。

总结：责任分工

组件	监测职责	通知与响应
kubelet	节点资源、容器健康、pod状态	上报状态至API Server；重启失败容器
node-controller	监听节点心跳超时	标记NotReady状态；触发pod驱逐
kube-scheduler	依赖节点状态调度	避开不健康节点
运维系统/告警平台	聚合指标与日志	发送告警；提供根因分析与修复建议（如AI工作台）