Fehler beim Bereitstellen von AKS-Clustererweiterungen beheben

Zusammenfassung

In diesem Artikel wird erläutert, wie Sie Fehler beheben, die auftreten, wenn Sie Clustererweiterungen für Microsoft Azure Kubernetes Service (AKS) bereitstellen, einschließlich Fehler beim Erstellen von Erweiterungen, Helmfehlern und Planungsproblemen.

Fehler bei der Erweiterungserstellung

Fehler: Eine Antwort des Agents kann nicht rechtzeitig abgerufen werden.

Dieser Fehler tritt auf, wenn Azure-Dienste keine Antwort vom Clustererweiterungs-Agent erhalten. Diese Situation kann auftreten, da der AKS-Cluster keine Verbindung mit Azure herstellen kann.

Ursache 1: Der Clustererweiterungs-Agent und die Manager-Pods werden nicht initialisiert.

Der Clustererweiterungs-Agent und -Manager sind wichtige Systemkomponenten, die für die Verwaltung des Lebenszyklus von Kubernetes-Anwendungen verantwortlich sind. Die Initialisierung des Clustererweiterungs-Agents und der Manager-Pods kann aufgrund der folgenden Probleme fehlschlagen:

  • Ressourcenbeschränkungen
  • Richtlinieneinschränkungen
  • Knotentaints, z. B. NoSchedule
Lösung 1: Stellen Sie sicher, dass der Clustererweiterungs-Agent und die Manager-Pods ordnungsgemäß funktionieren

Um dieses Problem zu beheben, stellen Sie sicher, dass der Cluster-Erweiterungs-Agent und die Manager-Pods ordnungsgemäß geplant und betriebsbereit sind. Wenn die Pods in einem unbereiten Zustand hängen bleiben, überprüfen Sie die Pod-Beschreibung, indem Sie den folgenden kubectl describe pod Befehl ausführen, um weitere Details zu den zugrunde liegenden Problemen zu erhalten (z. B. taints, die die Planung verhindern, unzureichender Arbeitsspeicher oder Richtlinienbeschränkungen):

kubectl describe pod -n kube-system extension-operator-{id}

Hier ist ein Befehlsausgabebeispiel:

kube-system         extension-agent-55d4f4795f-sqx7q             2/2     Running   0          2d19h
kube-system         extension-operator-56c8d5f96c-nvt7x          2/2     Running   0          2d19h

Führen Sie für ARC-verbundene Cluster den folgenden Befehl aus, um die Beschreibung des Pods zu überprüfen:

kubectl describe pod -n azure-arc extension-manager-{id}

Hier ist ein Befehlsausgabebeispiel:

NAMESPACE         NAME                                          READY   STATUS             RESTARTS        AGE
azure-arc         cluster-metadata-operator-744f8bfbd4-7pssr    0/2     ImagePullBackOff   0               6d19h
azure-arc         clusterconnect-agent-7557d99d5c-rtgqh         0/3     ImagePullBackOff   0               6d19h
azure-arc         clusteridentityoperator-9b8b88f97-nr8hf       0/2     ImagePullBackOff   0               6d19h
azure-arc         config-agent-6d5fd59b8b-khw2d                 0/2     ImagePullBackOff   0               6d19h
azure-arc         controller-manager-5bc97f7db6-rt2zs           0/2     ImagePullBackOff   0               6d19h
azure-arc         extension-events-collector-7596688867-sqzv2   0/2     ImagePullBackOff   0               6d19h
azure-arc         extension-manager-86bbb949-6s59q              0/3     ImagePullBackOff   0               6d19h
azure-arc         flux-logs-agent-5f55888db9-wnr4c              0/1     ImagePullBackOff   0               6d19h
azure-arc         kube-aad-proxy-646c475dcc-92b86               0/2     ImagePullBackOff   0               6d19h
azure-arc         logcollector-5cbc659bfb-9v96d                 0/1     ImagePullBackOff   0               6d19h
azure-arc         metrics-agent-5794866b46-j9949                0/2     ImagePullBackOff   0               6d19h
azure-arc         resource-sync-agent-6cf4cf7486-flgwc          0/2     ImagePullBackOff   0               6d19h

