排查 AKS 中的 DNS 解析问题

本文讨论如何创建用于修复 Microsoft Azure Kubernetes 服务（AKS）中域名系统（DNS）解析问题的故障排除工作流。

先决条件

• Kubernetes kubectl 命令行工具

  注意： 若要使用 Azure CLI 安装 kubectl，请运行 az aks install-cli 命令。

• 用于 DNS 查找的 dig 命令行工具

• 用于文本搜索的 grep 命令行工具

• Wireshark 网络数据包分析器

故障排除清单

排查 AKS 中的 DNS 问题通常是一个复杂的过程。 你可以轻松地在许多不同的步骤中迷失，而无需看到明确的前进道路。 为了帮助使过程更加简单有效，请使用“科学”方法组织工作：

• 步骤 1. 收集事实。

• 步骤 2. 制定假设。

• 步骤 3. 创建和实施行动计划。

• 步骤 4. 观察结果并得出结论。

• 步骤 5. 根据需要重复。

故障排除步骤 1：收集事实

若要更好地了解问题的上下文，请收集有关特定 DNS 问题的事实。 通过使用以下基线问题作为起点，可以描述问题的性质、识别症状和确定问题的范围。

若要获得这些问题的更好答案，请遵循这三部分过程。

第 1 部分：生成在不同层级重现问题的测试

AKS 上 Pod 的 DNS 解析过程包括许多层。 检查这些层以隔离问题。 以下层是典型的：

• CoreDNS Pod
• CoreDNS 服务
• 节点
• 虚拟网络 DNS

若要启动该过程，请针对每个层从测试 Pod 运行测试。

在 CoreDNS Pod 级别测试 DNS 解析

1. 通过运行以下命令部署测试 Pod 以运行 DNS 测试查询：

   cat <<EOF | kubectl apply --filename -
   apiVersion: v1
   kind: Pod
   metadata:
     name: aks-test
   spec:
     containers:
     - name: aks-test
       image: debian:stable
       command: ["/bin/sh"]
       args: ["-c", "apt-get update && apt-get install -y dnsutils && while true; do sleep 1000; done"]
   EOF
   

2. 通过运行以下 kubectl get 命令检索 CoreDNS Pod 的 IP 地址：

   kubectl get pod --namespace kube-system --selector k8s-app=kube-dns --output wide
   

3. 运行以下命令，使用 kubectl exec -it aks-test -- bash 命令连接到测试 Pod，并针对每个 CoreDNS Pod IP 地址测试 DNS 解析：

   # Placeholder values
   FQDN="<fully-qualified-___domain-name>"  # For example, "db.contoso.com"
   DNS_SERVER="<coredns-pod-ip-address>"
   
   # Test loop
   for i in $(seq 1 1 10)
   do
       echo "host= $(dig +short ${FQDN} @${DNS_SERVER})"
       sleep 1
   done
   

有关从 Pod 层面排查 DNS 解析问题的详细信息，请参阅 从 Pod 内部排查 DNS 解析失败。

在 CoreDNS 服务级别测试 DNS 解析

1. 运行以下命令 kubectl get 检索 CoreDNS 服务 IP 地址：

   kubectl get service kube-dns --namespace kube-system
   

2. 在测试 Pod 上，针对 CoreDNS 服务 IP 地址运行以下命令：

   # Placeholder values
   FQDN="<fully-qualified-___domain-name>"  # For example, "db.contoso.com"
   DNS_SERVER="<kubedns-service-ip-address>"
   
   # Test loop
   for i in $(seq 1 1 10)
   do
       echo "host= $(dig +short ${FQDN} @${DNS_SERVER})"
       sleep 1
   done
   

在节点级别测试 DNS 解析

1. 连接到节点。

2. grep运行以下命令，检索配置的上游 DNS 服务器的列表：

   grep ^nameserver /etc/resolv.conf
   

3. 针对节点中配置的每个 DNS 运行以下文本命令：

   # Placeholder values
   FQDN="<fully-qualified-___domain-name>"  # For example, "db.contoso.com"
   DNS_SERVER="<dns-server-in-node-configuration>"
   
   # Test loop
   for i in $(seq 1 1 10)
   do
       echo "host= $(dig +short ${FQDN} @${DNS_SERVER})"
       sleep 1
   done
   

在虚拟网络 DNS 级别测试 DNS 解析

