Freigeben über

Problembehandlung bei einer Änderung eines fehlerfreien Knotens in den Status "Nicht bereit"

  • Artikel

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

Voraussetzungen

Symptome

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

kubectl describe nodes

Ursache

Das Kubelet hat den Status "Bereit" beendet.

Überprüfen Sie die Ausgabe des kubectl describe nodes Befehls, um das Feld "Bedingungen " und die Blöcke "Kapazität" und "Allocatable " zu finden. Werden die Inhalte dieser Felder erwartungsgemäß angezeigt? (Beispiel: in der Feld "Bedingungen " enthält die message Eigenschaft die Zeichenfolge "kubelet is posting ready status"?) Wenn Sie in diesem Fall direkten Zugriff auf secure Shell (SSH) 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:

# To check messages file,
cat /var/log/messages

# To check kubelet and containerd daemon logs,
journalctl -u kubelet > kubelet.log
journalctl -u containerd > containerd.log

Nachdem Sie diese Befehle ausgeführt haben, überprüfen Sie die Nachrichten- und Daemonprotokolldateien, um weitere Informationen zum Fehler zu erfahren.

Lösung

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

Wenn alle Clusterknoten auf einen Status "Nicht bereit" zurückgerückt wurden, überprüfen Sie, ob Änderungen auf Netzwerkebene vorgenommen wurden. Beispiele für Änderungen auf Netzwerkebene sind:

  • Änderungen im Domain Name System (DNS)
  • Firewallregeländerungen wie Port, vollqualifizierte Domänennamen (FQDNs) usw.
  • Netzwerksicherheitsgruppen (NSGs) hinzugefügt
  • Angewendete oder geänderte Routentabellenkonfigurationen für AKS-Datenverkehr

Wenn Änderungen auf Netzwerkebene vorgenommen wurden, nehmen Sie alle erforderlichen Korrekturen vor. Wenn Sie über direkten Zugriff auf secure Shell (SSH) auf den Knoten verfügen, können Sie den Befehl oder telnet den curl Befehl verwenden, um die Konnektivität mit den anforderungen von AKS ausgehend zu überprüfen. Nachdem Sie die Probleme behoben haben, beenden Sie die Knoten, und starten Sie sie neu. Wenn die Knoten nach diesen Fixes in einem fehlerfreien Zustand bleiben, können Sie die verbleibenden Schritte sicher überspringen.

Schritt 2: Beenden und Neustarten der Knoten

Wenn nur wenige Knoten auf den Status "Nicht bereit " zurückgerückt sind, beenden Sie einfach die Knoten, und starten Sie sie neu. Diese Aktion allein kann die Knoten in einen fehlerfreien Zustand zurückgeben. Überprüfen Sie dann die Übersicht über die Azure Kubernetes-Dienstdiagnose, um zu ermitteln, ob Probleme auftreten, z. B. die folgenden Probleme:

  • Knotenfehler
  • Fehler bei der Netzwerkadressenübersetzung (Source Network Address Translation, SNAT)
  • Leistungsprobleme bei der Eingabe/Ausgabe pro Sekunde (Input/Output Operations Per Second, IOPS) des Knotens
  • Andere Probleme

Wenn die Diagnose keine zugrunde liegenden Probleme erkennt und die Knoten an den Status "Bereit" zurückgegeben werden, 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 aufgedeckt? Wenn ja, führen Sie gegebenenfalls einige der folgenden Aktionen aus:

  • Überprüfen Sie, ob Ihre Verbindungen lange im Leerlauf bleiben und sich auf das Standardtimeout des Leerlaufs verlassen, 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?

  • Bestimmen Sie, ob diese Aktivität das erwartete Verhalten darstellt oder stattdessen zeigt, dass die Anwendung falsch funktioniert. Verwenden Sie Metriken und Protokolle in Azure Monitor, um Ihre Ergebnisse zu untermauern. Beispielsweise können Sie die Kategorie "Fehlgeschlagen" als SNAT Connections-Metrik verwenden.

  • Bewerten Sie, ob geeignete Muster befolgt werden.

  • Prüfen Sie, ob die SNAT-Portüberlastung durch die Verwendung zusätzlicher ausgehender IP-Adressen und mehr zugewiesener ausgehender Ports abmildern sollten. Weitere Informationen finden Sie unter Skalieren der Anzahl der verwalteten ausgehenden öffentlichen IPs und Konfigurieren der zugewiesenen ausgehenden Ports.

