Kubernetes集群中CoreDNS组件Pending状态问题排查与解决

在Kubernetes集群部署过程中，CoreDNS组件出现Pending状态是一个常见问题。本文将深入分析该问题的成因，并提供详细的解决方案。

问题现象

当使用kubeadm部署Kubernetes集群（版本v1.30.10）并安装Flannel网络插件（版本v0.26.4）后，可能会出现以下症状：

1. 节点状态显示为NotReady
2. CoreDNS Pod处于Pending状态
3. 系统日志报错："runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady network plugin is not ready: cni config uninitialized"

根本原因分析

这个问题通常是由于CNI（容器网络接口）配置未正确初始化导致的。具体来说：

1. 网络插件初始化顺序问题：Flannel作为CNI插件需要完成初始化后才能为Pod提供网络功能
2. 运行时组件状态不同步：containerd等容器运行时可能缓存了旧的网络状态
3. 组件依赖关系：CoreDNS依赖集群网络正常工作，而网络又依赖CNI插件

解决方案

经过实践验证，以下步骤可以有效解决问题：

1. 确认Flannel Pod已正常运行：

   kubectl get pods -n kube-system
   

2. 重启containerd服务以刷新网络状态：

   systemctl restart containerd
   

3. 观察CoreDNS状态变化（通常在1分钟内会变为Running状态）：

   watch kubectl get pods -n kube-system
   

深入理解

这个解决方案有效的原理在于：

1. 状态刷新：重启containerd会强制重新加载CNI配置，确保网络插件的最新状态被正确识别
2. 依赖关系重建：重启运行时组件会重建与kubelet的网络通信通道
3. 初始化顺序重置：给系统一个重新协调组件启动顺序的机会

预防措施

为避免类似问题再次发生，建议：

1. 在安装网络插件后，主动重启容器运行时服务
2. 按照正确的顺序部署组件：先确保网络插件正常运行，再部署CoreDNS等依赖网络的组件
3. 监控集群事件日志，及时发现网络初始化问题

总结

Kubernetes集群部署是一个复杂的过程，各组件之间存在严格的依赖关系。理解这些依赖关系并掌握基本的故障排查方法，对于维护稳定的Kubernetes环境至关重要。通过本文介绍的方法，可以有效解决因CNI配置未初始化导致的CoreDNS Pending状态问题。