为什么K3s的Rancher DNS排障技巧仅在Busybox 1.28版本生效？

核心根因 #

该问题和K3s本身无关，是Busybox 1.29版本开始调整底层依赖和DNS解析逻辑导致的差异：

• Busybox 1.28及更早版本的官方镜像基于uClibc编译，其DNS解析逻辑和常见的glibc（Ubuntu、CentOS镜像采用的C库）行为一致：会读取Pod内/etc/resolv.conf的search域配置，对于点数少于ndots阈值的域名，会自动追加search后缀后再发起查询。Kubernetes默认给Pod注入的resolv.conf包含svc.cluster.local、cluster.local等搜索后缀，因此直接查询kubernetes.default时，会自动补全为kubernetes.default.svc.cluster.local，成功解析到集群服务IP。
• Busybox 1.29及后续版本的官方镜像切换为musl libc编译，musl的DNS解析逻辑做了特殊设计：只要查询的域名包含至少1个点，就不会自动追加search域，直接查询原始输入的域名。kubernetes.default包含1个点，因此不会补全后缀，单独的kubernetes.default不是有效域名，就会返回NXDOMAIN错误。此外musl libc不支持resolv.conf中的ndots参数，因此就算调整Pod的dnsConfig也无法兼容该行为。

验证方法 #

你可以在新版Busybox中执行以下命令验证解析逻辑正常：

kubectl run -it --rm --restart=Never busybox --image=busybox:1.33 -- nslookup kubernetes.default.svc.cluster.local

该命令会返回正常的解析结果，和1.28版本的表现一致。

测试方案选择 #

如果需要做集群DNS可用性测试，可以任选以下方案：

• 继续使用Busybox 1.28版本进行测试，和官方排障文档示例保持一致
• 使用新版Busybox时，直接查询完整的集群服务域名
• 选择Ubuntu、CentOS、Alpine这类基于glibc的镜像进行测试，行为更贴合Kubernetes默认DNS规则

内容的提问来源于stack exchange，提问作者Thib Guicherd-Callin