检查虚拟网络的 DNS 服务器配置，并确定服务器是否可以解析相关的记录。

第 2 部分：查看 CoreDNS Pod 和节点的运行状况和性能

查看 CoreDNS Pod 的运行状况和性能

可以使用 kubectl 命令来检查 CoreDNS Pod 的运行状况和性能。 为此，请执行以下步骤：

1. 验证 CoreDNS Pod 是否正在运行：

   kubectl get pods -l k8s-app=kube-dns -n kube-system
   

2. 检查 CoreDNS Pod 是否被过度使用：

   kubectl top pods -n kube-system -l k8s-app=kube-dns
   

   NAME                      CPU(cores)   MEMORY(bytes)
   coredns-dc97c5f55-424f7   3m           23Mi
   coredns-dc97c5f55-wbh4q   3m           25Mi
   

3. 获取托管 CoreDNS Pod 的节点：

   kubectl get pods -n kube-system -l k8s-app=kube-dns -o jsonpath='{.items[*].spec.nodeName}'
   

4. 验证节点是否未过度使用：

   kubectl top nodes
   

5. 验证 CoreDNS Pod 的日志：

   kubectl logs -l k8s-app=kube-dns -n kube-system
   

查看节点的运行状况和性能

你可能会首先注意到 DNS 解析的性能问题，这些问题表现为间歇性错误，例如超时。 此问题的主要原因包括托管 CoreDNS Pod 或客户端 Pod 的节点内的资源耗尽和 I/O 限制。

若要检查资源耗尽或 I/O 限制是否发生，请运行以下 kubectl 描述 命令以及 grep 节点上的命令。 通过这一系列命令，可以查看请求计数，并将其与每个资源的限制进行比较。 如果资源的上限百分比超过100%，该资源就会出现过度分配。

kubectl describe node | grep -A5 '^Name:\|^Allocated resources:' | grep -v '.kubernetes.io\|^Roles:\|Labels:'

以下代码片段显示了此命令的示例输出：

Name:               aks-nodepool1-17046773-vmss00000m
--
Allocated resources:
  (Total limits might be more than 100 percent.)
  Resource           Requests           Limits
  --------           --------           ------
  cpu                250m (13 percent)  40m (2 percent)
  memory             420Mi (9 percent)  1762Mi (41 percent)
--
Name:               aks-nodepool1-17046773-vmss00000n
--
Allocated resources:
  (Total limits might be more than 100 percent.)
  Resource           Requests            Limits
  --------           --------            ------
  cpu                612m (32 percent)   8532m (449 percent)
  memory             804Mi (18 percent)  6044Mi (140 percent)
--
Name:               aks-nodepool1-17046773-vmss00000o
--
Allocated resources:
  (Total limits might be more than 100 percent.)
  Resource           Requests           Limits
  --------           --------           ------
  cpu                250m (13 percent)  40m (2 percent)
  memory             420Mi (9 percent)  1762Mi (41 percent)
--
Name:               aks-ubuntu-16984727-vmss000008
--
Allocated resources:
  (Total limits might be more than 100 percent.)
  Resource           Requests            Limits
  --------           --------            ------
  cpu                250m (13 percent)   40m (2 percent)
  memory             420Mi (19 percent)  1762Mi (82 percent)

若要更好地了解 Pod 和节点级别的资源使用情况，还可以在 Azure 中使用容器见解和其他云原生工具。 有关详细信息，请参阅 使用 Azure 服务和云本机工具监视 Kubernetes 群集。

第 3 部分：分析 DNS 流量并查看 DNS 解析性能

分析 DNS 流量有助于了解 AKS 群集如何处理 DNS 查询。 理想情况下，您应该在测试 Pod 上重现问题，同时捕获该测试 Pod 和每个 CoreDNS Pod 的流量。

可通过两种主要方法来分析 DNS 流量：

• 使用实时 DNS 分析工具（如 Inspektor 小工具）实时分析 DNS 流量。
• 使用流量捕获工具（如 Retina Capture 和 Dumpy）收集 DNS 流量，并使用网络数据包分析器工具（如 Wireshark）对其进行分析。

这两种方法旨在使用 DNS 响应代码、响应时间和其他指标了解 DNS 响应的运行状况和性能。 选择最符合需求的解决方案。

实时 DNS 流量分析

可以使用 Inspektor 小工具 实时分析 DNS 流量。 若要将 Inspektor 小工具安装到群集，请参阅 如何在 AKS 群集中安装 Inspektor 小工具。

