Diagnostizieren von Verbindungsproblemen für Kubernetes-Cluster mit Azure Arc-Unterstützung

  • Artikel

Wenn Probleme beim Verbinden eines Clusters mit Azure Arc auftreten, liegt dies wahrscheinlich an einem der hier aufgeführten Probleme. Wir stellen zwei Flussdiagramme mit Hilfestellungen bereit: eins für den Fall, dass Sie keinen Proxyserver verwenden, und eins für den Fall, dass Ihre Netzwerkverbindung einen Proxyserver verwendet.

Tipp

Die Schritte in diesem Flussdiagramm gelten unabhängig davon, ob Sie die Azure CLI oder Azure PowerShell verwenden, um eine Verbindung mit Ihrem Cluster herzustellen. Für einige Schritte ist jedoch die Verwendung der Azure CLI erforderlich. Wenn Sie die Azure CLI noch nicht installiert haben, holen Sie das unbedingt nach, bevor Sie beginnen.

Verbindungen ohne Proxy

Diagnostizieren Sie mithilfe dieses Flussdiagramms Ihr Problem, wenn Sie versuchen, einen Cluster ohne Proxyserver mit Azure Arc zu verbinden. Weitere Einzelheiten zu den einzelnen Schritten finden Sie im Anschluss.

Flussdiagramm: Visuelle Darstellung der Prüfung auf Verbindungsprobleme, wenn kein Proxy verwendet wird

Verfügt die Azure-Identität über ausreichende Berechtigungen?

Überprüfen Sie die Voraussetzungen für die Verbindung mit einem Cluster, und stellen Sie sicher, dass die Identität, die Sie zum Herstellen einer Verbindung mit dem Cluster verwenden, über die erforderlichen Berechtigungen verfügt.

Verwenden Sie die neueste Version der Azure-Befehlszeilenschnittstelle?

Stellen Sie sicher, dass Sie die neueste Version installiert haben.

Wenn Sie Ihren Cluster mithilfe von Azure PowerShell verbunden haben, stellen Sie sicher, dass Sie die aktuelle Version ausführen.

Verwenden Sie die aktuelle Version der connectedk8s-Erweiterung?

Aktualisieren Sie die Azure CLI-Erweiterung connectedk8s auf die neueste Version, indem Sie den folgenden Befehl ausführen:

az extension update --name connectedk8s

Wenn Sie die Erweiterung noch nicht installiert haben, können Sie dazu den folgenden Befehl ausführen:

az extension add --name connectedk8s

Verweist kubeconfig auf den richtigen Cluster?

Führen Sie kubectl config get-contexts aus, um den Namen des Zielkontexts zu bestätigen. Legen Sie dann den Standardkontext auf den richtigen Cluster fest, indem Sie kubectl config use-context <target-cluster-name> ausführen.

Sind alle erforderlichen Ressourcenanbieter registriert?

Stellen Sie sicher, dass die Ressourcenanbieter Microsoft.Kubernetes, Microsoft.KubernetesConfiguration und Microsoft.ExtendedLocation registriert sind.

Sind alle Netzwerkanforderungen erfüllt?

Überprüfen Sie die Netzwerkanforderungen, und stellen Sie sicher, dass keine erforderlichen Endpunkte blockiert werden.

Werden alle Pods im azure-arc-Namespace ausgeführt?

Wenn alles ordnungsgemäß funktioniert, sollten sich Ihre Pods im Zustand Running befinden. Führen Sie kubectl get pods -n azure-arc aus, um zu überprüfen, ob der Zustand eines Pods nicht Running lautet.

Treten weiterhin Probleme auf?

Mit den oben genannten Schritten können viele allgemeine Verbindungsprobleme behoben werden. Wenn Sie jedoch immer noch keine Verbindung herstellen können, generieren Sie eine Problembehandlungsprotokolldatei, und öffnen Sie dann eine Supportanfrage, damit wir das Problem weiter untersuchen können.

Führen Sie den folgenden Befehl aus, um die Protokolldatei zur Problembehandlung zu generieren:

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

Wenn Sie eine Supportanfrage erstellen, verwenden Sie im Abschnitt Zusätzliche Details die Option Dateiupload, um die generierte Protokolldatei hochzuladen.

Verbindungen mit einem Proxyserver

Wenn Sie auf mindestens einem Computer einen Proxyserver verwenden, führen Sie die ersten fünf Schritte des Flussdiagramms für das Szenario ohne Proxyserver (über die Registrierung des Ressourcenanbieters) aus. Dies sind grundlegende Schritte zur Problembehandlung. Sollten dann weiterhin Probleme auftreten, finden Sie im nächsten Flussdiagramm weitere Schritte zur Problembehandlung. Weitere Einzelheiten zu den einzelnen Schritten finden Sie im Anschluss.

Flussdiagramm: Visuelle Darstellung der Prüfung auf Verbindungsprobleme, wenn ein Proxy verwendet wird

Führt der Computer Befehle hinter einem Proxyserver aus?

