直接看集群整体健康度需联动节点层、Pod层、应用层三层状态：节点层关注kube_node_status_phase、node_memory_available_bytes、kubelet_running_pods_count及disk/memory/pid pressure持续时长；Pod层穿透kubectl get pods表象，结合events分析Pending/ContainerCreating/CrashLoopBackOff/Running但NotReady根因；应用层将liveness/readiness探针与SRE四大黄金信号对齐，并防范probe路径过轻导致的静默失效。
直接看集群整体健康度，关键不是堆指标，而是抓准三层状态：节点层、Pod层、应用层。这三层不联动，监控就是碎片。
节点健康是底座，但不能只看“Ready/NotReady”
节点状态只是表象。比如一个节点显示 Ready，但内存碎片严重、kubelet心跳延迟、磁盘 inode 耗尽，Pod照样频繁驱逐。必须结合以下指标交叉验证：
- kube_node_status_phase（Pending/NotReady/Unknown）
- node_cpu_usage_percent 和 node_memory_available_bytes（注意不是 used，是 available）
- kubelet_running_pods_count（低于预期值说明调度异常）
- disk_pressure、memory_pressure、pid_pressure 这三个 condition 的持续时长
单点告警建议设为“连续5分钟内，3个以上 pressure condition 同时触发”，避免瞬时抖动误报。
Pod 状态要穿透到“为什么没 Running”
kubectl get pods 只显示 Phase，真正要盯的是背后事件链：
- Pending：查 events 里是否卡在 ImagePullBackOff、InsufficientCPU、FailedScheduling
- ContainerCreating：看 init container 是否超时，或 volume mount 失败
- CrashLoopBackOff：提取 lastState.terminated.exitCode + message，比日志更快定位 OOMKilled 或 panic
- Running 但 NotReady：检查 readinessProbe 失败次数和失败原因（HTTP 503？TCP 拒绝？命令返回非零？）
推荐用 Prometheus 查询：
sum by (reason) (count(kube_pod_status_phase{phase=~"Pending|Unknown"}) * on(job) group_left() kube_pod_status_phase)
能快速聚类当前最集中的失败类型。
应用级健康得靠探针+黄金信号联动
Liveness 和 Readiness 探针本身不是目的，而是把它们和 SRE 四大黄金信号（延迟、流量、错误、饱和度）对齐：
- /healthz 返回 200 ≠ 应用健康，需确认该接口是否真实调用了下游 DB 和缓存
- 错误率突增时，自动检查对应 Pod 的 readinessProbe 成功率是否同步下跌
- 流量下降但 Pod 全部 Ready？查 endpoints 对应的 readyAddresses 数量是否归零
TKE、EKS、ACK 等托管服务已内置 probe 执行日志聚合，可直接关联 trace ID 查探针调用链；自建集群建议用 OpenTelemetry 把 probe 请求打上 pod_name、namespace 标签，便于下钻。
别漏掉“静默失效”场景：长期存活但无响应
有些 Pod 一直 Running，probe 也成功，但实际请求全超时——因为 probe 路径太轻（如只 return “OK”），而业务路径卡死。应对方法：
- probe 接口必须包含一次最小闭环调用（如查一次本地配置 + 一次 Redis ping）
- 在 Grafana 面板中并列展示：probe_success_rate vs http_request_duration_seconds_avg（业务路径）
- 设置“probe 成功率 100% 但 P99 延迟 >2s 持续3分钟”为高优告警
不复杂但容易忽略。
