优先检查 kube-system 命名空间下 Pod 的 READY 状态和 Events，执行 kubectl get pods -n kube-system 查看是否全为 Running 且 READY 列匹配副本数（如 1/1），再用 kubectl describe pod 定位 Events 中的 FailedScheduling、镜像拉取失败等关键错误，90% 异常可直接定位。
安装后核心组件状态异常，优先检查 kube-system 命名空间下 Pod 的 READY 状态和 Events，90% 的问题能直接从 kubectl get pods -n kube-system 和 kubectl describe pod 输出中定位。
查看 kube-system 下所有 Pod 是否就绪
刚装完集群，kube-apiserver、kube-controller-manager、kube-scheduler、coredns、calico-node（或 flannel）这些 Pod 必须全部处于 Running 且 READY 列为 1/1（或对应副本数）。任何非 1/1 或 Pending/CrashLoopBackOff 都是明确信号。
执行命令：
kubectl get pods -n kube-system
常见误判点：
-
coredns显示0/1：不是 DNS 没起，而是它依赖网络插件（如 Calico）先就绪；先看calico-node状态 -
calico-node卡在Init:0/3：说明 InitContainer 失败，必须用kubectl describe pod查 Events 和 Init Container 日志 -
kube-scheduler一直是Pending：大概率是节点没打标签（比如缺失node-role.kubernetes.io/control-plane=），或被污点阻塞
用 describe 定位具体失败原因
kubectl describe pod 是最高效的根因入口，尤其关注输出末尾的 Events 区域——它不撒谎，直接告诉你“为什么没起来”。
例如：
kubectl describe pod calico-node-abc12 -n kube-system
重点关注以下几类事件：
-
FailedScheduling：调度器找不到匹配节点，检查节点taints、labels、资源是否满足resources.requests -
Failed to pull image：镜像拉取失败，确认镜像名拼写、私有仓库 Secret 是否挂载、节点能否访问镜像仓库（如quay.io或k8s.gcr.io） -
Back-off restarting failed container：容器启动即退出，立刻用kubectl logs查日志，加--previous看上一次崩溃输出 -
MountVolume.SetUp failed：通常是hostPath路径不存在，或configmap/secret名字写错、未创建
跳过 kubectl 直接查节点本地组件状态
当 kubectl 本身不可用（比如 kube-apiserver 挂了），或 Pod 状态显示正常但集群无响应时，必须登录控制平面节点，绕过 API 直查底层服务。
依次执行：
-
systemctl status kubelet：如果inactive (dead)，整个节点已脱离集群；若报certificate has expired，说明证书过期（kubeadm 默认一年） -
docker ps -a | grep -E "(apiserver|controller-manager|scheduler)"（或crictl ps -a）：确认容器进程是否真在运行，状态是否为Exited -
journalctl -u kubelet -n 100 --no-pager：查最近 100 行 kubelet 日志，重点找failed to load KubeConfig、connection refused、etcd server连接失败等关键词 -
netstat -tlnp | grep :6443：验证kube-apiserver是否真监听了 6443 端口；若无输出，说明进程根本没起来
etcd 连接失败是最隐蔽的根因
很多组件（尤其是 kube-apiserver）启动后立即退出，日志里只有一句 context deadline exceeded 或 connection refused，但 etcd Pod 显示 Running ——这往往是因为 etcd 集群成员配置错误或网络不通，导致 apiserver 无法完成初始化。
验证方式：
- 进到 etcd 容器里（或用
etcdctl）执行：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 - 若返回
unhealthy，检查/etc/kubernetes/manifests/etcd.yaml中的--initial-cluster是否包含所有成员，IP 是否可路由，防火墙是否放行 2379/2380 端口 - 注意：kubeadm 初始化时若指定
--pod-network-cidr与节点实际网段冲突，会导致 etcd 成员间通信失败，但不会报明显错误
证书、etcd 成员列表、CNI 插件初始化顺序——这三个地方出问题，现象都类似“组件起不来”，但修复路径完全不同。别只盯着 Pod 状态，得一层层拆开看。
