Problembehandlung beim Status "Nicht bereit" eines fehlerfreien Knotens

  • Artikel
  • 5 Minuten Lesedauer

In diesem Artikel wird ein Szenario erläutert, in dem sich der Status eines AKS-Clusterknotens (Azure Kubernetes Service) in "Nicht bereit" ändert, nachdem sich der Knoten einige Zeit in einem fehlerfreien Zustand befindet. In diesem Artikel wird die besondere Ursache beschrieben und eine mögliche Lösung bereitgestellt.

Voraussetzungen

Problembeschreibung

Der Status eines Clusterknotens mit einem fehlerfreien Status (alle ausgeführten Dienste) ändert sich unerwartet in "Nicht bereit". Um den Status eines Knotens anzuzeigen, führen Sie den folgenden kubectl describe-Befehl aus:

kubectl describe nodes

Ursache

Das Kubelet hat den Status " Bereit " nicht mehr veröffentlicht.

Überprüfen Sie die Ausgabe des kubectl describe nodes Befehls, um das Feld "Bedingungen" und die Blöcke "Capacity" und "Allocatable " zu finden. Wird der Inhalt dieser Felder erwartungsgemäß angezeigt? (Enthält die Eigenschaft beispielsweise im Feld "Bedingungen " die message Zeichenfolge "kubelet is posting ready status"?) Wenn Sie in diesem Fall direkten SSH-Zugriff (Secure Shell) auf den Knoten haben, überprüfen Sie die letzten Ereignisse, um den Fehler zu verstehen. Suchen Sie in der Datei "/var/log/messages ". Oder generieren Sie die Kubelet- und Containerdaemon-Protokolldateien, indem Sie die folgenden Shellbefehle ausführen:

journalctl --directory=. --unit=kubelet > kubelet.log
journalctl --directory=. --unit=docker > docker.log

Nachdem Sie diese Befehle ausgeführt haben, überprüfen Sie die Daemonprotokolldateien auf Details zu dem Fehler.

Schritt 1: Überprüfen auf Änderungen auf Netzwerkebene

Wenn alle Clusterknoten auf den Status "Nicht bereit " zurückgestuft wurden, überprüfen Sie, ob auf Netzwerkebene Änderungen vorgenommen wurden. Beispiele für Änderungen auf Netzwerkebene sind die folgenden Elemente:

  • Dns-Änderungen (Domain Name System)
  • Firewallportänderungen
  • Netzwerksicherheitsgruppen (Network Security Groups, NSGs) hinzugefügt

Wenn Änderungen auf Netzwerkebene vorgenommen wurden, nehmen Sie alle erforderlichen Korrekturen vor. Beenden Sie die Ausgeführten Knoten, und starten Sie sie neu, nachdem Sie die Probleme behoben haben. Wenn sich die Knoten nach diesen Korrekturen in einem fehlerfreien Zustand befinden, können Sie die verbleibenden Schritte sicher überspringen.

Schritt 2: Beenden und Neustarten der Knoten

Wenn nur wenige Knoten in den Status "Nicht bereit " zurückgestuft wurden, beenden Sie einfach die Knoten, und starten Sie sie neu. Diese Aktion allein kann dazu führen, dass die Knoten in einen fehlerfreien Zustand versetzt werden. Überprüfen Sie dann Azure Kubernetes Service Übersicht über die Diagnose, um festzustellen, ob Probleme auftreten, z. B. die folgenden Probleme:

  • Knotenfehler
  • SNAT-Fehler (Source Network Address Translation)
  • Leistungsprobleme bei Knoteneingabe-/Ausgabevorgängen pro Sekunde (IOPS)
  • Andere Probleme

Wenn die Diagnose keine zugrunde liegenden Probleme erkennt, können Sie die verbleibenden Schritte sicher überspringen.

Schritt 3: Beheben von SNAT-Problemen für öffentliche AKS-API-Cluster

Hat die AKS-Diagnose SNAT-Probleme entdeckt? Wenn ja, führen Sie gegebenenfalls einige der folgenden Aktionen aus:

  • Überprüfen Sie, ob Ihre Verbindungen lange im Leerlauf bleiben, und verlassen Sie sich auf das standardmäßige Leerlauftimeout, um den Port freizugeben. Wenn die Verbindungen dieses Verhalten aufweisen, müssen Sie möglicherweise das Standardtimeout von 30 Minuten reduzieren.

  • Bestimmen Sie, wie ihre Anwendung ausgehende Verbindungen erstellt. Wird z. B. Codeüberprüfung oder Paketerfassung verwendet?

  • Ermitteln Sie, ob diese Aktivität das erwartete Verhalten darstellt, oder zeigt stattdessen, dass sich die Anwendung falsch verhält. Verwenden Sie Metriken und Protokolle in Azure Monitor, um Ihre Ergebnisse zu belegen. Sie können z. B. die Kategorie "Fehlgeschlagen" als Metrik "SNAT-Verbindungen" verwenden.

  • Bewerten Sie, ob geeignete Muster befolgt werden.

  • Bewerten Sie, ob Sie die SNAT-Portauslastung verringern sollten, indem Sie zusätzliche ausgehende IP-Adressen und mehr zugewiesene ausgehende Ports verwenden. Weitere Informationen finden Sie unter Skalieren der Anzahl der verwalteten ausgehenden öffentlichen IPs und Konfigurieren der zugewiesenen ausgehenden Ports.

