诊断已启用 Azure Arc 的 Kubernetes 群集的连接问题
如果你在将群集连接到 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>
创建支持请求时，请在“其他详细信息”部分使用“文件上传”选项上传生成的日志文件。