AKS 群集出站连接的基本故障排除

项目
12/18/2024

本文介绍如何对来自 Microsoft Azure Kubernetes 服务（AKS）群集的出站连接进行基本故障排除，以及如何识别故障组件。

先决条件

Kubernetes kubectl 工具或类似的工具连接到群集。若要使用 Azure CLI 安装 kubectl，请运行 az aks install-cli 命令。
用于处理包的 apt-get 命令行工具。
客户端 URL （cURL）工具或类似的命令行工具。
nslookup用于检查 DNS 解析的命令行（dnsutils）工具。

Azure Kubernetes 服务中的出站流量方案

源自 AKS 群集内的流量（无论是来自 Pod 还是工作器节点）被视为来自群集的出站流量。如果 AKS 群集的出站流出现问题，该怎么办？在进行故障排除之前，请先了解出站流量流的方案。

AKS 群集的出站流量可分为以下类别：

发到同一群集（内部流量）中的 Pod 或服务的流量。
发到同一虚拟网络中的设备或终结点的流量，或者使用虚拟网络对等互连的不同虚拟网络。
通过 VPN 连接或 Azure ExpressRoute 连接发送到本地环境的流量。
通过Azure 负载均衡器（公共出站流量）在 AKS 网络外部的流量。
通过 Azure 防火墙或代理服务器（公共出站流量）在 AKS 网络外部的流量。

内部流量

AKS 群集内部流量的基本请求流类似于下图所示的流。

通过Azure 负载均衡器的公共出站流量

如果流量用于 Internet 上的目标，则默认方法是通过Azure 负载均衡器发送流量。

通过Azure 防火墙或代理服务器的公共出站流量

在某些情况下，必须筛选出口流量，并且可能需要Azure 防火墙。

用户可能需要添加代理服务器而不是防火墙，或为出口流量设置 NAT 网关。基本流保持不变，如图所示。

请务必了解群集的出口流的性质，以便可以继续进行故障排除。

故障排除时的注意事项

检查出口设备

排查 AKS 中的出站流量问题时，请务必了解出口设备是什么（即流量通过的设备）。此处，出口设备可以是以下组件之一：

Azure 负载均衡器
Azure 防火墙或自定义防火墙
网络地址转换（NAT）网关
代理服务器

流也可能因目标而异。例如，内部流量（即群集内部）不会通过出口设备。内部流量仅使用群集网络。对于公共出站流量，请确定是否有出口设备通过并检查该设备。

检查流量流中的每个跃点

标识出口设备后，请检查以下因素：

请求的源和目标。
源和目标之间的跃点。
请求-响应流。
通过额外的安全层增强的跃点，例如以下层：
- 防火墙
- 网络安全组 (NSG)
- 网络策略

若要识别有问题的跃点，请在响应代码之前和之后检查响应代码。若要检查数据包是否正确到达特定跃点，可以继续执行数据包捕获。

检查 HTTP 响应代码

检查每个组件时，获取和分析 HTTP 响应代码。这些代码可用于识别问题的性质。在应用程序响应 HTTP 请求的情况下，这些代码特别有用。

从客户端和服务器获取数据包捕获

如果其他故障排除步骤不提供任何最终结果，请从客户端和服务器获取数据包捕获。当客户端和服务器之间涉及非 HTTP 流量时，数据包捕获也很有用。有关如何收集 AKS 环境的数据包捕获的详细信息，请参阅数据收集指南中的以下文章：

故障排除清单

有关来自 AKS 群集的出口流量的基本故障排除，请执行以下步骤：

确保终结点的域名系统 (DNS) 解析正常工作。
确保可以通过 IP 地址连接到终结点。
确保可以从另一个源访问终结点。
确保终结点正常工作。
检查群集是否可以连接到任何其他外部终结点。
检查网络策略是否阻止了流量。
检查 NSG 是否阻止了流量。
检查防火墙或代理是否阻止了流量。
检查 AKS 服务主体或托管标识是否具有对 Azure 资源进行网络更改所需的 AKS 服务权限。

注意

执行基本故障排除时，假设没有服务网格。如果使用服务网格（如 Istio），则会为基于 TCP 的流量生成异常结果。

检查 Pod 和节点是否可以访问终结点

在 pod 内部，可以对终结点运行 DNS 查找。

如果无法运行 kubectl exec 命令连接到 pod 并安装 DNS Utils 包，该怎么办？在这种情况下，可以在有问题的 pod 所在的同一命名空间中启动测试 pod，然后运行测试。

注意

如果 DNS 解析或出口流量不允许安装所需的网络包，你可以使用 rishasi/ubuntu-netutil:1.0 docker 映像。此映像中已安装所需的包。

