Beheben von Fehlern bei der Bereitstellung von AKS-Clustererweiterungen
In diesem Artikel wird erläutert, wie Sie Fehler beheben, die auftreten, wenn Sie Clustererweiterungen für Microsoft Azure Kubernetes Service (AKS) bereitstellen.
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 Clustererweiterungs-Agent und die Manager-Pods ordnungsgemäß geplant sind und gestartet werden können. Wenn die Pods in einem ungelesenen 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 planung, unzureichenden Arbeitsspeicher oder Richtlinieneinschränkungen verhindern):
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 nicht, Datenebenen-Dienstendpunkte aufzurufen <region>.dp.kubernetesconfiguration.azure.com . Dieser Fehler generiert einen Eintrag "Errorcode: 403, Message This traffic is not authorized" in the extension-agent pod logs.
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 abzurufen, in die 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.
Lösung 3.1: (Empfohlen) Erstellen separater virtueller Netzwerke
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:
Suchen Sie die öffentliche IP-Adresse des Endpunkts der Erweiterungsdatenebene, indem Sie den
nslookupBefehl ausführen. Stellen Sie sicher,eastus2euapdass Sie die Region (z. B. ) 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.netErstellen Sie eine Sicherung der vorhandenen CoreDNS-Konfiguration:
kubectl get configmap -n kube-system coredns-custom -o yaml > coredns.backup.yamlÜberschreiben Sie die Zuordnung für den regionalen (z. B
eastus2euap. ) Datenebenenendpunkt der ö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 }Führen Sie zum Erstellen der ConfigMap den
kubectl applyBefehl aus, und geben Sie den Namen der YAML-Manifestdatei an:kubectl apply -f corednsms.yamlUm 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 corednsFühren Sie den
nslookupBefehl 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 "Errorcode: 403, Message This traffic is not authorized" fehlereinträge 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 "CriticalAddonsOnly" enthalten 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 enthaltene 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 anzuzeigen, überprüfen Sie die Erweiterungs-Pods, um zu überprüfen, 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
CriticalAddOnsOnlytainted Node Pools zu installieren, es sei denn, dies ist für Anwendungsworkloads 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 Anwendungs pods im Cluster planen. Stellen Sie sicher, dass mindestens ein Knotenpool im Cluster diesen Taint nicht hat. 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 theCriticalAddonsOnlyannotation 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 Taint hat CriticalAddonsOnly . Diese Aktion bewirkt, dass die Erweiterungs-Pods im neuen Knotenpool geplant werden.
Lösung 2: Entfernen Sie den Taint "CriticalAddonsOnly"
Wenn es möglich und praktisch 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:
- Timeout beim Warten auf die Ressourcenbereitschaft
- Fehler beim Heruntergeladen des Helm-Diagramms aus der Repository-URL
- Fehler beim Rendern des Helmdiagramms mit bestimmten Werten
- Ressource ist bereits in Ihrem Cluster vorhanden
- Der Vorgang ist bereits für Helm in Bearbeitung
Fehler: Timeout 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 zu einem Timeout der Installation. Richtlinieneinschränkungen oder Knotentaints (z
NoSchedule. B. ) können auch 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:
Überprüfen Sie Ressourcen: Stellen Sie sicher, dass Ihr Kubernetes-Cluster über ausreichende Ressourcen verfügt und dass die Pod-Planung auf den Knoten zulässig ist (Sie sollten taints berücksichtigen). Stellen Sie sicher, dass Arbeitsspeicher- und CPU-Ressourcen die Anforderungen erfüllen.
Inspect events: Check the events within the Kubernetes namespace to identify potential problems that might prevent pods, jobs, or other Kubernetes resources from reaching a ready state.
Ü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 zusätzlich zu Blockierungsproblemen zwischen dem Cluster und der Firewall 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: Fehler beim Rendern des Helmdiagramms mit bestimmten Werten
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.
Kontaktieren Sie uns für Hilfe
Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.