若要跨所有命名空间跟踪 DNS 流量，请使用以下命令：

# Get the version of Gadget
GADGET_VERSION=$(kubectl gadget version | grep Server | awk '{print $3}')
# Run the trace_dns gadget
kubectl gadget run trace_dns:$GADGET_VERSION --all-namespaces --fields "src,dst,name,qr,qtype,id,rcode,latency_ns"

其中 --fields 要显示的字段的逗号分隔列表。 以下列表描述了命令中使用的字段：

• src：包含 Kubernetes 信息的请求源（<kind>/<namespace>/<name>:<port>）。
• dst：包含 Kubernetes 信息的请求目标（<kind>/<namespace>/<name>:<port>）。
• name：DNS 请求的名称。
• qr：查询/响应标志。
• qtype：DNS 请求的类型。
• id：DNS 请求的 ID，用于匹配请求和响应。
• rcode：DNS 请求的响应代码。
• latency_ns：DNS 请求的延迟。

命令输出如下所示：

SRC                                  DST                                  NAME                        QR QTYPE          ID             RCODE           LATENCY_NS
p/default/aks-test:33141             p/kube-system/coredns-57d886c994-r2… db.contoso.com.             Q  A              c215                                  0ns
p/kube-system/coredns-57d886c994-r2… 168.63.129.16:53                     db.contoso.com.             Q  A              323c                                  0ns
168.63.129.16:53                     p/kube-system/coredns-57d886c994-r2… db.contoso.com.             R  A              323c           NameErr…           13.64ms
p/kube-system/coredns-57d886c994-r2… p/default/aks-test:33141             db.contoso.com.             R  A              c215           NameErr…               0ns
p/default/aks-test:56921             p/kube-system/coredns-57d886c994-r2… db.contoso.com.             Q  A              6574                                  0ns
p/kube-system/coredns-57d886c994-r2… p/default/aks-test:56921             db.contoso.com.             R  A              6574           NameErr…               0ns

可以使用该 ID 字段来标识查询是否具有响应。 该 RCODE 字段显示 DNS 请求的响应代码。 该 LATENCY_NS 字段显示 DNS 请求的延迟（以纳秒为单位）。 这些字段可帮助你了解 DNS 响应的运行状况和性能。 有关实时 DNS 分析的详细信息，请参阅 实时排查 AKS 群集中的 DNS 故障。

捕获 DNS 流量

本部分演示如何使用 Dumpy 从每个 CoreDNS Pod 和客户端 DNS Pod 收集 DNS 流量捕获（在本例中为 aks-test Pod）。

若要从测试客户端 Pod 收集捕获，请运行以下命令：

kubectl dumpy capture pod aks-test -f "-i any port 53" --name dns-cap1-aks-test

若要收集 CoreDNS Pod 的数据，请运行以下 Dumpy 命令：

kubectl dumpy capture deploy coredns \
    -n kube-system \
    -f "-i any port 53" \
    --name dns-cap1-coredns

理想情况下，您应在问题重现时进行数据捕获。 这一要求意味着，不同的捕获过程可能会运行不同的时长，这具体取决于您能够复现问题的频率。 为了收集数据包，请运行以下命令：

mkdir dns-captures
kubectl dumpy export dns-cap1-aks-test ./dns-captures
kubectl dumpy export dns-cap1-coredns ./dns-captures -n kube-system

若要删除 Dumpy 的 Pod，请运行以下 Dumpy 命令：

kubectl dumpy delete dns-cap1-coredns -n kube-system
kubectl dumpy delete dns-cap1-aks-test

若要合并所有 CoreDNS Pod 捕获，请使用 mergecap 命令行工具合并捕获文件。 该工具 mergecap 包含在 Wireshark 网络数据包分析器工具中。 运行以下 mergecap 命令：

mergecap -w coredns-cap1.pcap dns-cap1-coredns-<coredns-pod-name-1>.pcap dns-cap1-coredns-<coredns-pod-name-2>.pcap [...]

单个 CoreDNS Pod 的 DNS 数据包分析

生成和合并流量捕获文件后，可以在 Wireshark 中对捕获文件执行 DNS 数据包分析。 按照以下步骤查看单个 CoreDNS Pod 流量的数据包分析：

1. 选择 “开始”，输入 Wireshark，然后在搜索结果中选择 Wireshark 。

