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

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

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

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

确保安装了最新版本。

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

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

az extension update --name connectedk8s

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

az extension add --name connectedk8s

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

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

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

如果一切正常，则 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，你可以对这两个参数使用 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>

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

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

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

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

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

   kubectl run -it --rm test-pod --namespace <namespace> --image=debian:stable
   

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

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

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

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

   $ nslookup microsoft.com
   Server:         10.0.0.10
   Address:        10.0.0.10#53
   ...
   ...
   Name:   microsoft.com
   Address: 20.53.203.50
   

4. 直接从上游 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
   

5. 运行 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
   

6. 在 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"
   

7. 使用 PowerShell 运行 kubectl exec 命令以连接到 pod：

   kubectl exec -it dnsutil-win -- powershell
   

8. 在 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 的过程。