CoreDNS hosts插件缺行配置,导致整个集群异常

Kuberentes 环境中 CoreDNS 是一个基础服务，他提供外部域名、Service名称、POD名称等资源的 DNS 解析功能。CoreDNS 可以通过插件来进行功能扩展，但是如果对插件配置使用不当，可能会引起整个集群的故障。

问题背景

问题背景是在一次 argocd 服务的部署场景中，安装完后总是提示 argocd-redis 连接不上，服务名无法解析。而 argocd-redis 就是和 argocd helmchart 一起部署的一个组件，并在同一个 Namespace 中。

# kubectl  -n argocd logs -f argocd-server-56748df646-cmnjv......redis: 2026/09/09 03:08:04 pool.go:715: redis: connection pool: failed to dial after 5 attempts: dial tcp: lookup argocd-redis on 10.43.0.10:53: server misbehavingtime="2026-09-09T03:08:04Z" level=warning msg="Reconnect to redis because error: \"dial tcp: lookup argocd-redis on 10.43.0.10:53: server misbehaving\""

分析阶段

根据错误提示，问题方向应该是 argocd-server 服务访问 redis 的 service 名称进行域名解析时网络异常，或者 CoreDNS 本身异常。

首先分析的 CoreDNS 本身是否异常，我尝试使用 CoreDNS 的 ClusterIP 作为 DNS 服务器解析我配置的一条 hosts 静态解析，发现 CoreDNS 解析功能正常。

[root@openeuler100 ~]#  dig -q registry-local.cncfstack.com @10.43.0.10 +short192.168.1.100

这时还没有意识到问题就在这里，缺少 Kubernetes Service 域名进行解析验证。

之后查看 CoreDNS 的自身日志，也没有异常

[root@openeuler100 ~]# kubectl  -n kube-system logs rke2-coredns-rke2-coredns-659b8fb74b-mjbvnmaxprocs: Updating GOMAXPROCS=1: using minimum allowed GOMAXPROCS.:53[INFO] plugin/reload: Running configuration SHA512 = 8ddb920c44cdb2ea9739bb839367dce3c606218288682d235afb136b108331bf3e841310cd49aa1180936b6da52f1e9b46f5c0cfc3dcf42250394ffbed16ffccCoreDNS-1.14.6linux/amd64, go1.25.12 X:boringcrypto, 424d12577

然后就去分析网络问题，验证路由是否正确、分析 Iptables、NetworkManager 影响， 分析 NetworkPolicy 影响等等，还是没有找到问题原因。

根因确定

就在一天中午吃完饭，打开一局 LOL 对局时，突然想到：使用 CoreDNS hosts 模块时好像有插件顺序和 fallthrough 配置要求。

赶紧打开电脑继续分析，在意识到 CoreDNS 插件有顺序要求时，立马看下了 Corefile 的配置文件

[root@openeuler100 ~]# kubectl  -n kube-system get cm rke2-coredns-rke2-coredns -o yamlapiVersion: v1data:  Corefile: |-    .:53 {        errors        health {            lameduck 10s        }        hosts {            192.168.1.100 registry-local.cncfstack.com        }        ready        kubernetes  cluster.local  in-addr.arpa ip6.arpa {            pods insecure            fallthrough in-addr.arpa ip6.arpa            ttl 30        }        prometheus  0.0.0.0:9153        forward  . /etc/resolv.conf        cache  30        loop        reload        loadbalance    }kind: ConfigMap

果然，hosts 插件 在 kubernetes 上面，这是我才想起来验证 Service 域名解析的问题的问题。

argocd-redis 的服务运行正常，日志没有报错，但就是无法解析

[root@openeuler100 ~]# dig argocd-redis.argocd.cluster.local @10.43.0.10; <<>> DiG 9.20.21 <<>> argocd-redis.argocd.cluster.local @10.43.0.10;; global options: +cmd;; Got answer:;; WARNING: .local is reserved for Multicast DNS;; You are currently testing what happens when an mDNS query is leaked to DNS;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36787;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1;; WARNING: recursion requested but not available;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 1232; COOKIE: af2575f3f760bae5 (echoed);; QUESTION SECTION:;argocd-redis.argocd.cluster.local. IN    A;; Query time: 0 msec;; SERVER: 10.43.0.10#53(10.43.0.10) (UDP);; WHEN: Wed Sep 09 11:04:38 CST 2026;; MSG SIZE  rcvd: 74

我就尝试注释掉 hosts 插件的配置，之后发现 service 域名解析正常，那这基本确认就是 hosts 插件引起的。

结合之前的经验， CoreDNS 功能由一系列插件组成，这些插件按顺序形成一条处理链， 默认从配置文件上到下依次执行插件。因为如果 hosts 模块在上面，在 hosts 模块配置有问题时插件链不继续执行，Kubernetes service 域名解析插件就无法生效。

这次就是因为 hosts 插件缺少 fallthrough 配置导致的。当 hosts 插件无法找到某个域名的匹配记录时，如果没有配置 fallthrough 就是返回解析失败，但是如果配置了 fallthrough 就会把这次查询传递给链中的下一个插件（例如 kubernetes 插件，或者 forward 插件）继续解析。

解决方法

找到问题的原因，解决方法就简单了。hosts 是我专门添加用来解析自定义域名的，所以 hosts 插件需要保留。

那就给 hosts 插件添加fallthrough配置，为了防止以后手动修改 hosts 出现啥问题，我还将 hosts 模块放在 Kubernetes 模块后面。

[root@openeuler100 ~]#  kubectl  -n kube-system get cm  rke2-coredns-rke2-coredns -o yamlapiVersion: v1data:  Corefile: |-    .:53 {        errors        health {            lameduck 10s        }        ready        kubernetes  cluster.local  in-addr.arpa ip6.arpa {            pods insecure            fallthrough in-addr.arpa ip6.arpa            ttl 30        }        hosts {            192.168.1.100 registry-local.cncfstack.com            fallthrough        }        prometheus  0.0.0.0:9153        forward  . /etc/resolv.conf        cache  30        loop        reload        loadbalance    }kind: ConfigMap

之后再验证，自定义域名、Kubernets Service 服务名、外部域名解析都正常。argocd 的服务也正常了，问题算是解决好了。

总结

这次遇到的问题处理的效率有点低，从事后来看这个问题本来是我早就知道的技术点 CoreDNS的插件有顺序要求，hosts需要fallthrough配置，结果还要靠 顿悟。

按照之前不使用AI辅助的习惯，这种问题的分析思路应该是：

1. 1. argocd-server 日志明确提示 argocd-redis 服务名无法解析，在 argocd-server 验证其他域名是否可以正常解析，比如 registry-local.cncfstack.com 可以解析，但 kubernetes.default.svc.cluster.local 无法解析。结论：CoreDNS Servcie 域名解析异常。
2. 2. 查看 CoreDNS 日志，日志没有报错。查看 Corefile 配置文件，发现与默认配置项目多了 hosts 插件配置。
3. 3. 查看 CoreDNS hosts插件官网文档^[1] ，就会在插件介绍的最前面有句话

If you want to pass the request to the rest of the plugin chain if there is no match in the hosts plugin, you must specify the fallthrough option.

这次是和 DeepSeek 一起分析的，我提供了背景、日志、配置等信息，它也提供了很多验证方法，但并没有准确找到问题点，反而浪费了大量的时间。

反思：思想懒惰，强依赖AI帮我分析。

另外开源项目最靠谱的资料还是源码和官网，你有多久没有访问开源项目的官网了？

引用链接

[1] CoreDNS hosts插件官网文档: https://coredns.website.cncfstack.com/plugins/hosts/