Schritt 4: Beheben von IOPS-Leistungsproblemen

Wenn die AKS-Diagnose Probleme aufdeckt, die die IOPS-Leistung verringern, führen Sie gegebenenfalls einige der folgenden Aktionen aus:

  • Um IOPS auf Vm-Skalierungsgruppen zu erhöhen, ändern Sie die Datenträgergröße, indem Sie einen neuen Knotenpool bereitstellen.

  • Erhöhen Sie die Knoten-SKU-Größe für mehr Arbeitsspeicher und CPU-Verarbeitungsfunktion.

  • Erwägen Sie die Verwendung von Ephemeral OS.

  • Beschränken Sie die CPU- und Speicherauslastung für Pods. Diese Grenzwerte verhindern die CPU-Auslastung von Knoten und Situationen mit nicht genügend Arbeitsspeicher.

  • Verwenden Sie Planungstopologiemethoden, um weitere Knoten hinzuzufügen und die Last auf die Knoten zu verteilen. Weitere Informationen finden Sie unter Pod-Topologie-Spread-Einschränkungen.

Schritt 5: Beheben von Threadingproblemen

Kubernetes-Komponenten wie Kubelets und Containerlaufzeiten basieren stark auf Threading und erzeugen regelmäßig neue Threads. Wenn die Zuweisung neuer Threads nicht erfolgreich ist, kann sich dieser Fehler wie folgt auf die Dienstbereitschaft auswirken:

  • Der Knotenstatus ändert sich in "Nicht bereit", wird aber von einem Behebungsdienst neu gestartet und kann wiederhergestellt werden.

  • In den Protokolldateien "/var/log/messages " und "/var/log/syslog " treten wiederholt die folgenden Fehlereinträge auf:

    pthread_create fehlgeschlagen: Die Ressource ist von verschiedenen Prozessen vorübergehend nicht verfügbar.

    Zu den zitierten Prozessen gehören containerd und möglicherweise kubelet.

  • Der Knotenstatus wird bald nach dem Schreiben der pthread_create Fehlereinträge in die Protokolldateien in "Nicht bereit" geändert.

Prozess-IDs (PIDs) stellen Threads dar. Die Standardanzahl von PIDs, die ein Pod verwenden kann, hängt möglicherweise vom Betriebssystem ab. Die Standardnummer ist jedoch mindestens 32.768. Dieser Betrag ist für die meisten Situationen mehr als ausreichend PIDs. Gibt es bekannte Anwendungsanforderungen für höhere PID-Ressourcen? Falls nicht, reicht möglicherweise sogar eine achtfache Erhöhung auf 262.144 PIDs nicht aus, um eine ressourcenintensive Anwendung zu berücksichtigen.

Identifizieren Sie stattdessen die beleidigte Anwendung, und ergreifen Sie dann die entsprechende Aktion. Ziehen Sie andere Optionen in Betracht, z. B. das Erhöhen der VM-Größe oder das Aktualisieren von AKS. Diese Aktionen können das Problem vorübergehend beheben, stellen aber keine Garantie dafür, dass das Problem nicht wieder auftritt.

Führen Sie den folgenden Shellbefehl aus, um die Threadanzahl für jede Steuerelementgruppe (cgroup) zu überwachen und die acht obersten cgroups zu drucken:

watch 'ps -e -w -o "thcount,cgname" --no-headers | awk "{a[\$2] += \$1} END{for (i in a) print a[i], i}" | sort --numeric-sort --reverse | head --lines=8'

Weitere Informationen finden Sie unter "Einschränkungen und Reservierungen für Prozess-ID".

Kubernetes bietet zwei Methoden zum Verwalten der PID-Erschöpfung auf Knotenebene:

  1. Konfigurieren Sie die maximale Anzahl von PIDs, die auf einem Pod innerhalb eines Kubelets zulässig sind, mithilfe des --pod-max-pids Parameters. Diese Konfiguration legt die pids.max Einstellung innerhalb der cgroup der einzelnen Pods fest. Sie können die --system-reserved --kube-reserved Und-Parameter auch verwenden, um die System- bzw. Kubelet-Grenzwerte zu konfigurieren.

  2. Konfigurieren der PID-basierten Räumung.

Hinweis

Standardmäßig ist keine dieser Methoden eingerichtet. Darüber hinaus können Sie derzeit keine der beiden Methoden mithilfe der Knotenkonfiguration für AKS-Knotenpools konfigurieren.

Schritt 6: Verwenden einer höheren Dienstebene

Sie können sicherstellen, dass der AKS-API-Server über eine hohe Verfügbarkeit verfügt, indem Sie eine höhere Dienstebene verwenden. Weitere Informationen finden Sie unter Azure Kubernetes Service (AKS) Uptime SLA.

Weitere Informationen