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

如果在将群集连接到 Azure Arc 时遇到问题，问题很可能是本文中列出的问题之一。 两个流程图提供引导式帮助：一个适用于不 使用代理服务器的情况，另一个则适用于网络连接 使用代理服务器的情况。

不使用代理的连接

查看此流程图，在尝试在没有代理服务器的情况下将群集连接到 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>"

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

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

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 参数。 使用--proxy-http作为HTTP代理和--proxy-https作为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 解析的示例过程：

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