排查 Azure Kubernetes 服务上 CoreDNS 的问题（AKS）

本文提供有关 Azure Kubernetes 服务（AKS）上各种 CoreDNS 问题的故障排除指南。

排查 DNS 解析问题

如需了解常规 CoreDNS 故障排除步骤（例如检查终结点或解析），请参阅调试 DNS 解析。

对 CoreDNS Pod 流量不平衡进行故障排除

你可能会看到一两个 CoreDNS Pod 的 CPU 使用率明显高于其他 Pod，处理更多的 DNS 查询，即使在 AKS 群集中运行的多个 CoreDNS Pod 也是如此。这是 Kubernetes 中的一个已知问题，可能会导致其中一个 CoreDNS Pod 过载和崩溃。

DNS 查询分布不均衡主要是由 Kubernetes 中的用户数据报协议（UDP）负载均衡限制引起的。平台使用五元组哈希（源 IP、源端口、目标 IP、目标端口、协议）来分发 UDP 流量，因此，如果应用程序重复使用同一源端口进行 DNS 查询，则来自该客户端的所有查询将路由到同一 CoreDNS Pod。此分发方法可能会导致单个 Pod 处理不成比例的流量。此外，某些应用程序使用连接池并重复使用 DNS 连接。此行为可以进一步将 DNS 查询集中在单个 CoreDNS Pod 上，从而增加过载和潜在崩溃的风险。

以下部分可帮助你排查和缓解此问题。

启用 DNS 查询日志记录

启用 DNS 查询日志记录以从 CoreDNS Pod 捕获所需的 DNS 查询日志。

将以下配置添加到 coredns-custom ConfigMap：

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  log.override: | # You can select any name here, but it must end with the .override file extension
        log

使用 kubectl apply configmap 命令应用 ConfigMap 更改。
```
kubectl apply -f corednsms.yaml
```
执行滚动重启以重新加载 ConfigMap，并使 Kubernetes 计划程序无需停机即可使用 kubectl rollout restart 命令重启 CoreDNS。
```
kubectl --namespace kube-system rollout restart deployment coredns
```
使用 kubectl logs 命令查看 CoreDNS 调试日志记录。
```
kubectl logs --namespace kube-system -l k8s-app=kube-dns
```

检查 CoreDNS Pod 流量分布

使用 kubectl get pods 命令获取群集中所有 CoreDNS Pod 的名称。
```
kubectl get pods --namespace kube-system -l k8s-app=kube-dns
```
查看每个 CoreDNS Pod 的日志，以使用 kubectl logs 命令分析 DNS 查询模式。对所有 CoreDNS Pod 重复此命令，将 <coredns-pod-x> 替换为实际的 Pod 名称。
```
kubectl logs --namespace kube-system <coredns-pod-x>
```
在输出中，查找仅在单个 CoreDNS Pod 的日志中出现的重复客户端 IP 地址和端口。这表示某些客户端的 DNS 查询未均匀分布。

日志输出示例：
```
[INFO] 10.244.0.247:5556 - 42621 "A IN myservice.default.svc.cluster.local. udp 28" NOERROR qr,aa,rd 106 0.000141s
```
在这个示例日志条目中：
- 10.244.0.247 是发出 DNS 查询的客户端 IP 地址。
- 5556 是客户端源端口。
- 42621 是查询 ID。
如果在一个 Pod 的日志中重复看到相同的客户端 IP 和端口，这将确认流量不平衡。

缓解 CoreDNS Pod 流量不平衡

如果您注意到负载不平衡，可能是应用程序正在重用 UDP 源端口或共享其连接。根据根本原因，可以采取以下缓解措施：

由 UDP 源端口重用引起的：当客户端应用程序从同一 UDP 源端口发送多个 DNS 查询时，将发生 UDP 源端口重用。如果出现此问题，请更新应用程序或 DNS 客户端以随机化每个 DNS 查询的源端口，这有助于在 Pod 之间更均匀地分配请求。
由于连接池：连接池是一种机制，使应用程序能够重用现有的网络连接，而无需为每个请求创建新的连接。虽然这样可以提高效率，但可能会导致应用程序的所有 DNS 查询通过同一连接发送，从而路由到同一 CoreDNS Pod。若要缓解此问题，请通过减少连接生存时间（TTL）或随机创建连接来调整应用程序的 DNS 连接处理，确保查询不集中在单个 CoreDNS Pod 上。

这些更改有助于实现更均衡的 DNS 查询分发，并降低重载单个 Pod 的风险。

排查 internal.chinacloudapp.cn 和 reddog.microsoft.com 的搜索域完成无效问题

Azure DNS 使用 Azure DNS 配置虚拟网络（VNet）的默认搜索域 <VNET_ID>.<REGION>.internal.chinacloudapp.cn ，并使用自定义 DNS 服务器在 VNet 中配置非功能存根 reddog.microsoft.com 。有关详细信息，请参阅资源文档的名称解析。

Kubernetes 使用 ndots: 5 配置 Pod DNS 设置，以正确支持群集服务主机名解析。这两种配置组合在一起，导致在系统通过域搜索列表处理时永远不会成功发送到上游名称服务器的搜索域完成查询无效。这些无效的查询会导致名称解析延迟，并可能给上游 DNS 服务器带来额外的负载。

从 v20241025 AKS 版本开始，AKS 将 CoreDNS 配置为在以下情况下进行响应 NXDOMAIN ，以防止这些无效的搜索域完成查询转发到上游 DNS：

针对根域或 reddog.microsoft.com 的子域的任何查询。
针对域名中具有 7 个或更多标签的 internal.chinacloudapp.cn 的子域的任何查询。
- 此配置允许主机名的虚拟机（VM）解析仍然成功。例如，CoreDNS 将（aks12345.myvnetid.myregion.internal.chinacloudapp.cn 个标签）发送到 Azure DNS，但拒绝mcr.azk8s.cn.myvnetid.myregion.internal.chinacloudapp.cn（8 个标签）。

此块在群集 CoreFile 的默认服务器块中实现。如果需要，可以通过为启用转发插件的相应域创建自定义服务器块来禁用此拒绝配置：

在以下示例配置中创建一个名为 corednsms.yaml 并粘贴的文件。请确保使用自己的值更新 IP 地址和主机名。

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom # This is the name of the ConfigMap you can overwrite with your changes
  namespace: kube-system
data:
    override-block.server:
       internal.chinacloudapp.cn:53 {
           errors
           cache 30
           forward . /etc/resolv.conf
       }
       reddog.microsoft.com:53 {
           errors
           cache 30
           forward . /etc/resolv.conf
       }

使用 kubectl apply configmap 命令创建 ConfigMap。
```
kubectl apply -f corednsms.yaml
```
执行滚动重启以重新加载 ConfigMap，并使 Kubernetes 计划程序无需停机即可使用 kubectl rollout restart 命令重启 CoreDNS。
```
kubectl --namespace kube-system rollout restart deployment coredns
```

解决 CoreDNS 自动缩放问题

若要排查 CoreDNS 自动缩放问题，请参阅 Azure Kubernetes 服务（AKS）中的自动缩放 CoreDNS。

Last updated on 2025-10-30

Compartir a través de