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

项目
11/20/2024

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

先决条件

Kubernetes kubectl 工具或类似的工具连接到群集。若要使用 Azure CLI 安装 kubectl，请运行 az aks install-cli 命令。
用于处理包的 apt-get 命令行工具。
客户端 URL （cURL）工具或类似的命令行工具。
用于 DNS 查找的主机命令行工具。
用于 TCP 连接的 Netcat （nc）命令行工具。
用于将路由数据包的跟踪打印到网络主机的跟踪路由命令行工具。

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

在任何网络方案中，在进行故障排除时，应考虑以下因素：

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

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

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

如果知道如何获取 HTTP 响应代码并捕获数据包，则更容易排查网络连接问题。

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

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

同一群集中 Pod 或服务的流量（内部流量）
发到同一虚拟网络或不同虚拟网络中的设备或终结点的流量（使用虚拟网络对等互连）
通过 VPN 连接或 Azure ExpressRoute 连接发送到本地环境的流量
AKS 网络外部的流量（公共出站流量）

本文档介绍影响出站连接的问题的基本故障排除步骤：

在群集中
在虚拟网络中
向外界（公共交通）

在 AKS 中对出站流量进行故障排除时，了解出口设备（即流量通过的设备）也很重要。此处，出口设备可以是以下组件之一：

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

流也可能因目标而异。例如，内部流量（即群集内部）不会通过出口设备。内部流量仅使用群集网络。

内部流量

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

通过Azure 负载均衡器的外部流量

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

通过Azure 防火墙或代理服务器的外部流量

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

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

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

故障排除清单

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

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

检查终结点的 DNS 解析是否成功

在 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 命令安装其他工具包：

apt-get update -y   
apt-get install -y dnsutils && apt-get install netcat-traditional -y && apt-get install curl -y

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

$ nslookup microsoft.com
Server:         10.0.0.10
Address:        10.0.0.10#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

运行 host 命令来检查 DNS 请求是否路由到上游服务器：

$ host -a microsoft.com
Trying "microsoft.com.default.svc.cluster.local"
Trying "microsoft.com.svc.cluster.local"
Trying "microsoft.com.cluster.local"
Trying "microsoft.com.00idcnmrrm4edot5s2or1onxsc.bx.internal.cloudapp.net"
Trying "microsoft.com"
Trying "microsoft.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62884
;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 0, ADDITIONAL: 5

;; QUESTION SECTION:
;microsoft.com.                 IN      ANY

;; ANSWER SECTION:
microsoft.com.          30      IN      NS      ns1-39.azure-dns.com.
...
...
ns4-39.azure-dns.info.  30      IN      A       13.107.206.39

Received 2121 bytes from 10.0.0.10#53 in 232 ms

下面是检查 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 设置。执行以下步骤：

连接到 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
```

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

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

检查群集是否可以通过网络访问终结点

若要确定是否可以通过群集通过网络访问终结点，请执行以下步骤：

检查到终结点的路由，以确定特定操作是否有超时：

kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "linux"}}}'
apt-get update -y
apt-get install -y traceroute && apt-get install netcat-traditional -y && apt-get install curl -y
traceroute -T microsoft.com -m 50 -p 443

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

第三方联系人免责声明

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

联系我们寻求帮助

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

通过