2. 在 Wireshark 窗口中，选择 “文件” 菜单，然后选择“ 打开”。

3. 导航到包含捕获文件的文件夹，选择 dns-cap1-db-check-db-check-pod-name.pcap<>（单个 CoreDNS Pod 的客户端捕获文件），然后选择“打开”按钮。

4. 选择“ 统计信息 ”菜单，然后选择 DNS。 “Wireshark - DNS”对话框随即显示并显示对 DNS 流量的分析。 下表显示了对话框的内容。

   主题/项目	计数	平均值	Min Val	Max Val	速率（ms）	百分比	突发速率	快速启动
   ▾ 数据包总数	1066				0.0017	100%	0.1200	0.000
   ▾ rcode	1066				0.0017	100.00%	0.1200	0.000
   服务器故障	17				0.0000	1.59%	0.0100	99.332
   无此类名称	353				0.0006	33.11%	0.0400	0.000
   无错误	696				0.0011	65.29%	0.0800	0.000
   ▾操作码	1066				0.0017	100.00%	0.1200	0.000
   标准查询	1066				0.0017	100.00%	0.1200	0.000
   ▾ 查询/响应	1066				0.0017	100.00%	0.1200	0.000
   响应	531				0.0009	49.81%	0.0600	0.000
   查询	535				0.0009	50.19%	0.0600	0.000
   ▾ 查询类型	1066				0.0017	100.00%	0.1200	0.000
   AAAA	167				0.0003	15.67%	0.0200	0.000
   一个	899				0.0015	84.33%	0.1000	0.000
   ▾ 类	1066				0.0017	100.00%	0.1200	0.000
   在	1066				0.0017	100.00%	0.1200	0.000
   ▾ 服务统计信息	0				0.0000	100%	-	-
   request-response time （msec）	531	184.42	0.067000	6308.503906	0.0009		0.0600	0.000
   不。 未经请求的回复	0				0.0000		-	-
   不。 重传	0				0.0000		-	-
   ▾ 响应统计信息	0				0.0000	100%	-	-
   不。 一些问题	1062	1.00	1	1	0.0017		0.1200	0.000
   不。 当局	1062	0.82	0	1	0.0017		0.1200	0.000
   不。 答案	1062	0.15	0	1	0.0017		0.1200	0.000
   不。 附加项	1062	0.00	0	0	0.0017		0.1200	0.000
   ▾ 查询统计信息	0				0.0000	100%	-	-
   Qname Len	535	32.99	14	66	0.0009		0.0600	0.000
   ▾ 标签统计信息	0				0.0000		-	-
   第 4 级或更多级别	365				0.0006		0.0400	0.000
   第三级	170				0.0003		0.0200	0.000
   第二级	0				0.0000		-	-
   第 1 级	0				0.0000		-	-
   载荷大小	1066	92.87	32	194	0.0017	100%	0.1200	0.000

Wireshark 中的 DNS 分析对话框显示总共 1,066 个数据包。 在这些数据包中，17（1.59%）导致服务器故障。 此外，最大响应时间为 6,308 毫秒（6.3 秒），并且 0.38% 的查询未收到任何响应。 通过从包含查询的数据包的 50.19% 减去包含响应的数据包的 49.81% 来计算此总计。

如果在 Wireshark 中输入 (dns.flags.response == 0) && ! dns.response_in 为显示筛选器，此筛选器将显示未收到响应的 DNS 查询，如下表所示。

此外，Wireshark 状态栏显示文本 数据包：1066 - 显示：4 （0.4%）。 此信息意味着 1,066 个数据包（即 0.4%）中有 4 个是从未收到响应的 DNS 查询。 此百分比实质上与之前计算的 0.38% 总计匹配。

如果将显示筛选器更改为，该筛选器 dns.time >= 5将显示需要五秒或更多时间才能接收的查询响应数据包，如更新后的表所示。

更改显示筛选器后，状态栏将更新为显示文本数据包：1066 - 显示：8（0.8%）。 因此，1,066 个数据包（即 0.8%）中有 8 个是 DNS 响应，需要 5 秒或更多时间才能接收。 但是，在大多数客户端上，默认 DNS 超时值应为 5 秒。 此预期意味着，尽管 CoreDNS Pod 处理并传递了八个响应，但客户端已通过发出“超时”错误消息来结束会话。 筛选结果中的 “信息 ”列显示所有 8 个数据包都导致服务器故障。

