Teilen über


Behandeln von Problemen mit der Plattform für Kubernetes-Cluster mit Azure Arc-Unterstützung

Dieses Dokument enthält Anleitungen zur Problembehandlung bei Problemen mit der Konnektivität, den Berechtigungen und den Agents von Kubernetes mit Azure Arc-Unterstützung. Außerdem werden Leitfäden zur Problembehandlung für Azure GitOps bereitgestellt, die entweder in Kubernetes-Clustern mit Azure Arc-Unterstützung oder Azure Kubernetes Service-Clustern (AKS) verwendet werden können.

Hilfe bei der Behebung von Problemen im Zusammenhang mit Erweiterungen wie GitOps (Flux v2), Azure Monitor Container Insights, Open Service Mesh finden Sie unter Behebung von Problemen mit Erweiterungen für Kubernetes-Cluster mit Azure Arc-Unterstützung.

Azure CLI

Stellen Sie vor der Verwendung von az connectedk8s- oder az k8s-configuration-CLI-Befehlen sicher, dass Azure CLI so eingestellt ist, dass es mit dem richtigen Azure-Abonnement funktioniert.

az account set --subscription 'subscriptionId'
az account show

Wenn ein Fehler wie cli.azext_connectedk8s.custom: Failed to download and install kubectl angezeigt wird, führen Sie az aks install-cli --install-location ~/.azure/kubectl-client/kubectl aus, bevor Sie versuchen, az connectedk8s connect erneut auszuführen. Mit diesem Befehl wird der kubectl-Client installiert, der für die Ausführung des Befehls erforderlich ist.

Azure Arc-Agents

Alle Agents für Kubernetes mit Azure Arc-Unterstützung werden als Pods im azure-arc-Namespace bereitgestellt. Alle Pods sollten ausgeführt werden und ihre Integritätsprüfungen bestehen.

Überprüfen Sie zunächst das Azure Arc-Helm-Chart-Release:

$ helm --namespace default status azure-arc
NAME: azure-arc
LAST DEPLOYED: Fri Apr  3 11:13:10 2020
NAMESPACE: default
STATUS: deployed
REVISION: 5
TEST SUITE: None

Wenn das Helm-Chart-Release nicht gefunden wird oder fehlt, versuchen Sie, erneut eine Verbindung des Clusters mit Azure Arc herzustellen.

Wenn das Helm-Chart-Release vorhanden ist und den STATUS: deployed aufweist, überprüfen Sie den Status des Agents mithilfe von kubectl:

$ kubectl -n azure-arc get deployments,pods
NAME                                         READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/cluster-metadata-operator    1/1     1            1           3d19h
deployment.apps/clusterconnect-agent         1/1     1            1           3d19h
deployment.apps/clusteridentityoperator      1/1     1            1           3d19h
deployment.apps/config-agent                 1/1     1            1           3d19h
deployment.apps/controller-manager           1/1     1            1           3d19h
deployment.apps/extension-events-collector   1/1     1            1           3d19h
deployment.apps/extension-manager            1/1     1            1           3d19h
deployment.apps/flux-logs-agent              1/1     1            1           3d19h
deployment.apps/kube-aad-proxy               1/1     1            1           3d19h
deployment.apps/metrics-agent                1/1     1            1           3d19h
deployment.apps/resource-sync-agent          1/1     1            1           3d19h

NAME                                              READY   STATUS    RESTARTS        AGE
pod/cluster-metadata-operator-74747b975-9phtz     2/2     Running   0               3d19h
pod/clusterconnect-agent-cf4c7849c-88fmf          3/3     Running   0               3d19h
pod/clusteridentityoperator-79bdfd945f-pt2rv      2/2     Running   0               3d19h
pod/config-agent-67bcb94b7c-d67t8                 1/2     Running   0               3d19h
pod/controller-manager-559dd48b64-v6rmk           2/2     Running   0               3d19h
pod/extension-events-collector-85f4fbff69-55zmt   2/2     Running   0               3d19h
pod/extension-manager-7c7668446b-69gps            3/3     Running   0               3d19h
pod/flux-logs-agent-fc7c6c959-vgqvm               1/1     Running   0               3d19h
pod/kube-aad-proxy-84d668c44b-j457m               2/2     Running   0               3d19h
pod/metrics-agent-58fb8554df-5ll67                2/2     Running   0               3d19h
pod/resource-sync-agent-dbf5db848-c9lg8           2/2     Running   0               3d19h

