Kubernetes集群中Calico与DNS的循环依赖问题分析与解决

问题现象

在Kubernetes生产环境中，我们经常会遇到一些微妙的组件间依赖问题。近期在一个使用Kubespray部署的Kubernetes集群中，发现部分节点出现DNS解析异常的情况。具体表现为：

1. 节点上的Pod无法解析域名
2. CoreDNS服务IP（10.233.0.3）无响应
3. 部分节点的calico-node Pod处于异常状态（ImagePullBackOff或Pending）

根本原因分析

经过深入排查，发现这是一个典型的循环依赖问题：

1. DNS依赖网络：CoreDNS服务需要通过Calico提供的网络功能才能正常工作
2. 网络依赖DNS：Calico-node Pod启动时需要拉取镜像，而镜像拉取又依赖DNS解析
3. 系统配置固化：Kubespray将/etc/systemd/resolved.conf中的DNS服务器硬编码为CoreDNS的服务IP(10.233.0.3)

当某些节点的calico-node Pod因故无法启动时，会导致网络功能缺失，进而使CoreDNS不可用。而CoreDNS不可用又导致calico-node无法拉取镜像，形成死循环。

解决方案

临时解决方案

对于已经出现问题的节点，可以采取以下步骤恢复：

1. 验证系统DNS解析配置：

   systemctl status systemd-resolved
   ls -l /etc/resolv.conf
   

2. 修改系统DNS配置： 编辑/etc/systemd/resolv.conf，在原有CoreDNS IP前添加可靠的公共DNS：

   DNS=1.1.1.1 10.233.0.3
   

3. 重启DNS服务：

   systemctl restart systemd-resolved
   

4. 等待calico-node Pod恢复：

   kubectl get pods -n kube-system -l k8s-app=calico-node -w
   

5. 恢复原始DNS配置（可选）： 确认网络功能正常后，可以移除临时添加的公共DNS。

长期预防措施

1. 配置备用DNS：在Kubespray配置中设置备用DNS服务器

   resolvconf_extra_dns_servers:
     - 1.1.1.1
     - 8.8.8.8
   

2. 镜像缓存：在节点上预先缓存calico相关镜像

   ctr -n k8s.io images pull docker.io/calico/node:v3.24.1
   

3. 健康检查：设置calico-node的readinessProbe，确保网络就绪后才提供服务

4. 资源预留：为系统组件预留足够资源，避免因资源不足导致Pod启动失败

技术原理深入

Kubernetes网络架构

在Kubernetes中，网络功能由CNI插件实现。Calico作为流行的CNI插件，负责：

1. 为Pod分配IP地址
2. 实现Pod间网络通信
3. 提供网络策略功能

DNS解析流程

Kubernetes中的DNS解析流程如下：

1. Pod内的应用发起DNS查询
2. 查询被重定向到节点配置的DNS服务器（通常是CoreDNS）
3. CoreDNS根据集群配置进行解析

系统级DNS配置

systemd-resolved是Linux系统上的DNS解析管理器，其特点包括：

1. 支持多DNS服务器配置
2. 具有缓存功能
3. 可以通过/etc/systemd/resolved.conf进行配置

经验总结

在Kubernetes集群运维中，组件间的依赖关系需要特别关注。对于这类"先有鸡还是先有蛋"的问题，建议：

1. 设计系统时考虑启动顺序和依赖关系
2. 关键组件应该有降级方案或备用路径
3. 监控系统应该能够检测这类循环依赖问题
4. 文档中应该明确记录各组件的依赖关系

通过这次问题的解决，我们更加理解了Kubernetes核心组件间的微妙关系，这对今后设计高可用集群架构有重要指导意义。