Wenn der Computer Befehle hinter einem Proxyserver ausführt, müssen Sie alle erforderlichen Umgebungsvariablen festlegen. Informationen finden Sie unter Herstellen einer Verbindung mithilfe eines ausgehenden Proxyservers.

Beispiel:

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

Akzeptiert der Proxyserver nur vertrauenswürdige Zertifikate?

Achten Sie darauf, dass Sie den Zertifikatdateipfad einschließen, indem Sie --proxy-cert <path-to-cert-file> beim Ausführen des Befehls az connectedk8s connect einfügen.

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

Kann der Proxyserver die erforderlichen Netzwerkendpunkte erreichen?

Überprüfen Sie die Netzwerkanforderungen, und stellen Sie sicher, dass keine erforderlichen Endpunkte blockiert werden.

Verwendet der Proxyserver nur HTTP?

Wenn Ihr Proxyserver nur HTTP verwendet, können Sie proxy-http für beide Parameter verwenden.

Wenn Ihr Proxyserver sowohl mit HTTP als auch mit HTTPS eingerichtet ist, führen Sie den Befehl az connectedk8s connect aus, und geben Sie dabei die Parameter --proxy-https und --proxy-http an. Stellen Sie sicher, dass Sie --proxy-http für den HTTP-Proxy und --proxy-https für den HTTPS-Proxy verwenden.

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>

Erfordert der Proxyserver Auslassungsbereiche für die Kommunikation zwischen Diensten?

Wenn Sie Auslassungsbereiche benötigen, verwenden Sie --proxy-skip-range <excludedIP>,<excludedCIDR> im Befehl az connectedk8s connect.

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>

Werden alle Pods im azure-arc-Namespace ausgeführt?

Wenn alles ordnungsgemäß funktioniert, sollten sich Ihre Pods im Zustand Running befinden. Führen Sie kubectl get pods -n azure-arc aus, um zu überprüfen, ob der Zustand eines Pods nicht Running lautet.

Überprüfen, ob die DNS-Auflösung für den Endpunkt erfolgreich ist

Innerhalb des Pods können Sie eine DNS-Suche für den Endpunkt ausführen.

Was geschieht, wenn Sie den Befehl kubectl exec nicht ausführen können, um eine Verbindung mit dem Pod herzustellen und das DNS Utils-Paket zu installieren? In diesem Fall können Sie einen Testpod im selben Namespace wie der problematische Pod starten und dann die Tests ausführen.

Hinweis

Wenn die DNS-Auflösung oder der ausgehende Datenverkehr die Installation der erforderlichen Netzwerkpakete verhindert, können Sie das Docker-Image rishasi/ubuntu-netutil:1.0 verwenden. In diesem Image sind die erforderlichen Pakete bereits installiert.

Hier ist ein Beispiel für die Überprüfung der DNS-Auflösung:

  1. Starten Sie einen Testpod im selben Namespace wie der problematische Pod:

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

    Sobald der Testpod ausgeführt wird, erhalten Sie Zugriff auf den Pod.

  2. Führen Sie die folgenden apt-get-Befehle aus, um andere Toolpakete zu installieren:

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

  3. Führen Sie nach der Installation der Pakete den Befehl nslookup aus, um die DNS-Auflösung für den Endpunkt zu testen:

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

  4. Probieren Sie die DNS-Auflösung vom Upstream-DNS-Server direkt aus. In diesem Beispiel wird Azure DNS verwendet:

    $ nslookup microsoft.com 168.63.129.16
Server:         168.63.129.16
Address:        168.63.129.16#53
...
...
Address: 20.81.111.85

  5. Führen Sie den Befehl host aus, um zu überprüfen, ob die DNS-Anforderungen an den Upstreamserver weitergeleitet werden:

    $ 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

  6. Führen Sie einen Testpod im Windows-Knotenpool aus:

    # 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. Führen Sie den Befehl kubectl exec aus, um mithilfe von PowerShell eine Verbindung mit dem Pod herzustellen:

    kubectl exec -it dnsutil-win -- powershell

  8. Führen Sie das Cmdlet Resolve-DnsName in PowerShell aus, um zu überprüfen, ob die DNS-Auflösung für den Endpunkt funktioniert:

    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

Wenn die DNS-Auflösung nicht erfolgreich ist, überprüfen Sie die DNS-Konfiguration für den Cluster.

Treten weiterhin Probleme auf?

Mit den oben genannten Schritten können viele allgemeine Verbindungsprobleme behoben werden. Wenn Sie jedoch immer noch keine Verbindung herstellen können, generieren Sie eine Problembehandlungsprotokolldatei, und öffnen Sie dann eine Supportanfrage, damit wir das Problem weiter untersuchen können.

Führen Sie den folgenden Befehl aus, um die Protokolldatei zur Problembehandlung zu generieren:

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

Wenn Sie eine Supportanfrage erstellen, verwenden Sie im Abschnitt Zusätzliche Details die Option Dateiupload, um die generierte Protokolldatei hochzuladen.

Nächste Schritte