Alle Pods sollten STATUS als Running mit 3/3 oder 2/2 unter der Spalte READY anzeigen. Rufen Sie Protokolle ab, und beschreiben Sie die Pods, die Error oder CrashLoopBackOff zurückgeben. Wenn Pods im Zustand Pending hängengeblieben sind, sind möglicherweise nicht ausreichend Ressourcen auf den Clusterknoten vorhanden. Wenn Sie Ihren Cluster hochskalieren, können diese Pods in den Zustand Running übergehen.

Ressourcenbereitstellung fehlgeschlagen/ Dienst-Timeout-Fehler

Wenn Sie diese Fehler sehen, überprüfen Sie den Azure-Status, um festzustellen, ob es aktive Ereignisse gibt, die sich auf den Status des Kubernetes-Dienstes mit Azure Arc-Unterstützung auswirken. Wenn dies der Fall ist, warten Sie, bis das Dienstereignis behoben wurde, und versuchen Sie dann das Onboarding erneut, nachdem Sie die vorhandene verbundene Clusterressource gelöscht haben. Wenn es keine Dienstereignisse gibt und Sie weiterhin Probleme beim Onboarding haben, öffnen Sie ein Supportanfrage, damit wir das Problem untersuchen können.

Fehler mit Überschreitungsmeldungen

Wenn Sie eine Meldung zur Überschreitung erhalten, stellen Sie sicher, dass Ihr Dienstprinzipal nicht Teil von mehr als 200 Microsoft Entra-Gruppen ist. Wenn dies der Fall ist, müssen Sie einen anderen Dienstprinzipal erstellen und verwenden, der nicht Mitglied von mehr als 200 Gruppen ist, oder den ursprünglichen Dienstprinzipal aus einigen seiner Gruppen entfernen und es erneut versuchen.

Eine Überschreitungsmeldung kann auch angezeigt werden, wenn Sie eine ausgehende Proxy-Umgebung konfiguriert haben, ohne den Endpunkt https://<region>.obo.arc.azure.com:8084/ für ausgehenden Verkehr zuzulassen.

Trifft beides nicht zu, stellen Sie eine Supportanfrage, damit wir uns das Problem ansehen können.

Probleme beim Verbinden von Kubernetes-Clustern mit Azure Arc

Das Herstellen einer Verbindung von Clustern mit Azure Arc erfordert Zugriff auf ein Azure-Abonnement und cluster-admin-Zugriff auf einen Zielcluster. Wenn Sie den Cluster nicht erreichen können oder nicht über ausreichende Berechtigungen verfügen, tritt beim Herstellen einer Verbindung des Clusters mit Azure Arc ein Fehler auf. Stellen Sie sicher, dass Sie alle Voraussetzungen erfüllt haben, um einen Cluster zu verbinden.

Tipp

Einen visuellen Leitfaden zum Beheben der Verbindungsprobleme finden Sie unter Diagnostizieren von Verbindungsproblemen für Arc-fähige Kubernetes-Cluster.

Probleme bei der DNS-Auflösung

Hilfe bei Problemen im Zusammenhang mit der DNS-Auflösung in Ihrem Cluster finden Sie unter Debuggen der DNS-Auflösung.

Probleme mit der ausgehenden Netzwerkkonnektivität

Probleme mit der ausgehenden Netzwerkkonnektivität aus dem Cluster können aus verschiedenen Gründen auftreten. Stellen Sie zunächst sicher, dass alle Netzwerkanforderungen erfüllt sind.

Wenn Verbindungsprobleme auftreten und sich Ihr Cluster hinter einem ausgehenden Proxyserver befindet, stellen Sie sicher, dass Sie beim Onboarding Ihres Clusters Proxyparameter übergeben haben und dass der Proxy ordnungsgemäß konfiguriert ist. Informationen finden Sie unter Herstellen einer Verbindung mithilfe eines ausgehenden Proxyservers.

Es wird ggf. eine Fehlermeldung wie die folgende angezeigt:

An exception has occurred while trying to execute the cluster diagnostic checks in the cluster. Exception: Unable to pull cluster-diagnostic-checks helm chart from the registry 'mcr.microsoft.com/azurearck8s/helmchart/stable/clusterdiagnosticchecks:0.1.2': Error: failed to do request: Head "https://mcr.microsoft.com/v2/azurearck8s/helmchart/stable/clusterdiagnosticchecks/manifests/0.1.2": dial tcp xx.xx.xx.219:443: i/o timeout

Dieser Fehler tritt auf, wenn der https://k8connecthelm.azureedge.net-Endpunkt blockiert ist. Stellen Sie sicher, dass Ihr Netzwerk eine Verbindung zu diesem Endpunkt zulässt und alle anderen Netzwerkanforderungen erfüllt.

