诊断已启用 Azure Arc 的 Kubernetes 群集的连接问题

Artículo
06/24/2024

如果你在将群集连接到 Azure Arc 时遇到问题，原因也许与下面列出的问题之一有关。我们提供了两个带有引导式帮助的流程图：一个适用于未使用代理服务器的情况，另一个适用于网络连接使用代理服务器的情况。

提示

无论你是使用 Azure CLI 还是 Azure PowerShell 来连接群集，此流程图中的步骤都适用。但是，某些步骤需要使用 Azure CLI。如果你尚未安装 Azure CLI，请务必在开始之前安装。

不使用代理的连接

查看此流程图，以诊断在不使用代理服务器的情况下尝试将群集连接到 Azure Arc 时遇到的问题。下面提供了有关每个步骤的更多详细信息。

Azure 标识是否拥有足够的权限？

查看连接群集的先决条件，并确保用于连接群集的标识拥有必要的权限。

是否正在运行最新版本的 Azure CLI？

确保安装了最新版本。

如果使用 Azure PowerShell 连接了群集，请确保运行最新版本。

`connectedk8s` 扩展是否为最新版本？

运行以下命令将 Azure CLI connectedk8s 扩展更新到最新版本：

az extension update --name connectedk8s

如果尚未安装该扩展，可以运行以下命令来安装：

az extension add --name connectedk8s

kubeconfig 是否指向正确的群集？

运行 kubectl config get-contexts 以确认目标上下文名称。然后，运行 kubectl config use-context <target-cluster-name> 将默认上下文设置为正确的群集。

是否注册了所有必需的资源提供程序？

确保已注册 Microsoft.Kubernetes、Microsoft.KubernetesConfiguration 和 Microsoft.ExtendedLocation 资源提供程序。

是否满足所有网络要求？

查看网络要求，并确保未阻止所需的终结点。

`azure-arc` 命名空间中的所有 Pod 是否都在运行？

如果一切正常，则 Pod 应全部处于 Running 状态。运行 kubectl get pods -n azure-arc 以确认是否有任何 Pod 的状态不是 Running。

仍有问题？

上述步骤可以解决许多常见连接问题，但如果你仍然无法成功连接，请生成故障排除日志文件，然后提交支持请求，以便我们进一步调查问题。

若要生成故障排除日志文件，请运行以下命令：

az connectedk8s troubleshoot -g <myResourceGroup> -n <myK8sCluster>

创建支持请求时，请在“其他详细信息”部分使用“文件上传”选项上传生成的日志文件。

使用代理服务器的连接

如果你在至少一台计算机上使用代理服务器，请完成无代理流程图的前五个步骤（通过资源提供程序注册）以执行基本的故障排除步骤。然后，如果仍然遇到问题，请查看下一个流程图以了解其他故障排除步骤。下面提供了有关每个步骤的更多详细信息。

计算机是否在代理服务器后面执行命令？

如果计算机在代理服务器后面执行命令，则需要设置所有必要的环境变量。有关详细信息，请参阅使用出站代理服务器进行连接。

例如：

export HTTP_PROXY="http://<proxyIP>:<proxyPort>"
export HTTPS_PROXY="https://<proxyIP>:<proxyPort>"
export NO_PROXY="<cluster-apiserver-ip-address>:<proxyPort>"

代理服务器是否仅接受受信任的证书？

运行 az connectedk8s connect 命令时，请确保通过包含 --proxy-cert <path-to-cert-file> 来包含证书文件路径。

az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-cert <path-to-cert-file>

代理服务器是否能够访问所需的网络终结点？

查看网络要求，并确保未阻止所需的终结点。

代理服务器是否仅使用 HTTP？

如果代理服务器仅使用 HTTP，你可以对这两个参数使用 proxy-http。

如果为代理服务器同时设置了 HTTP 和 HTTPS，请运行 az connectedk8s connect 命令并指定 --proxy-https 和 --proxy-http 参数。确保为 HTTP 代理使用 --proxy-http，并为 HTTPS 代理使用 --proxy-https。