Weitere Informationen zur Problembehandlung bei SNAT-Portexhaution finden Sie unter "Problembehandlung bei SNAT-Portausschöpfung auf AKS-Knoten".

Schritt 4: Beheben von IOPS-Leistungsproblemen

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

  • Um IOPS auf VM-Skalierungssätzen zu erhöhen, wählen Sie eine größere Datenträgergröße aus, die eine bessere IOPS-Leistung bietet, indem Sie einen neuen Knotenpool bereitstellen. Direktes Ändern der Größe von VMSS wird nicht unterstützt. Weitere Informationen zum Ändern der Größe von Knotenpools finden Sie unter Ändern der Größe von Knotenpools in Azure Kubernetes Service (AKS).For more information on resizing node pools, see Resize node pools in Azure Kubernetes Service (AKS).

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

  • Erwägen Sie die Verwendung des kurzlebigen Betriebssystems.

  • Beschränken Sie die CPU- und Arbeitsspeicherauslastung für Pods. Diese Grenzwerte tragen dazu bei, die CPU-Auslastung von Knoten und Situationen außerhalb des Arbeitsspeichers zu verhindern.

  • Verwenden Sie Planungstopologiemethoden, um weitere Knoten hinzuzufügen und die Last zwischen den Knoten zu verteilen. Weitere Informationen finden Sie unter "Pod topology spread constraints".

Schritt 5: Beheben von Threadingproblemen

Kubernetes-Komponenten wie Kubelets und Containerlaufzeiten basieren stark auf Threading, und sie werden regelmäßig zu neuen Threads spawnen. Wenn die Zuweisung neuer Threads fehlschlägt, kann dieser Fehler die Dienstbereitschaft wie folgt beeinträchtigen:

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

  • In den Protokolldateien /var/log/messages und /var/log/syslog gibt es wiederholt Vorkommen der folgenden Fehlereinträge:

    pthread_create fehlgeschlagen: Ressource durch verschiedene Prozesse vorübergehend nicht verfügbar.

    Zu den zitierten Prozessen gehören Containerd und möglicherweise Kubelet.

  • Der Knotenstatus wird in "Nicht bereit" geändert, nachdem die Fehlereinträge in die pthread_create Protokolldateien geschrieben wurden.

Prozess-IDs (PIDs) stellen Threads dar. Die Standardanzahl der PIDs, die ein Pod verwenden kann, kann vom Betriebssystem abhängig sein. Die Standardzahl ist jedoch mindestens 32.768. Diese Menge ist mehr als genug PIDs für die meisten Situationen. Gibt es irgendwelche bekannten Anwendungsanforderungen für höhere PID-Ressourcen? Wenn dies nicht der Fall ist, dann könnte selbst eine Verachtfachung auf 262.144 PIDs nicht ausreichen, um eine ressourcenintensive Anwendung zu unterstützen.

Identifizieren Sie stattdessen die fehlerhafte Anwendung und ergreifen Sie dann die entsprechenden Maßnahmen. Ziehen Sie andere Optionen in Betracht, wie z. B. die Vergrößerung der VM oder ein Upgrade von AKS. Diese Maßnahmen können das Problem vorübergehend eindämmen, sind aber keine Garantie dafür, dass das Problem nicht wieder auftritt.

Um die Anzahl der Threads für jede Steuerelementgruppe (cgroup) zu überwachen und die acht besten cgroups zu drucken, führen Sie den folgenden Shell-Befehl aus:

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 Prozess-ID-Grenzwerte und Reservierungen.

Kubernetes bietet zwei Methoden zur Verwaltung der PID-Erschöpfung auf der Knotenebene:

  1. Konfigurieren Sie die maximale Anzahl von PIDs, die auf einem Pod in einem Kubelet zulässig sind, indem Sie den --pod-max-pids Parameter verwenden. Diese Konfiguration legt die pids.max Einstellung innerhalb der C-Gruppe der einzelnen Pods fest. Sie können auch die System- bzw. Kubelet-Grenzwerte mithilfe der --system-reserved Parameter --kube-reserved konfigurieren.

  2. Konfigurieren der PID-basierten Entfernung

Notiz

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

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 im Azure Kubernetes Service (AKS) Uptime SLA.

Weitere Informationen