Fehler beim Abrufen des MSI-Zertifikats

Probleme beim Abrufen des MSI-Zertifikats sind in der Regel auf Netzwerkprobleme zurückzuführen. Überprüfen Sie, ob alle Netzwerkanforderungen erfüllt sind, und wiederholen Sie dann den Vorgang.

Unzureichende Clusterberechtigungen

Wenn die bereitgestellte kubeconfig-Datei nicht über ausreichende Berechtigungen für die Installation der Azure Arc-Agenten verfügt, gibt der Azure CLI-Befehl einen Fehler zurück: Error: list: failed to list: secrets is forbidden: User "myuser" cannot list resource "secrets" in API group "" at the cluster scope

Um dieses Problem zu beheben, stellen Sie sicher, dass der Benutzer, der den Cluster mit Azure Arc verbindet, die zugewiesene cluster-admin-Rolle hat.

Herstellen einer Verbindung zwischen OpenShift-Cluster und Azure Arc nicht möglich

Wenn beim Verbinden eines OpenShift-Clusters mit Azure Arc ein Timeout für az connectedk8s connect auftritt und der Befehl nicht ausgeführt wird:

  1. Stellen Sie sicher, dass der OpenShift-Cluster die erforderlichen Versionsvoraussetzungen erfüllt: 4.5.41 oder höher oder 4.6.35 oder höher oder 4.7.18 oder höher.

  2. Führen Sie vor dem Ausführen von az connectedk8s connnect diesen Befehl im Cluster aus:

    oc adm policy add-scc-to-user privileged system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa
    

Timeouts bei der Installation

Das Herstellen einer Verbindung zwischen einem Kubernetes-Cluster und Kubernetes mit Azure Arc-Unterstützung erfordert die Installation von Azure Arc-Agents im Cluster. Wenn der Cluster über eine langsame Internetverbindung ausgeführt wird, kann das Pullen des Containerimages für Agents länger dauern, als die Azure CLI-Timeouts erlauben.

Helm-Timeout-Fehler

Möglicherweise wird der Fehler Unable to install helm release: Error: UPGRADE Failed: time out waiting for the condition angezeigt. Zur Behebung dieses Problems wird Folgendes empfohlen:

  1. Führen Sie den folgenden Befehl aus:

    kubectl get pods -n azure-arc
    
  2. Überprüfen Sie, ob die clusterconnect-agent- oder config-agent-Pods crashloopbackoff anzeigen oder nicht alle Container ausgeführt werden:

    NAME                                        READY   STATUS             RESTARTS   AGE
    cluster-metadata-operator-664bc5f4d-chgkl   2/2     Running            0          4m14s
    clusterconnect-agent-7cb8b565c7-wklsh       2/3     CrashLoopBackOff   0          1m15s
    clusteridentityoperator-76d645d8bf-5qx5c    2/2     Running            0          4m15s
    config-agent-65d5df564f-lffqm               1/2     CrashLoopBackOff   0          1m14s
    
  3. Wenn azure-identity-certificate nicht vorhanden ist, wurde die vom System zugewiesene verwaltete Identität nicht installiert.

    kubectl get secret -n azure-arc -o yaml | grep name:
    
    name: azure-identity-certificate
    

    Um dieses Problem zu lösen, versuchen Sie, die Arc-Bereitstellung zu löschen, indem Sie den az connectedk8s delete-Befehl ausführen und sie erneut installieren. Wenn das Problem weiterhin auftritt, könnte ein Problem mit Ihren Proxyeinstellungen vorliegen. Versuchen Sie in diesem Fall, die Verbindung ihres Clusters mit Azure Arc über einen Proxy herzustellen, um Ihren Cluster über einen Proxy mit Arc zu verbinden. Überprüfen Sie außerdem, ob alle Netzwerkvoraussetzungen erfüllt wurden.

  4. Wenn die clusterconnect-agent- und dieconfig-agent-Pods ausgeführt werden, aber der kube-aad-proxy-Pod fehlt, überprüfen Sie Ihre Pod-Sicherheitsrichtlinien. Dieser Pod verwendet das azure-arc-kube-aad-proxy-sa-Dienstkonto, das nicht über Administratorberechtigungen verfügt, aber die Berechtigung zum Bereitstellen des Host-Pfads erfordert.

  5. Wenn der kube-aad-proxy-Pod im Zustand ContainerCreating hängt, überprüfen Sie, ob das kube-aad-Proxyzertifikat auf den Cluster heruntergeladen wurde.

    kubectl get secret -n azure-arc -o yaml | grep name:
    
    name: kube-aad-proxy-certificate
    

    Wenn das Zertifikat fehlt, löschen Sie die Bereitstellung und versuchen Sie das Onboarding erneut, indem Sie sich mit einem anderen Namen für den Cluster erneut anmelden. Wenn das Problem weiterhin besteht, öffnen Sie eine Supportanfrage.