az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-https https://<proxy-server-ip-address>:<port> --proxy-http http://<proxy-server-ip-address>:<port>

代理服务器是否需要对服务间通信使用跳过范围？

如果需要使用跳过范围，请在 az connectedk8s connect 命令中使用 --proxy-skip-range <excludedIP>,<excludedCIDR>。

az connectedk8s connect --name <cluster-name> --resource-group <resource-group> --proxy-https https://<proxy-server-ip-address>:<port> --proxy-http http://<proxy-server-ip-address>:<port> --proxy-skip-range <excludedIP>,<excludedCIDR>

`azure-arc` 命名空间中的所有 Pod 是否都在运行？

如果一切正常，则 Pod 应全部处于 Running 状态。运行 kubectl get pods -n azure-arc 以确认是否有任何 Pod 的状态不是 Running。

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

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

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

注意

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

下面是检查 DNS 解析的示例过程：

在有问题的 pod 所在的同一命名空间中启动测试 pod：
```
kubectl run -it --rm test-pod --namespace <namespace> --image=debian:stable
```
测试 pod 运行后，你可以访问该 pod。

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

apt-get update -y
apt-get install dnsutils -y
apt-get install curl -y
apt-get install netcat -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.chinacloudapp.cn"
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：

# For a Windows environment, use the Resolve-DnsName cmdlet.
kubectl run dnsutil-win --image='mcr.microsoft.com/windows/servercore:1809' --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 配置。

仍有问题？

上述步骤可以解决许多常见连接问题，但如果你仍然无法成功连接，请生成故障排除日志文件，然后提交支持请求，以便我们进一步调查问题。

若要生成故障排除日志文件，请运行以下命令：

az connectedk8s troubleshoot -g <myResourceGroup> -n <myK8sCluster>

创建支持请求时，请在“其他详细信息”部分使用“文件上传”选项上传生成的日志文件。

后续步骤

查看有关使用已启用 Azure Arc 的 Kubernetes 的更多故障排除提示。
查看将现有 Kubernetes 群集连接到 Azure Arc 的过程。

Compartir a través de

诊断已启用 Azure Arc 的 Kubernetes 群集的连接问题

不使用代理的连接

Azure 标识是否拥有足够的权限？

是否正在运行最新版本的 Azure CLI？

`connectedk8s` 扩展是否为最新版本？

kubeconfig 是否指向正确的群集？

是否注册了所有必需的资源提供程序？

是否满足所有网络要求？

`azure-arc` 命名空间中的所有 Pod 是否都在运行？

仍有问题？

使用代理服务器的连接

计算机是否在代理服务器后面执行命令？

代理服务器是否仅接受受信任的证书？

代理服务器是否能够访问所需的网络终结点？

代理服务器是否仅使用 HTTP？

代理服务器是否需要对服务间通信使用跳过范围？

`azure-arc` 命名空间中的所有 Pod 是否都在运行？

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

仍有问题？

后续步骤

Recursos adicionales

Compartir a través de

诊断已启用 Azure Arc 的 Kubernetes 群集的连接问题

不使用代理的连接

Azure 标识是否拥有足够的权限？

是否正在运行最新版本的 Azure CLI？

connectedk8s 扩展是否为最新版本？

kubeconfig 是否指向正确的群集？

是否注册了所有必需的资源提供程序？

是否满足所有网络要求？

azure-arc 命名空间中的所有 Pod 是否都在运行？

仍有问题？

使用代理服务器的连接

计算机是否在代理服务器后面执行命令？

代理服务器是否仅接受受信任的证书？

代理服务器是否能够访问所需的网络终结点？

代理服务器是否仅使用 HTTP？

代理服务器是否需要对服务间通信使用跳过范围？

azure-arc 命名空间中的所有 Pod 是否都在运行？

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

仍有问题？

后续步骤

Recursos adicionales

`connectedk8s` 扩展是否为最新版本？

`azure-arc` 命名空间中的所有 Pod 是否都在运行？

`azure-arc` 命名空间中的所有 Pod 是否都在运行？