所有 CoreDNS Pod 的 DNS 数据包分析

在 Wireshark 中，打开前面合并的 CoreDNS Pod 的捕获文件（coredns-cap1.pcap），然后打开 DNS 分析，如上一部分所述。 此时会显示一个“Wireshark”对话框，其中显示了下表。

该对话框表示总共有大约 450 万（4,540,233 个）数据包，其中 2.68% 导致服务器故障。 查询和响应数据包百分比的差异表明，5.94% 的查询（52.97% 减 47.03%）未收到响应。 最长响应时间为 12 秒（12,000.5322227 毫秒）。

如果您为查询响应应用了显示筛选器（处理时间为 5 秒或更长），dns.time >= 5那么筛选结果中的大多数数据包将显示服务器出现故障。 这可能是因为客户端“超时”错误。

下表汇总了捕获结果。

故障排除步骤 2：制定假设

本部分对常见问题类型进行分类，以帮助缩小潜在问题范围，并确定可能需要调整的组件。 此方法为创建有针对性的行动计划奠定了基础，以有效缓解和解决这些问题。

常见的 DNS 响应代码

下表汇总了最常见的 DNS 返回代码。

常规问题类型

下表列出了有助于分解问题症状的问题类型类别。

所需的输入

在提出问题可能原因的假设之前，请汇总故障排除工作流前面步骤的结果。

可以使用下表收集结果。

基线问卷模板的结果

不同级别的测试结果

节点和 CoreDNS Pod 的运行状况和性能结果

流量捕获和 DNS 解析性能的结果

将所需的输入映射到问题类型

若要开发第一个假设，请将每个结果从所需输入映射到一个或多个问题类型。 通过在问题类型上下文中分析这些结果，可以开发有关 DNS 解决问题的潜在根本原因的假设。 然后，可以创建有针对性的调查和故障排除的行动计划。

错误类型映射指针

• 如果测试结果显示 CoreDNS 服务的 DNS 解析失败，或者在尝试访问特定终结点时包含“超时”错误，则可能存在配置或连接问题。

• CoreDNS Pod 或节点级别的计算资源不足的指示可能表明性能问题。

• DNS 捕获在 DNS 查询和 DNS 响应之间存在相当大的不匹配，这可以指示数据包丢失。 此方案建议存在连接或性能问题。

• 在虚拟网络级别或 Kubernetes 级别存在的自定义配置可能包含一些设置，这些设置无法与 AKS 和 CoreDNS 正常工作。

故障排除步骤 3：创建和实施行动计划

现在，你应该有足够的信息来创建和实施行动计划。 以下部分包含为特定问题类型制定计划的额外建议。

性能问题

如果要处理 DNS 解决性能问题，请查看并实施以下最佳做法和指南。

如果进行这些更改后 DNS 性能仍然不够好，请考虑使用 节点本地 DNS。

配置问题

根据具体组件，您应审查并理解该特定设置的影响。 有关配置详细信息，请参阅以下特定于组件的文档列表：

• Kubernetes DNS 配置选项
• AKS CoreDNS 自定义配置选项
• 缺少虚拟网络链接的专用 DNS 区域

网络连接问题

• 涉及容器网络接口（CNI）或其他 Kubernetes 或 OS 组件的 Bug 通常需要 AKS 支持或 AKS 产品组的干预。

• 基础结构问题（如硬件故障或虚拟机监控程序问题）可能需要基础结构支持团队的协作。 或者，这些问题可能有自我修复功能。

故障排除步骤 4：观察结果并得出结论

观察实施行动计划的结果。 此时，你的行动计划应能够修复或缓解问题。

故障排除步骤 5：根据需要重复

如果这些故障排除步骤无法解决问题，请根据需要重复故障排除步骤。

第三方信息免责声明

本文讨论的第三方产品由独立于微软的公司制造。 Microsoft对这些产品的性能或可靠性不作任何明示或暗示的保证。

第三方联系人免责声明

为了帮助您获取有关此主题的更多信息，Microsoft 提供了第三方的联系信息。 该联系信息可能会在不通知的情况下更改。 微软不保证第三方联系信息的准确性。

联系我们以获得帮助

如果您有任何疑问或需要帮助，可以创建支持请求，或咨询Azure社区支持。 您还可以向Azure反馈社区提交产品反馈。