节点Ready不等于集群健康，需验证API Server（/livez/readyz）、Metrics Server、控制平面Pod、etcd及基础调度能力。
安装完 Kubernetes 后，光看 kubectl get nodes 显示 Ready 并不等于集群真正健康。很多故障（如调度卡住、Pod 无法启动、指标不可用）在节点“就绪”状态下依然存在。必须主动验证几类关键指标，否则上线应用后容易踩坑。
检查 API Server 是否响应正常
这是整个集群的入口，所有操作都依赖它。如果它假死或 TLS 配置错误，kubectl 可能仍能连上但返回超时或 403。
直接调用健康端点最可靠：
curl -k https://<master-ip>:6443/healthz curl -k https://<master-ip>:6443/livez curl -k https://<master-ip>:6443/readyz
注意：/healthz 已被弃用，优先用 /livez 和 /readyz；-k 是因为自签证书环境常见，生产环境应配好 CA；返回 ok 才算通过，任何 HTTP 非 200 或响应体含 failure 都要排查。
验证 Metrics Server 是否就绪并可查数据
没有 Metrics Server，kubectl top node 和 HPA 就完全失效，但集群照样能跑 Pod —— 这是最隐蔽的“伪健康”陷阱。
- 先确认 Pod 运行：
kubectl get pod -n kube-system | grep metrics-server，状态必须是Running且 Ready 为1/1 - 再验证数据可取：
kubectl top node必须输出 CPU/MEM 列表，若报Metrics API not available，说明 Metrics Server 没真正连上 kubelet（常见于没加--kubelet-insecure-tls或证书 CN 不匹配） - 检查日志：
kubectl logs -n kube-system deploy/metrics-server，重点关注是否反复报x509: certificate signed by unknown authority
确认核心控制平面组件状态
etcd、scheduler、controller-manager 的健康不体现在 get nodes 里，得查它们的 ComponentStatus（虽已弃用，但仍是快速筛查手段）或直接看 Pod。
推荐方式是查命名空间下的 Pod：
kubectl get pod -n kube-system | grep -E "(etcd|scheduler|controller-manager)"
重点看三类问题：
- etcd Pod 处于
CrashLoopBackOff：大概率是磁盘满、peer 通信失败或证书过期 - scheduler/controller-manager 显示
0/1Ready：可能是 RBAC 权限缺失或监听地址配置错误（如绑定了127.0.0.1而非0.0.0.0） - 所有组件时间戳相差过大（>30s）：说明节点间 NTP 不同步，可能引发 etcd leader 频繁切换
测试基础调度与运行能力
节点 Ready 只代表 kubelet 在线，不代表能真正调度和运行容器。必须手动触发一次最小闭环验证。
执行以下命令并观察结果：
kubectl run nginx-test --image=nginx:alpine --restart=Never kubectl wait --for=condition=completed --timeout=60s job/nginx-test kubectl get pod -l run=nginx-test
失败常见原因：
- Pod 卡在
Pending：通常是资源不足、污点未容忍、StorageClass 缺失或 CNI 插件没装好 - Pod 进入
ImagePullBackOff：镜像仓库不可达或认证失败（私有仓库没配imagePullSecret） - Pod 启动后立即
CrashLoopBackOff：可能是 initContainer 失败、安全策略（如 seccomp）拦截或挂载卷权限问题
这个测试看似简单，但覆盖了调度器、kubelet、CNI、镜像拉取、容器运行时五个关键链路，漏掉任何一个，后续应用部署都会出问题。