Wenn der Clustererweiterungs-Agent und die Manager-Pods betriebsbereit und fehlerfrei sind, richten sie die Kommunikation mit Azure-Diensten ein, um Kubernetes-Anwendungen zu installieren und zu verwalten.

Ursache 2: Ein Problem betrifft den Ausstiegsblock oder die Firewall

Wenn der Clustererweiterungs-Agent und die Manager-Pods fehlerfrei sind und immer noch der Fehler "Es ist nicht möglich, eine Antwort vom Agent rechtzeitig zu erhalten" angezeigt wird, ist wahrscheinlich ein Ausstiegsblock oder ein Firewallproblem vorhanden. Dieses Problem kann verhindern, dass der Clustererweiterungs-Agent und die Manager-Pods mit Azure kommunizieren.

Lösung 2: Sicherstellen, dass netzwerkvoraussetzungen erfüllt sind

Um dieses Problem zu beheben, stellen Sie sicher, dass Sie die Netzwerkvoraussetzungen einhalten, die in ausgehenden Netzwerk- und FQDN-Regeln für Azure Kubernetes Service (AKS)-Cluster beschrieben sind.

Ursache 3: Der Datenverkehr ist nicht autorisiert

Der Erweiterungs-Agent versucht erfolglos, <region>.dp.kubernetesconfiguration.azure.com Datenebenen-Dienstendpunkte aufzurufen. Dieser Fehler generiert einen Eintrag "Errorcode: 403, Nachricht: Dieser Datenverkehr ist nicht autorisiert" in den Protokollen des Extension-Agent-Pods.

