CoreDNS 自定义域名失效问题\"
发布时间：2025-02-26 点击：13
来自专辑
k8s训练营摘录
前几天我们在解决 coredns 的5秒超时问题的时候，使用了 nodelocal dnscache 来解决这个问题，集群 dns 的解析性能也明显大幅提升了。但是今天确遇到一个很大的坑，我们在做 devops 实验的时候，相关的工具都使用的是自定义的域名，这个时候要互相访问的话就需要添加自定义的域名解析，我们可以通过给 pod 添加 hostalias 来解决，但是在使用 jenkins 的 kubernetes 插件的时候却不支持这个参数，需要使用 yaml 来自定义，比较麻烦，所以想着通过 coredns 来添加 a 记录解决这个问题。
正常我们只需要在 coredns 的 configmap 中添加 hosts 插件就可以使用了：
hosts { 10.151.30.11 git.k8s.local fallthrough}
但是在配置完成后，始终解析不了这个自定义的域名：
$ kubectl run -it –image busybox:1.28.4 test –restart=never –rm /bin/shif you don\\\’t see a command prompt, try pressing enter./ # nslookup git.k8s.localserver: 169.254.20.10address 1: 169.254.20.10nslookup: can\\\’t resolve \\\’git.k8s.local\\\’
这有点奇怪，难道 hosts 插件不能这样使用吗？在经过一番查阅过后确信这样配置是正确的方式。然后将 coredns 的日志开启，来过滤上面域名的解析日志：
可以看到走了一遍 search 域，但是没有获取到正确的解析结果，这就有点不解了。在折腾了一番过后，想到我们在集群中启用了 nodelocaldnscache，难道是这个组件导致的吗？这个不是解析没有命中的时候会转发到 coredns 查询吗？
为了验证这个问题，我们就直接使用 coredns 的地址来进行解析测试一番：
/ # nslookup git.k8s.local 10.96.0.10server: 10.96.0.10address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.localname: git.k8s.localaddress 1: 10.151.30.11 git.k8s.local
发现居然是正确的，那也就说明 coredns 的配置是没有任何问题的，问题肯定就是 nodelocaldnscache 导致的，直接用 localdns 的地址（169.254.20.10）解析发现确实是失败的：
/ # nslookup git.k8s.local 169.254.20.10server: 169.254.20.10address 1: 169.254.20.10nslookup: can\\\’t resolve \\\’git.k8s.local\\\’
这个时候只能去查看 localdns 的 pod 日志了：
$ kubectl logs -f node-local-dns-bb84m -n kube-system……2020/05/14 05:30:21 [info] updated corefile with 0 custom stubdomains and upstream servers /etc/resolv.conf2020/05/14 05:30:21 [info] using config file:cluster.local:53 { errors cache { success 9984 30 denial 9984 5 } reload loop bind 169.254.20.10 10.96.0.10 forward . 10.96.207.156 { force_tcp } prometheus :9253 health 169.254.20.10:8080 }in-addr.arpa:53 { errors cache 30 reload loop bind 169.254.20.10 10.96.0.10 forward . 10.96.207.156 { force_tcp } prometheus :9253 }ip6.arpa:53 { errors cache 30 reload loop bind 169.254.20.10 10.96.0.10 forward . 10.96.207.156 { force_tcp } prometheus :9253 }.:53 { errors cache 30 reload loop bind 169.254.20.10 10.96.0.10 forward . /etc/resolv.conf { force_tcp } prometheus :9253 }……[info] plugin/reload: running configuration md5 = 3e3833f9361872f1d34bc97155f952cacoredns-1.6.7linux/amd64, go1.11.13,
仔细分析上面的 localdns 的配置信息，其中 10.96.0.10 为 coredns 的 service clusterip，169.254.20.10 为 localdns 的 ip 地址，10.96.207.156 是 localdns 新建的一个 service clusterip，该 service 和 coredns 一样都是关联以前的 coredns 的 endpoints 列表。
仔细观察可以发现 cluster.local、 in-addr.arpa 以及 ip6.arpa 都会通过 forward 转发到 10.96.207.156，也就是去 coredns 解析，其他的则是 forward./etc/resolv.conf 通过 resolv.conf 文件去解析，该文件的内容如下所示：
nameserver 169.254.20.10search default.svc.cluster.local svc.cluster.local cluster.localoptions ndots:5
所以当我们解析域名 git.k8s.local 的时候需要走一遍搜索域，而 cluster.local 的域名是直接 forward 到 coredns 解析的，coredns 自然解析不出来这几天记录了。那么我们是不是自然可以想到把 hosts 插件配置在 localdns 这边不就可以了吗？这种思路应该是完全正确的：
$ kubectl edit cm node-local-dns -n kube-system…….:53 { errors hosts { # 添加 a 记录 10.151.30.11 git.k8s.local fallthrough } cache 30 reload loop bind 169.254.20.10 10.96.0.10 forward . __pillar__upstream__servers__ { force_tcp } prometheus :9253}……
更新完成后，我们可以手动重建 nodelocaldns pod，重建过后发现 nodelocaldns 的 pod 启动失败了，会出现如下所示的错误信息：
no action found for directive \\\’hosts\\\’ with server type \\\’dns\\\’
原来压根就不支持 hosts 这个插件。那么我们就只有去 coredns 解析了，所以这个时候我们需要把 forward./etc/resolv.conf 更改成 forward.10.96.207.156，这样就会去 coredns 解析了，在 nodelocaldns 的 configmap 中做如下的修改即可：
$ kubectl edit cm node-local-dns -n kube-system…….:53 { errors cache 30
为什么网站显示腾讯云服务器错误
云服务器价格计算器
想退掉这个空间-虚拟主机/数据库问题
中国云服务器哪个好用吗
短视频内容运营方法论
vps云服务器linux搭建网站
什么云主机最好
服务器硬件配置该如何进行选择呢?
k8s训练营摘录
前几天我们在解决 coredns 的5秒超时问题的时候，使用了 nodelocal dnscache 来解决这个问题，集群 dns 的解析性能也明显大幅提升了。但是今天确遇到一个很大的坑，我们在做 devops 实验的时候，相关的工具都使用的是自定义的域名，这个时候要互相访问的话就需要添加自定义的域名解析，我们可以通过给 pod 添加 hostalias 来解决，但是在使用 jenkins 的 kubernetes 插件的时候却不支持这个参数，需要使用 yaml 来自定义，比较麻烦，所以想着通过 coredns 来添加 a 记录解决这个问题。
正常我们只需要在 coredns 的 configmap 中添加 hosts 插件就可以使用了：
hosts { 10.151.30.11 git.k8s.local fallthrough}
但是在配置完成后，始终解析不了这个自定义的域名：
$ kubectl run -it –image busybox:1.28.4 test –restart=never –rm /bin/shif you don\\\’t see a command prompt, try pressing enter./ # nslookup git.k8s.localserver: 169.254.20.10address 1: 169.254.20.10nslookup: can\\\’t resolve \\\’git.k8s.local\\\’
这有点奇怪，难道 hosts 插件不能这样使用吗？在经过一番查阅过后确信这样配置是正确的方式。然后将 coredns 的日志开启，来过滤上面域名的解析日志：
可以看到走了一遍 search 域，但是没有获取到正确的解析结果，这就有点不解了。在折腾了一番过后，想到我们在集群中启用了 nodelocaldnscache，难道是这个组件导致的吗？这个不是解析没有命中的时候会转发到 coredns 查询吗？
为了验证这个问题，我们就直接使用 coredns 的地址来进行解析测试一番：
/ # nslookup git.k8s.local 10.96.0.10server: 10.96.0.10address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.localname: git.k8s.localaddress 1: 10.151.30.11 git.k8s.local
发现居然是正确的，那也就说明 coredns 的配置是没有任何问题的，问题肯定就是 nodelocaldnscache 导致的，直接用 localdns 的地址（169.254.20.10）解析发现确实是失败的：
/ # nslookup git.k8s.local 169.254.20.10server: 169.254.20.10address 1: 169.254.20.10nslookup: can\\\’t resolve \\\’git.k8s.local\\\’
这个时候只能去查看 localdns 的 pod 日志了：
$ kubectl logs -f node-local-dns-bb84m -n kube-system……2020/05/14 05:30:21 [info] updated corefile with 0 custom stubdomains and upstream servers /etc/resolv.conf2020/05/14 05:30:21 [info] using config file:cluster.local:53 { errors cache { success 9984 30 denial 9984 5 } reload loop bind 169.254.20.10 10.96.0.10 forward . 10.96.207.156 { force_tcp } prometheus :9253 health 169.254.20.10:8080 }in-addr.arpa:53 { errors cache 30 reload loop bind 169.254.20.10 10.96.0.10 forward . 10.96.207.156 { force_tcp } prometheus :9253 }ip6.arpa:53 { errors cache 30 reload loop bind 169.254.20.10 10.96.0.10 forward . 10.96.207.156 { force_tcp } prometheus :9253 }.:53 { errors cache 30 reload loop bind 169.254.20.10 10.96.0.10 forward . /etc/resolv.conf { force_tcp } prometheus :9253 }……[info] plugin/reload: running configuration md5 = 3e3833f9361872f1d34bc97155f952cacoredns-1.6.7linux/amd64, go1.11.13,
仔细分析上面的 localdns 的配置信息，其中 10.96.0.10 为 coredns 的 service clusterip，169.254.20.10 为 localdns 的 ip 地址，10.96.207.156 是 localdns 新建的一个 service clusterip，该 service 和 coredns 一样都是关联以前的 coredns 的 endpoints 列表。
仔细观察可以发现 cluster.local、 in-addr.arpa 以及 ip6.arpa 都会通过 forward 转发到 10.96.207.156，也就是去 coredns 解析，其他的则是 forward./etc/resolv.conf 通过 resolv.conf 文件去解析，该文件的内容如下所示：
nameserver 169.254.20.10search default.svc.cluster.local svc.cluster.local cluster.localoptions ndots:5
所以当我们解析域名 git.k8s.local 的时候需要走一遍搜索域，而 cluster.local 的域名是直接 forward 到 coredns 解析的，coredns 自然解析不出来这几天记录了。那么我们是不是自然可以想到把 hosts 插件配置在 localdns 这边不就可以了吗？这种思路应该是完全正确的：
$ kubectl edit cm node-local-dns -n kube-system…….:53 { errors hosts { # 添加 a 记录 10.151.30.11 git.k8s.local fallthrough } cache 30 reload loop bind 169.254.20.10 10.96.0.10 forward . __pillar__upstream__servers__ { force_tcp } prometheus :9253}……
更新完成后，我们可以手动重建 nodelocaldns pod，重建过后发现 nodelocaldns 的 pod 启动失败了，会出现如下所示的错误信息：
no action found for directive \\\’hosts\\\’ with server type \\\’dns\\\’
原来压根就不支持 hosts 这个插件。那么我们就只有去 coredns 解析了，所以这个时候我们需要把 forward./etc/resolv.conf 更改成 forward.10.96.207.156，这样就会去 coredns 解析了，在 nodelocaldns 的 configmap 中做如下的修改即可：
$ kubectl edit cm node-local-dns -n kube-system…….:53 { errors cache 30
为什么网站显示腾讯云服务器错误
云服务器价格计算器
想退掉这个空间-虚拟主机/数据库问题
中国云服务器哪个好用吗
短视频内容运营方法论
vps云服务器linux搭建网站
什么云主机最好
服务器硬件配置该如何进行选择呢?