包包和糖葫芦1. 现象观察：当CoreDNS卡在Pending状态时发生了什么
刚部署完Kubernetes集群的新手经常会遇到一个经典问题：执行完kubeadm init后，满怀期待地输入kubectl get pods -n kube-system，却发现CoreDNS的状态一直显示Pending。更糟的是，用kubectl get nodes查看节点状态，Master和Worker节点都显示NotReady。这种场景就像你买了一台新电脑，开机后却发现连最基本的文件管理器都打不开。
我最近在帮朋友搭建测试环境时就遇到了完全一样的情况。当时我们按照官方文档一步步操作，初始化过程看似顺利，直到检查系统组件时才发现异常。具体现象表现为：
- CoreDNS Pod始终处于Pending状态，无法转为Running
- 节点状态持续显示NotReady
- 通过
kubectl describe pod查看事件，会发现类似"0/1 nodes available: 1 node(s) had taint"的警告 - 检查节点描述时会出现关键错误信息："NetworkReady=false reason:NetworkPluginNotReady"
这种状况通常发生在安装Flannel网络插件之后。很多人以为执行了kubectl apply -f kube-flannel.yml就万事大吉，实际上底层还缺少关键组件。就像组装电脑时插上了显卡却忘了装驱动，硬件识别了但无法正常工作。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 逐层排查：从表面现象到底层原因
2.1 第一步：检查Pod事件详情
当发现问题时，我首先会查看CoreDNS Pod的详细状态。这个操作相当于电脑蓝屏时查看错误日志：
bash复制kubectl describe pod coredns-7ff77c879f-xxxxx -n kube-system
在Events部分，通常会看到两类关键信息：
- 调度失败提示："0/1 nodes available: 1 node(s) had taint..."
- 网络未就绪警告："network plugin is not ready"
这些信息说明Pod调度本身没有问题，问题出在节点网络准备阶段。就像快递送到了你家门口，却发现门锁坏了