kubectl get nodes是验证节点状态的首要命令，STATUS为Ready表示节点在线可用，NotReady则需排查CNI、网络、kubelet或证书等问题；须结合describe node、get pods -A及网络连通性测试综合判断。
检查集群节点状态是否为 Ready
安装完 Kubernetes 后，第一件事不是急着部署应用，而是确认控制平面和工作节点是否真正“在线且可用”。kubectl get nodes 是最直接的验证入口，但容易忽略的是 STATUS 列背后的含义。
常见错误现象：节点显示 NotReady，但 kubelet 进程在运行、systemctl status kubelet 看似正常。这通常意味着 CNI 插件未就绪或网络配置有误——比如 calico 的 pod 卡在 Pending，或 flannel 的 ConfigMap 缺失网段定义。
- 执行
kubectl get nodes -o wide，核对INTERNAL-IP是否与/etc/hosts或 DNS 解析一致（尤其在多网卡环境） - 若节点状态异常，立即查
kubectl get pods -A | grep -E "(calico|flannel|kube-proxy)"，重点关注STATUS和RESTARTS - 不要跳过
kubectl describe node <node-name>，其中Conditions下的Ready、NetworkReady字段才是真实健康信号
验证 Pod 调度与基础网络连通性
节点 Ready 只是前提，真正能跑起来才算数。用一个极简的 busybox Pod 测试调度、拉镜像、启动、DNS 和跨节点通信四个关键环节。
执行：kubectl run test-pod --image=busybox:1.35 --restart=Never --command -- sleep 3600，然后等它进入 Running 状态。这时候别急着删，先做三件事：
- 进容器执行
kubectl exec -it test-pod -- nslookup kubernetes.default.svc.cluster.local，验证 CoreDNS 是否生效（失败说明corednsPod 异常或ServiceCIDR 配置冲突） - 再起一个同命名空间的 Pod，用
kubectl exec尝试ping它的 ClusterIP，确认 Service 网络层通（注意：不是 ping Pod IP，那是 CNI 层的事） - 如果跨节点 Pod 间无法通信，大概率是 CNI 插件没正确配置 VXLAN 或 BGP 路由，而非
kube-proxy问题——后者只管 iptables/IPVS 规则生成
确认 kubectl 与 API Server 的认证链完整
kubectl 能连上不代表权限没问题。很多用户卡在 Forbidden 错误却以为集群装好了，实际是 rbac.authorization.k8s.io 没配或 kubeconfig 中的 user 凭据过期。
典型表现：kubectl get pods 成功，但 kubectl logs 或 kubectl exec 报错 error: You must be logged in to the server (the server has asked for the client to provide credentials)。
- 检查当前 context 使用的 user：
kubectl config view --minify --output 'jsonpath={..user}' - 确认该 user 对应的证书未过期：
openssl x509 -in /path/to/client.crt -noout -dates - 若用 token 认证（如
serviceaccount），需验证对应Secret是否挂载进 Pod，且token文件存在、内容可读
测试基础资源对象生命周期管理
最后一步，用最常用的对象类型走通创建 → 查看 → 更新 → 删除全链路，排除 YAML 解析、admission controller 或 etcd 写入问题。
推荐用 Deployment + Service 组合，因为它覆盖了控制器、Pod 模板、Endpoint 同步、iptables/IPVS 规则下发多个环节：
- 创建：
kubectl create deploy nginx-test --image=nginx:1.25 --replicas=2 - 暴露：
kubectl expose deploy nginx-test --port=80 --target-port=80 --type=ClusterIP - 验证：
kubectl get endpoints nginx-test应返回两个Pod IP:80地址；kubectl get svc nginx-test的CLUSTER-IP要能被其他 Podcurl -I http://<cluster-ip>访问通 - 缩容再扩：执行
kubectl scale deploy nginx-test --replicas=1，观察get pods是否只剩一个，且endpoints条目同步减少
真正容易被忽略的是 etcd 健康状态——所有资源操作最终都落盘到它。哪怕前面步骤全绿，etcdctl endpoint health 返回 unhealthy，后续任何变更都可能静默失败或延迟生效。
