1.引言
- 问题描述：搭建公司的k8s集群组件的监控，发现CoreDNS的 NoDomain请求奇高，是正常请求的两倍。很明显其中存在问题，TroubleShooting，启动！
-
介绍 CoreDNS：
Kubernetes 默认的 DNS 服务，CoreDNS 负责集群内服务发现。
-
什么是 NoDomain 错误？
NS 服务器无法解析查询的域名。
-
常见场景
- 访问某些服务时，CoreDNS 返回 NXDOMAIN 错误（不存在的域名）。
- 在日志中看到 NoDomain，通常伴随有大量类似错误。
2.问题排查和分析
求教gpt，有以下几个分析思路，仅供参考
-
查看 CoreDNS 日志
- 通过 kubectl logs 查看 CoreDNS 日志，找出具体的 NoDomain 错误信息。
- 检查日志中的模式和异常。
-
检查 DNS 配置
- 分析 CoreDNS 配置文件 /etc/coredns/Corefile 是否正确。
- 检查是否有配置错误或域名解析服务（如外部 DNS）不可用。
-
网络连接问题
- 验证 CoreDNS 与外部 DNS 服务器的网络连接是否畅通。
- 使用 dig 或 nslookup 命令进行手动查询验证。
-
集群 DNS 配置
- 确保 Kubernetes 的 DNS 配置正确，检查 kube-dns 或 CoreDNS 的服务端点和端口是否正确。
实际排查过程中，在coredns日志中发现形如 google.com.ns_a.svc.cluster.local NXDomain 错误。
我们知道，请求svc的DNS服务地址格式是<svc>.<namespace>.svc.cluster.local，很明显上述日志说明，我们的请求域名被错误进行拼接了，进一步看下这是如何发生的。
通过coredns的日志中ip，通过kubectl get po -A -owide |grep <IP>，查出错误请求的容器。
进入容器后，执行命令cat /etc/resolv.conf。注意以下内容：options ndots:5
options ndots作用：它定义了“点号” (.) 数量从而控制域名解析的行为，这很抽象，不太好理解我试着举例说明。
对于这个域名 app.monitor.svc.cluster.local.，注意local后面还有“点号”，它包含五个“点号”，视为完全合格的域名（FQDN）。CoreDNS将其当做完整域名解析。
如果域名包含少于 5 个点号，则会使用搜索域来尝试完成查询。这通常意味着它会追加一个或多个域名后缀来完成查询，直到成功解析。上图中search后，即为可能得搜索域。因此才会出现 形如
google.com.ns_a.svc.cluster.local NXDomain错误。
我们如何修改options ndots取值呢。
4.解决方案
推荐把所有命名空间下的编排（deploy/statefulset/daemonset）都加上这个配置。 attemps：dns解析请求次数。
ndots：推荐至少设置4，或者更少，如果服务仅仅访问集群内svc，并遵守规范app.monitor.svc.cluster.local。刚好4 dots满足FQDN。
timeout：超时时间1s。
dnsConfig:
options:
- name: attempts
value: "2"
- name: ndots
value: "4"
- name: timeout
value: "1"
参考以下脚本：
spec:
template:
spec:
dnsConfig:
options:
- name: attempts
value: "2"
- name: ndots
value: "4"
- name: timeout
value: "1"
kubectl get deployments -n cc_ns -o json | jq -r '.items[].metadata.name' | while read deployment; do
kubectl patch deployment "$deployment" -n cc_ns -p '{
"spec": {
"template": {
"spec": {
"dnsConfig": {
"options": [
{ "name": "attempts", "value": "2" },
{ "name": "ndots", "value": "4" },
{ "name": "timeout", "value": "1" }
]
}
}
}
}
}' --type=merge
done
