K3s-Ansible部署中DNS解析故障排查与解决方案

问题现象分析

在使用k3s-ansible部署Kubernetes集群时，用户遇到了一个典型的DNS解析问题：Pod内部无法解析集群内服务域名(如kubernetes.default.svc)和外部域名(如google.com)，而节点主机上却能正常解析。这种症状表明集群的CoreDNS服务虽然正常运行，但Pod与DNS服务之间的网络通信存在异常。

根本原因定位

经过排查发现，问题的根源在于IP地址段冲突。用户的主机网络配置为10.42.42.1/24，这与K3s默认使用的Service CIDR(10.43.0.0/16)和Pod CIDR(10.42.0.0/16)产生了潜在冲突。特别是10.42.x.x段与主机网络重叠，导致网络路由混乱。

技术背景说明

在Kubernetes集群中，CoreDNS作为集群DNS服务运行，负责处理以下类型的域名解析：

1. 集群内服务解析(如service.namespace.svc.cluster.local)
2. 外部域名解析(如互联网域名)

当Pod无法访问CoreDNS时，通常需要检查：

• 网络插件(如flannel/calico)是否正常工作
• iptables/nftables规则是否正确
• 网络地址空间是否冲突

解决方案实施

用户采取的解决措施非常有效：

1. 将主机网络改为非冲突段(10.43.43.1/24)
2. 确保与K3s的默认网络段无重叠：
   • Service CIDR: 10.43.0.0/16
   • Pod CIDR: 10.42.0.0/16

最佳实践建议

对于使用k3s-ansible部署集群的用户，建议：

1. 预先规划网络架构

   • 主机网络使用独立地址段(如192.168.x.x/24)
   • 确认与K3s默认网络不冲突

2. 自定义网络配置 在ansible配置中明确指定网络参数：

   k3s_service_cidr: "10.43.0.0/16"
   k3s_cluster_cidr: "10.42.0.0/16"
   

3. 部署后验证

   • 使用busybox或alpine镜像测试DNS解析
   • 检查CoreDNS Pod日志
   • 验证网络插件状态

深度排查方法

若遇到类似问题，可按以下步骤排查：

1. 检查CoreDNS服务状态

   kubectl get pods -n kube-system -l k8s-app=kube-dns
   

2. 验证DNS服务端点

   kubectl get endpoints kube-dns -n kube-system
   

3. 测试Pod网络连通性

   kubectl run net-test --image=nicolaka/netshoot --command -- sleep infinity
   kubectl exec -it net-test -- curl -I http://10.43.0.10:53
   

4. 检查网络插件日志

   kubectl logs -n kube-system -l app=flannel
   

通过系统化的网络规划和严谨的验证流程，可以避免这类DNS解析问题的发生，确保Kubernetes集群的稳定运行。