kubectl logs -n kube-system extension-agent-<pod-guid>
{  "Message": "2024/02/07 06:04:43 \"Errorcode: 403, Message This traffic is not authorized., Target /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/provider/managedclusters/clusters/<cluster-name>/configurations/getPendingConfigs\"",  "LogType": "ConfigAgentTrace",  "LogLevel": "Information",  "Environment": "prod",  "Role": "ClusterConfigAgent",  "Location": "<region>,  "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>",  "CorrelationId": "",  "AgentName": "ConfigAgent",  "AgentVersion": "1.14.5",  "AgentTimestamp": "2024/02/07 06:04:43.672"  }
{  "Message": "2024/02/07 06:04:43 Failed to GET configurations with err : {\u003cnil\u003e}",  "LogType": "ConfigAgentTrace",  "LogLevel": "Information",  "Environment": "prod",  "Role": "ClusterConfigAgent",  "Location": "<region>",  "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>",  "CorrelationId": "",  "AgentName": "ConfigAgent",  "AgentVersion": "1.14.5",  "AgentTimestamp": "2024/02/07 06:04:43.672"  }

Dieser Fehler tritt auf, wenn ein bereits vorhandenes PrivateLinkScope in der Datenebene einer Erweiterung für Azure Arc-fähige Kubernetes vorhanden ist und das virtuelle Netzwerk (oder der private DNS-Server) zwischen Azure Arc-fähigen Kubernetes und dem vom AKS verwalteten Cluster gemeinsam genutzt wird. Diese Netzwerkkonfiguration bewirkt, dass AKS ausgehender Datenverkehr aus der Erweiterungsdatenebene auch über dieselbe private IP-Adresse statt über eine öffentliche IP-Adresse weitergeleitet wird.

Führen Sie den folgenden nslookup-Befehl in Ihrem AKS-Cluster aus, um die spezifische private IP-Adresse zu ermitteln, zu der der Endpunkt der Datenebene aufgelöst wird.

PS D:\> kubectl exec -it -n kube-system extension-agent-<pod-guid> -- nslookup  <region>.dp.kubernetesconfiguration.azure.com
Non-authoritative answer:
<region>.dp.kubernetesconfiguration.azure.com        canonical name = <region>.privatelink.dp.kubernetesconfiguration.azure.com
Name:   <region>.privatelink.dp.kubernetesconfiguration.azure.com
Address: 10.224.1.184

Wenn Sie in der Azure-Portal nach der privaten IP-Adresse suchen, verweisen die Suchergebnisse auf die genaue Ressource: virtuelles Netzwerk, private DNS-Zone, privater DNS-Server usw. Diese Ressource verfügt über einen privaten Endpunkt, der für die Erweiterungsdatenebene für Azure Arc-fähige Kubernetes konfiguriert ist.

Um dieses Problem zu beheben, empfehlen wir, separate virtuelle Netzwerke für Azure Arc-fähige Kubernetes und AKS-Berechnungen zu erstellen.

Lösung 3.2: Erstellen einer CoreDNS-Außerkraftsetzung

Wenn die empfohlene Lösung in Ihrer Situation nicht möglich ist, erstellen Sie eine CoreDNS-Außerkraftsetzung für den Endpunkt der Erweiterungsdatenebene, um über das öffentliche Netzwerk zu wechseln. Weitere Informationen zum Anpassen von CoreDNS finden Sie im Abschnitt "Hosts plugin" unter "Customize CoreDNS with Azure Kubernetes Service".

Führen Sie die folgenden Schritte aus, um eine CoreDNS-Außerkraftsetzung zu erstellen:

  1. Suchen Sie die öffentliche IP-Adresse des Endpunkts der Erweiterungsdatenebene, indem Sie den nslookup Befehl ausführen. Stellen Sie sicher, dass Sie die Region (z. B. eastus2euap) basierend auf der Position Ihres AKS-Clusters ändern:

    nslookup <region>.dp.kubernetesconfiguration.azure.com
Non-authoritative answer:
Name:    clusterconfig<region>.<region>.cloudapp.azure.com
Address:  20.39.12.229
Aliases:  <region>.dp.kubernetesconfiguration.azure.com
         <region>.privatelink.dp.kubernetesconfiguration.azure.com
         <region>.dp.kubernetesconfiguration.trafficmanager.net

  2. Erstellen Sie eine Sicherung der vorhandenen CoreDNS-Konfiguration:

    kubectl get configmap -n kube-system coredns-custom -o yaml > coredns.backup.yaml

  3. Überschreiben Sie die Zuordnung für den regionalen (z. B. eastus2euap) Datenebenenendpunkt zur öffentlichen IP-Adresse. Erstellen Sie dazu eine YAML-Datei mit dem Namen "corednsms.yaml", und kopieren Sie dann die folgende Beispielkonfiguration in die neue Datei. (Stellen Sie sicher, dass Sie die Adresse und den Hostnamen mithilfe der Werte für Ihre Umgebung aktualisieren.)

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom      # This is the name of the configuration map that you can overwrite with your changes.
  namespace: kube-system
data:
  extensionsdp.override: |  # You can select any name here, but it must have the .override file name extension.
    hosts {
      20.39.12.229 <region>.dp.kubernetesconfiguration.azure.com
      fallthrough
    }

  4. Führen Sie zum Erstellen der ConfigMap den kubectl apply Befehl aus, und geben Sie den Namen der YAML-Manifestdatei an:

    kubectl apply -f corednsms.yaml

  5. Um die ConfigMap neu zu laden und Kubernetes Scheduler zu aktivieren, CoreDNS ohne Ausfallzeit neu zu starten, führen Sie den Befehl für den Kubectl-Rolloutneustart aus :

    kubectl -n kube-system rollout restart deployment coredns

  6. Führen Sie den nslookup Befehl erneut aus, um sicherzustellen, dass der Endpunkt der Datenebene in die bereitgestellte öffentliche IP-Adresse aufgelöst wird:

    kubectl exec -it -n kube-system extension-agent-55d4f4795f-nld9q -- nslookup  [region].dp.kubernetesconfiguration.azure.com
Name:   <region>.dp.kubernetesconfiguration.azure.com
Address: 20.39.12.229

Die Protokolle des Erweiterungs-Agent-Pods sollten nicht mehr die Fehlereinträge "Errorcode: 403, Message This traffic is not authorized" protokollieren. Stattdessen sollten die Protokolle "200"-Antwortcodes enthalten.

kubectl logs -n kube-system extension-agent-{id} 
{  "Message": "GET configurations returned response code {200}",  "LogType": "ConfigAgentTrace",  "LogLevel": "Information",  "Environment": "prod",  "Role": "ClusterConfigAgent",  "Location": "<region>",  "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>",  "CorrelationId": "",  "AgentName": "ConfigAgent",  "AgentVersion": "1.14.5"  }

Fehler: Erweiterungs-Pods können nicht geplant werden, wenn alle Knotenpools im Cluster mit "CriticalAddonsOnly" markiert sind.

Wenn dieser Fehler auftritt, wird der folgende Eintrag im Erweiterungs-Agent-Protokoll protokolliert:

Erweiterungs-Pod-Fehler: 0/2 Knoten sind verfügbar: 2 Knoten hatten untolerierte Taint {CriticalAddonsOnly: true}. Preemption: 0/2 Knoten sind verfügbar: 2 Preemption ist nicht hilfreich für die Planung.

Ursache

Dieser Fehler tritt auf, wenn Sie versuchen, Erweiterungen (z. B. die Distributed Application Runtime (DAPR)) auf einem AKS-Cluster zu aktivieren, CriticalAddonsOnly der über verunreinigte Knotenpools verfügt. In dieser Situation werden die Erweiterungs-Pods nicht auf einem Knoten geplant, da keine Toleration für diese Taints vorhanden ist.

Um die Fehlersituation zu betrachten, prüfen Sie die Verlängerungspods, um festzustellen, ob sie in einem ausstehenden Zustand hängen bleiben:

kubectl get po -n {namespace-name} -l app.kubernetes.io/name={name}

NAME                                   READY   STATUS    RESTARTS   AGE
{podname}                              0/2     Pending   0          2d6h

Beschreiben Sie die Pods, um zu sehen, dass sie aufgrund eines nicht unterstützten Taints nicht geplant werden können:

kubectl describe po -n {namespace-name} {podname}

Events:
  Type     Reason            Age   From               Message
  ----     ------            ----  ----               -------
  Warning  FailedScheduling  18s   default-scheduler  0/2 nodes are available: 2 node(s) had untolerated taint {CriticalAddonsOnly: true}. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling.

Notiz

  • Es wird empfohlen, keine Erweiterungen in getainteten CriticalAddOnsOnly Knotenpools zu installieren, es sei denn, dies ist für Anwendungs-Workloads erforderlich.

  • Es wird empfohlen, keinen Taint für einzelne Knotenpoolcluster zu verwenden CriticalAddOnsOnly. Wenn Sie diesen Taint in einem Cluster verwenden, der nur über einen Knotenpool verfügt, können Sie keine Anwendungspods im Cluster bereitstellen. Stellen Sie sicher, dass mindestens ein Knotenpool im Cluster diesen Taint nicht besitzt. Weitere Informationen dazu, wann die Anmerkung verwendet werden soll, finden Sie unter Verwalten von Systemknotenpools in Azure Kubernetes Service (AKS).For more information about when the CriticalAddonsOnly annotation should be used, see Manage system node pools in Azure Kubernetes Service (AKS).

Lösung 1: Hinzufügen eines Knotenpools zum Cluster

Um dieses Problem zu beheben, fügen Sie einen weiteren Knotenpool hinzu, der keinen CriticalAddonsOnly-Taint aufweist. Diese Aktion bewirkt, dass die Erweiterungspods dem neuen Knotenpool zugewiesen werden.

Lösung 2: Entfernen Sie den Taint "CriticalAddonsOnly"

Wenn es möglich und praktikabel ist, können Sie den CriticalAddonsOnly Taint entfernen, um die Erweiterung auf dem Cluster zu installieren.

Helmfehler

Möglicherweise treten folgende Helm-bezogene Fehler auf:

Fehler: Zeitüberschreitung beim Warten auf die Ressourcenbereitschaft

Die Installation einer Kubernetes-Anwendung schlägt fehl und zeigt die folgenden Fehlermeldungen an:

Auftragsfehler: BackoffLimitExceeded

Timeout beim Warten auf den Zustand "Bereit/Abgeschlossen" der Ressource.

Ursache

Dieses Problem hat die folgenden häufigen Ursachen:

  • Ressourceneinschränkungen: Unzureichender Arbeitsspeicher oder CPU-Ressourcen innerhalb des Clusters können die erfolgreiche Initialisierung von Pods, Aufträgen oder anderen Kubernetes-Ressourcen verhindern. Diese Situation führt dazu, dass die Installation ein Timeout erhält. Richtlinieneinschränkungen oder Knotentaints (z. B. NoSchedule) können ebenfalls die Ressourceninitialisierung blockieren.

  • Architekturkonflikt: Beim Versuch, eine Linux-basierte Anwendung auf einem Windows-basierten Knoten (oder umgekehrt) zu planen, kann dies zu Fehlern in der Kubernetes-Ressourceninitialisierung führen.

  • Falsche Konfigurationseinstellungen: Falsche Konfigurationseinstellungen können verhindern, dass Pods gestartet werden.

Lösung

Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:

  1. Überprüfen Sie Ressourcen: Stellen Sie sicher, dass Ihr Kubernetes-Cluster über ausreichende Ressourcen verfügt und dass auf den Knoten die Planung von Pods erlaubt ist (Sie sollten Taints berücksichtigen). Stellen Sie sicher, dass Arbeitsspeicher- und CPU-Ressourcen die Anforderungen erfüllen.

  2. Untersuchen Sie Ereignisse: Überprüfen Sie die Ereignisse im Kubernetes-Namensraum, um potenzielle Probleme zu identifizieren, die verhindern könnten, dass Pods, Jobs oder andere Kubernetes-Ressourcen einen Bereitschaftszustand erreichen.

  3. Überprüfen Sie Helmdiagramme und Konfigurationen: Viele Kubernetes-Anwendungen verwenden Helm-Diagramme, um Ressourcen auf dem Cluster bereitzustellen. Einige Anwendungen erfordern möglicherweise Benutzereingaben über Konfigurationseinstellungen. Stellen Sie sicher, dass alle bereitgestellten Konfigurationswerte korrekt sind und die Installationsanforderungen erfüllen.

Fehler: Das Helm-Diagramm kann nicht aus der Repository-URL heruntergeladen werden.

Dieser Fehler wird durch Konnektivitätsprobleme verursacht, die zwischen dem Cluster und der Firewall sowie durch Probleme mit der Blockierung ausgehender Daten auftreten. Informationen zum Beheben dieses Problems finden Sie unter "Ausgehende Netzwerk- und FQDN-Regeln für Azure Kubernetes Service (AKS)-Cluster.To resolve this problem, see Outbound network and FQDN rules for Azure Kubernetes Service (AKS)cluster.

Fehler: Rendering des Helm-Charts mit vorgegebenen Werten fehlgeschlagen.

Dieser Fehler tritt auf, wenn Kubernetes-Anwendungen auf Helm-Diagrammen angewiesen sind, um Ressourcen im Kubernetes-Cluster bereitzustellen. Diese Anwendungen erfordern möglicherweise Benutzereingaben, die über Konfigurationseinstellungen bereitgestellt werden, die während der Installation als Helmwerte übergeben werden. Wenn eine dieser wichtigen Konfigurationseinstellungen fehlt oder falsch ist, wird das Helm-Diagramm möglicherweise nicht gerendert.

Um dieses Problem zu beheben, überprüfen Sie die Erweiterungs- oder Anwendungsdokumentation, um zu ermitteln, ob Sie während der Anwendungsinstallation keine obligatorischen Werte angegeben oder falsche Werte angegeben haben. Diese Richtlinien können Ihnen helfen, Probleme beim Rendern von Helmdiagrammen zu beheben, die durch fehlende oder ungenaue Konfigurationswerte verursacht werden.

Fehler: Ressource ist bereits in Ihrem Cluster vorhanden

Dieser Fehler tritt auf, wenn ein Konflikt zwischen den Kubernetes-Ressourcen in Ihrem Cluster und den Kubernetes-Ressourcen besteht, die die Anwendung installieren möchte. Die Fehlermeldung gibt in der Regel den Namen der widersprüchlichen Ressource an.

Wenn die widersprüchliche Ressource unerlässlich ist und nicht ersetzt werden kann, können Sie die Anwendung möglicherweise nicht installieren. Wenn die Ressource nicht kritisch ist und entfernt werden kann, löschen Sie die widersprüchliche Ressource, und versuchen Sie es dann erneut.

Fehler: Der Vorgang wird bereits für Helm ausgeführt.

Dieser Fehler tritt auf, wenn für eine bestimmte Version bereits ein Vorgang ausgeführt wird. Um dieses Problem zu beheben, warten Sie 10 Minuten, und wiederholen Sie dann den Vorgang.

  • Last updated on