CryptoHash-Modulfehler

Wenn Sie versuchen, Kubernetes-Cluster in die Azure Arc-Plattform zu integrieren, gibt die lokale Umgebung (z. B. Ihre Clientkonsole) möglicherweise die folgende Fehlermeldung zurück:

Cannot load native module 'Crypto.Hash._MD5'

Manchmal können abhängige Module beim Hinzufügen der Erweiterungen connectedk8s und k8s-configuration über die Azure CLI oder über Azure Powershell nicht erfolgreich heruntergeladen werden. Um dieses Problem zu lösen, können Sie die Erweiterungen in der lokalen Umgebung manuell entfernen und dann hinzufügen.

Zum Entfernen der Erweiterungen verwenden Sie Folgendes:

az extension remove --name connectedk8s
az extension remove --name k8s-configuration

Zum Hinzufügen der Erweiterungen verwenden Sie Folgendes:

az extension add --name connectedk8s
az extension add --name k8s-configuration

Probleme bei der Clusterverbindung

Wenn sich Ihr Cluster hinter einem Proxy oder einer Firewall für ausgehende Daten befindet, überprüfen Sie, ob Websocketverbindungen für *.servicebus.windows.net aktiviert sind, was insbesondere für das Cluster Connect-Feature erforderlich ist. Stellen Sie außerdem sicher, dass Sie die neueste Version der Azure CLI-Erweiterung connectedk8s verwenden, wenn Sie Probleme mit der Clusterverbindung haben.

Wenn die Pods clusterconnect-agent und kube-aad-proxy fehlen, ist die Cluster-Verbindungsfunktion im Cluster wahrscheinlich deaktiviert. In diesem Fall gelingt es az connectedk8s proxy nicht, eine Sitzung mit dem Cluster einzurichten, und Sie erhalten die Fehlermeldung Cannot connect to the hybrid connection because no agent is connected in the target arc resource.

Um diesen Fehler zu beheben, aktivieren Sie das Clusterverbindungsfeature in Ihrem Cluster:

az connectedk8s enable-features --features cluster-connect -n $CLUSTER_NAME -g $RESOURCE_GROUP

Weitere Informationen finden Sie unter Verwenden von Cluster Connect zum sicheren Herstellen einer Verbindung mit Kubernetes-Clustern mit Azure Arc-Unterstützung.

Aktivieren von benutzerdefinierten Standorten per Dienstprinzipal

Wenn Sie eine Verbindung Ihres Clusters mit Azure Arc herstellen oder für einen vorhandenen Cluster benutzerdefinierte Speicherorte aktivieren, wird ggf. folgende Warnung angezeigt:

Unable to fetch oid of 'custom-locations' app. Proceeding without enabling the feature. Insufficient privileges to complete the operation.

Diese Warnung tritt auf, wenn Sie ein Dienstprinzipal verwenden, um sich bei Azure anzumelden, und das Dienstprinzipal nicht über die erforderlichen Berechtigungen verfügt. Führen Sie die folgenden Schritte aus, um diesen Fehler zu vermeiden:

  1. Melden Sie sich mit Ihrem Benutzerkonto bei Azure CLI an. Rufen Sie die Objekt-ID der vom Azure Arc-Dienst verwendeten Microsoft Entra-Anwendung ab:

    az ad sp show --id bc313c14-388c-4e7d-a58e-70017303ee3b --query objectId -o tsv
    
  2. Melden Sie sich mit dem Dienstprinzipal bei Azure CLI an. Verwenden Sie den <objectId>-Wert aus dem vorherigen Schritt, um benutzerdefinierte Speicherorte im Cluster zu aktivieren:

    • Führen Sie az connectedk8s connect -n <cluster-name> -g <resource-group-name> --custom-locations-oid <objectId> um benutzerdefinierte Speicherorte beim Herstellen der Verbindung des Clusters mit Arc zu aktivieren
    • Um benutzerdefinierte Speicherorte in einem Kubernetes-Cluster mit Azure Arc-Unterstützung zu aktivieren, führen Sie az connectedk8s enable-features -n <cluster-name> -g <resource-group-name> --custom-locations-oid <objectId> --features cluster-connect custom-locations aus

Nächste Schritte