检查 Linux Pod 的 DNS 解析的示例过程

在有问题的 pod 所在的同一命名空间中启动测试 pod：

kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "linux"}}}'

测试 pod 运行后，你可以访问该 pod。

运行以下 apt-get 命令安装其他工具包：

# Update and install tool packages
apt-get update && apt-get install -y dnsutils curl

安装包后，运行 nslookup 命令来测试终结点的 DNS 解析：

$ nslookup microsoft.com # Microsoft.com is used as an example
Server:         <server>
Address:        <server IP address>#53
...
...
Name:   microsoft.com
Address: 20.53.203.50

直接从上游 DNS 服务器尝试 DNS 解析。本示例使用 Azure DNS：

$ nslookup microsoft.com 168.63.129.16
Server:         168.63.129.16
Address:        168.63.129.16#53
...
...
Address: 20.81.111.85

有时，终结点本身而不是群集 DNS 存在问题。在这种情况下，请考虑以下检查：

检查是否在远程主机上打开所需的端口：
```
curl -Ivm5 telnet://microsoft.com:443
```
检查 HTTP 响应代码：
```
curl -Ivm5 https://microsoft.com
```
检查是否可以连接到任何其他终结点：
```
curl -Ivm5 https://kubernetes.io
```

若要验证终结点是否可从有问题的 Pod 所在的节点访问，然后验证 DNS 设置，请执行以下步骤：

输入有问题的 Pod 通过调试 Pod 进入的节点。有关如何执行此操作的详细信息，请参阅连接到Azure Kubernetes 服务（AKS）群集节点进行维护或故障排除。

测试终结点的 DNS 解析：

$ nslookup  microsoft.com
Server:         168.63.129.16
Address:        168.63.129.16#53

Non-authoritative answer:
Name:   microsoft.com
Address: 20.112.52.29
Name:   microsoft.com
Address: 20.81.111.85
Name:   microsoft.com
Address: 20.84.181.62
Name:   microsoft.com
Address: 20.103.85.33
Name:   microsoft.com
Address: 20.53.203.50

检查 resolv.conf 文件以确定是否添加了预期的名称服务器：
```
cat /etc/resolv.conf
cat /run/systemd/resolve/resolv.conf
```

检查 Windows Pod 的 DNS 解析的示例过程

在 Windows 节点池中运行测试 pod：

# For a Windows environment, use the Resolve-DnsName cmdlet.
kubectl run dnsutil-win --image='mcr.microsoft.com/windows/servercore:ltsc2022' --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "windows"}}}' -- powershell "Start-Sleep -s 3600"

使用 PowerShell 运行 kubectl exec 命令以连接到 pod：
```
kubectl exec -it dnsutil-win -- powershell
```

在 PowerShell 中运行 Resolve-DnsName cmdlet，检查终结点的 DNS 解析是否正常工作：

PS C:\> Resolve-DnsName www.microsoft.com 

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
www.microsoft.com              CNAME  20    Answer     www.microsoft.com-c-3.edgekey.net
www.microsoft.com-c-3.edgekey. CNAME  20    Answer     www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net
net
www.microsoft.com-c-3.edgekey. CNAME  20    Answer     e13678.dscb.akamaiedge.net
net.globalredir.akadns.net

Name       : e13678.dscb.akamaiedge.net 
QueryType  : AAAA
TTL        : 20
Section    : Answer
IP6Address : 2600:1408:c400:484::356e   


Name       : e13678.dscb.akamaiedge.net 
QueryType  : AAAA
TTL        : 20
Section    : Answer
IP6Address : 2600:1408:c400:496::356e 


Name       : e13678.dscb.akamaiedge.net
QueryType  : A
TTL        : 12
Section    : Answer
IP4Address : 23.200.197.152

在涉及 DNS 解析的异常方案中，DNS 查询从节点获取正确的响应，但从 Pod 失败。对于此方案，可以考虑从 Pod 内部检查 DNS 解析失败，但不检查工作器节点中的 DNS 解析失败。如果要检查群集中某个终结点的 DNS 解析，可以考虑检查群集中的 DNS 解析状态。

如果 DNS 解析成功，请继续执行网络测试。否则，请验证群集的 DNS 配置。

第三方联系人免责声明

Microsoft 会提供第三方联系信息来帮助你查找有关本主题的其他信息。此联系信息可能会更改，恕不另行通知。 Microsoft 不保证第三方联系信息的准确性。

联系我们寻求帮助

如果你有任何疑问或需要帮助，请创建支持请求或联系 Azure 社区支持。你还可以将产品反馈提交到 Azure 反馈社区。

通过