Behandeln von Fehlern beim Bereitstellen von AKS-Clustererweiterungen
In diesem Artikel wird erläutert, wie Sie Fehler beheben, die beim Bereitstellen von Clustererweiterungen für Microsoft Azure Kubernetes Service (AKS) auftreten.
Fehler bei der Erweiterungserstellung
Fehler: Eine Antwort vom Agent kann nicht rechtzeitig abgerufen werden.
Dieser Fehler tritt auf, wenn Azure-Dienste keine Antwort vom Clustererweiterungs-Agent erhalten. Diese Situation kann auftreten, weil 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 Podbeschreibung, 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 Richtlinieneinschränkungen):
kubectl describe pod -n kube-system extension-operator-{id}
Hier sehen Sie ein Beispiel für die Befehlsausgabe:
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 mit ARC verbundene Cluster den folgenden Befehl aus, um die Podbeschreibung zu überprüfen:
kubectl describe pod -n azure-arc extension-manager-{id}
Hier sehen Sie ein Beispiel für die Befehlsausgabe:
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, stellen sie die Kommunikation mit Azure-Diensten her, um Kubernetes-Anwendungen zu installieren und zu verwalten.
Ursache 2: Ein Problem betrifft den Ausgangsblock oder die Firewall.
Wenn der Clustererweiterungs-Agent und die Manager-Pods fehlerfrei sind und weiterhin der Fehler "Antwort vom Agent kann nicht rechtzeitig abgerufen werden" auftritt, liegt wahrscheinlich ein Problem mit einem Ausgangsblock oder einer Firewall vor. Dieses Problem kann die Kommunikation des Clustererweiterungs-Agents und der Manager-Pods mit Azure blockieren.
Lösung 2: Stellen Sie sicher, dass die Netzwerkvoraussetzungen erfüllt sind.
Um dieses Problem zu beheben, stellen Sie sicher, dass Sie die Netzwerkvoraussetzungen befolgen, die unter Ausgehende Netzwerk- und FQDN-Regeln für Azure Kubernetes Service-Cluster (AKS) beschrieben sind.
Ursache 3: Der Datenverkehr ist nicht autorisiert.
Der Erweiterungs-Agent versucht erfolglos, Dienstendpunkte auf Datenebene aufzurufen <region>.dp.kubernetesconfiguration.azure.com . Dieser Fehler generiert den Eintrag "Errorcode: 403, Message This traffic is not authorized" (Fehlercode: 403, Meldung Dieser Datenverkehr ist nicht autorisiert) in den Podprotokollen des Erweiterungs-Agents.
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 auf der Datenebene einer Erweiterung für Kubernetes mit Azure Arc-Unterstützung vorhanden ist und das virtuelle Netzwerk (oder der private DNS-Server) zwischen Kubernetes mit Azure Arc-Unterstützung und dem verwalteten AKS-Cluster gemeinsam genutzt wird. Diese Netzwerkkonfiguration bewirkt, dass ausgehender AKS-Datenverkehr von 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 Datenebenenendpunkt 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 im 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 Kubernetes mit Azure Arc-Unterstützung konfiguriert ist.
Lösung 3.1: (Empfohlen) Erstellen separater virtueller Netzwerke
Um dieses Problem zu beheben, empfiehlt es sich, separate virtuelle Netzwerke für Azure Arc-fähige Kubernetes- und AKS-Computes 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 das öffentliche Netzwerk zu durchlaufen. Weitere Informationen zum Anpassen von CoreDNS finden Sie im Abschnitt "Hosts-Plug-In" von "Customize CoreDNS with Azure Kubernetes Service" (Anpassen von CoreDNS mit Azure Kubernetes Service).
Führen Sie die folgenden Schritte aus, um eine CoreDNS-Außerkraftsetzung zu erstellen:
Suchen Sie die öffentliche IP-Adresse des Erweiterungsdatenebenenendpunkts, indem Sie den
nslookupBefehl ausführen. Stellen Sie sicher, dass Sie die Region (z. Beastus2euap. ) basierend auf dem Standort 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 des endpunkts der regionalen Datenebene (z. B
eastus2euap. ) zur öffentlichen IP-Adresse. Erstellen Sie hierzu 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 dabei den Namen Ihrer YAML-Manifestdatei an:kubectl apply -f corednsms.yamlFühren Sie den Befehl kubectl rollout restart aus, um die ConfigMap neu zu laden und Kubernetes Scheduler zu aktivieren, um CoreDNS ohne Ausfallzeiten neu zu starten:
kubectl -n kube-system rollout restart deployment corednsFühren Sie den
nslookupBefehl erneut aus, um sicherzustellen, dass der Datenebenenendpunkt in die angegebene ö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 Podprotokolle des Erweiterungs-Agents sollten die Fehlereinträge "Errorcode: 403, Message This traffic is not authorized" (Fehlercode: 403, Meldung Dieser Datenverkehr ist nicht autorisiert) nicht mehr 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: Erweiterungspods können nicht geplant werden, wenn alle Knotenpools im Cluster "CriticalAddonsOnly" tainted sind
Wenn dieser Fehler auftritt, wird der folgende Eintrag im Protokoll des Erweiterungs-Agents protokolliert:
Fehler des Erweiterungspods: 0/2 Knoten sind verfügbar: 2 Knoten hatten einen nicht erkannten Taint {CriticalAddonsOnly: true}. vorzeitige Entfernung: 0/2 Knoten sind verfügbar: 2 Vorzeitige Entfernung ist für die Planung nicht hilfreich.
Ursache
Dieser Fehler tritt auf, wenn Sie versuchen, Erweiterungen (z. B. die Distributed Application Runtime (DAPR)) für einen AKS-Cluster zu aktivieren, der CriticalAddonsOnly über verfleckte Knotenpools verfügt. In diesem Fall werden die Erweiterungspods auf keinem Knoten geplant, da für diese Taints keine Toleranz besteht.
Um die Fehlersituation anzuzeigen, überprüfen Sie die Erweiterungspods, um sicherzustellen, dass 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.
Hinweis
Es wird empfohlen, keine Erweiterungen in
CriticalAddOnsOnlyverfleckten Knotenpools zu installieren, es sei denn, dies ist für Anwendungsworkloads erforderlich.Es wird empfohlen, keinen Taint in Poolclustern mit nur einem
CriticalAddOnsOnlyKnoten zu verwenden. Wenn Sie diesen Taint in einem Cluster verwenden, der nur über einen Knotenpool verfügt, können Sie keine Anwendungspods im Cluster planen. Stellen Sie sicher, dass mindestens ein Knotenpool im Cluster nicht über diesen Taint verfügt. Weitere Informationen dazu, wann dieCriticalAddonsOnlyAnmerkung verwendet werden sollte, finden Sie unter Verwalten von Systemknotenpools 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 CriticalAddonsOnly ohne Taint hinzu. Diese Aktion bewirkt, dass die Erweiterungspods im neuen Knotenpool geplant werden.
Lösung 2: Entfernen des Taints "CriticalAddonsOnly"
Wenn dies möglich und praktisch ist, können Sie den CriticalAddonsOnly Taint entfernen, um die Erweiterung im Cluster zu installieren.
Helm-Fehler
Möglicherweise tritt einer der folgenden Helm-bezogenen Fehler auf:
- Timeout beim Warten auf Ressourcenbereitschaft
- Das Helm-Diagramm kann nicht von der Repository-URL heruntergeladen werden.
- Fehler beim Rendern von Helm-Diagrammen mit angegebenen Werten
- Ressource ist bereits in Ihrem Cluster vorhanden
- Der Vorgang für Helm wird bereits ausgeführt.
Fehler: Timeout beim Warten auf Ressourcenbereitschaft
Die Installation einer Kubernetes-Anwendung schlägt fehl und zeigt die folgenden Fehlermeldungen an:
Auftrag fehlgeschlagen: BackoffLimitExceed
Timeout beim Warten auf den Zustand "Bereit/Abgeschlossen" für die Ressource.
Ursache
Dieses Problem hat die folgenden häufigen Ursachen:
Ressourceneinschränkungen: Unzureichende Arbeitsspeicher- oder CPU-Ressourcen innerhalb des Clusters können die erfolgreiche Initialisierung von Pods, Aufträgen oder anderen Kubernetes-Ressourcen verhindern. Schließlich führt diese Situation zu einem Timeout für die Installation. Richtlinieneinschränkungen oder Knotentaints (z
NoSchedule. B. ) können auch die Ressourceninitialisierung blockieren.Architekturkonflikte: Der Versuch, eine Linux-basierte Anwendung auf einem Windows-basierten Knoten (oder umgekehrt) zu planen, kann zu Fehlern bei der Initialisierung von Kubernetes-Ressourcen führen.
Falsche Konfigurationseinstellungen: Falsche Konfigurationseinstellungen können das Starten von Pods verhindern.
Lösung
Gehen Sie wie folgt vor, um das Problem zu beheben:
Ressourcen überprüfen: Stellen Sie sicher, dass Ihr Kubernetes-Cluster über genügend Ressourcen verfügt und dass die Podplanung auf den Knoten zulässig ist (Sie sollten Taints berücksichtigen). Stellen Sie sicher, dass Arbeitsspeicher- und CPU-Ressourcen die Anforderungen erfüllen.
Untersuchen von Ereignissen: Überprüfen Sie die Ereignisse im Kubernetes-Namespace, um potenzielle Probleme zu identifizieren, die verhindern können, dass Pods, Aufträge oder andere Kubernetes-Ressourcen den Status "Bereit" erreichen.
Überprüfen von Helm-Diagrammen und -Konfigurationen: Viele Kubernetes-Anwendungen verwenden Helm-Diagramme, um Ressourcen im Cluster bereitzustellen. Einige Anwendungen erfordern möglicherweise Benutzereingaben über Konfigurationseinstellungen. Stellen Sie sicher, dass alle angegebenen Konfigurationswerte korrekt sind und die Installationsanforderungen erfüllen.
Fehler: Das Helm-Diagramm kann nicht von der Repository-URL heruntergeladen werden.
Dieser Fehler wird durch Konnektivitätsprobleme verursacht, die zwischen dem Cluster und der Firewall auftreten, zusätzlich zu Problemen beim Blockieren von ausgehenden Daten. Informationen zum Beheben dieses Problems finden Sie unter Ausgehende Netzwerk- und FQDN-Regeln für Azure Kubernetes Service-Cluster (AKS).
Fehler: Fehler beim Rendern von Helm-Diagrammen mit angegebenen Werten
Dieser Fehler tritt auf, wenn Kubernetes-Anwendungen Helm-Diagramme verwenden, um Ressourcen im Kubernetes-Cluster bereitzustellen. Diese Anwendungen erfordern möglicherweise Benutzereingaben, die über Konfigurationseinstellungen bereitgestellt werden, die während der Installation als Helm-Werte ü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 obligatorische Werte ausgelassen oder falsche Werte angegeben haben. Diese Richtlinien können Ihnen helfen, Probleme beim Rendern von Helm-Diagrammen 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 zu installieren versucht. Die Fehlermeldung gibt in der Regel den Namen der in Konflikt stehenden Ressource an.
Wenn die in Konflikt stehende 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 in Konflikt stehende Ressource, und versuchen Sie die Installation erneut.
Fehler: Der Vorgang für Helm wird bereits ausgeführt.
Dieser Fehler tritt auf, wenn für ein bestimmtes Release 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.