Fehlerbehebung bei Windows Server-Knotenpools

Wenn Sie Windows Server-Knotenpools in der Google Kubernetes Engine (GKE)ausführen, können Probleme auftreten, z. B. Pods, die nicht gestartet werden, Fehler beim Abrufen von Windows- Container-Images, Probleme mit der Netzwerkverbindung oder Knoten, die nicht gestartet werden.

In diesem Dokument erfahren Sie, wie Sie diese häufigen Probleme diagnostizieren und beheben und wie Sie dafür sorgen, dass Ihre Windows-basierten Anwendungen zuverlässig ausgeführt werden.

Diese Informationen sind wichtig für Plattformadministratoren und -operatoren, die GKE-Cluster mit Windows-Knotenpools verwalten, sowie für Anwendungsentwickler, die Windows-basierte Anwendungen in GKE bereitstellen und ausführen. Weitere Informationen zu den häufigsten Rollen und Beispiel aufgaben, auf die wir uns im Google Cloud Inhalt beziehen, finden Sie unter Häufige GKE Nutzerrollen und -aufgaben.

Allgemeinere Anleitungen finden Sie in der Kubernetes-Dokumentation zum Debugging von Pods undDiensten.

Probleme mit Containerd-Knoten

Informationen zum Beheben von Problemen bei der Verwendung eines Containerd-Knoten-Images finden Sie unter Probleme mit Windows Server-Knotenpools.

Windows-Pods können nicht gestartet werden

Inkompatibilitäten zwischen dem Basis-Image und den Windows Server-Hostbetriebssystemversionen können verhindern, dass Pods gestartet werden.

Symptome

  • Windows-Pods können nicht gestartet werden.
  • Der Knoten meldet den Status NotReady.

Ursache

Das Container-Image wurde auf einem älteren Windows-Basis-Image erstellt, das nicht mit der Windows Server-Version des Hostknotens kompatibel ist.

Lösung

Erstellen Sie Ihre Container-Images mit Windows-Basis Images , die Windows-Updates vom März 2020 oder später enthalten. Weitere Informationen zur Microsoft-Containerkompatibilität finden Sie in der Microsoft-Dokumentation zum Problem mit der Inkompatibilität von Windows Server-Containern vom Februar 2020.

Fehler beim Abrufen des Images

Windows Server-Container-Images sind oft deutlich größer als Linux-Images, was zu Zeitüberschreitungen führen kann.

Symptome

  • Fehlermeldungen wie Failed to pull image oder context cancelled.
  • Pods zeigen den Status ErrImagePull an.

Ursache

Windows Server-Container-Images und die einzelnen Ebenen, aus denen sie bestehen, können groß sein. Ihre Größe kann dazu führen, dass der kubelet-Agent beim Herunterladen und Extrahieren der Containerebenen das Zeitlimit erreicht und fehlschlägt.

Lösung

Versuchen Sie die folgenden Lösungen, um diese Fehler beim Abrufen von Images zu beheben:

  • Knoten-CPU erhöhen: Die Containerextraktion wird parallel über Kerne ausgeführt, sodass Maschinentypen mit mehr Kernen die Gesamtabrufzeit verkürzen.
  • Image-Ebenen optimieren: Teilen Sie Ihre Anwendungsebenen in kleinere Ebenen auf, um das Docker-Ebenen-Caching zu verbessern und die Wahrscheinlichkeit zu erhöhen, dass Image- Pull-Wiederholungsversuche erfolgreich sind. Weitere Informationen finden Sie unter Images und Ebenen in der Dokumentation zum Docker-Speichertreiber.
  • Manuelle Pull-Vorgänge verwenden: Stellen Sie eine Verbindung zu Ihren Windows Server-Knoten her und führen Sie manuell den Befehl docker pull für Container-Images aus, bevor Sie Ihre Pods erstellen.

Allgemeinere Ratschläge finden Sie unter Fehler beim Abrufen von Images beheben.

Image-Familie hat End of Life erreicht

GKE stellt ältere Windows Server-Image-Familien regelmäßig ein, wenn der Support des Anbieters endet. Diese Einstellung verhindert die Erstellung von Knotenpools mit diesen Images.

Symptome

Wenn Sie einen Knotenpool mit einem Windows-Image erstellen, erhalten Sie eine Fehlermeldung, die in etwa so aussieht:

WINDOWS_SAC image family for 1.18.20-gke.501 has reached end of life, newer
versions are still available.

Ursache

Die ausgewählte Windows Server-Image-Familie wird in GKE nicht mehr unterstützt.

Lösung

Wählen Sie ein Windows-Image aus, das verfügbar ist und unterstützt wird. Sie können das Supportenddatum für GKE-Windows-Knoten-Images mit dem gcloud container get-server-config Befehl ermitteln, wie unter GKE- und Windows-Versionen zuordnen beschrieben.

Zeitüberschreitung beim Erstellen des Knotenpools

Wenn Sie eine große Anzahl von Windows Server-Knoten gleichzeitig initialisieren, kann es zu Zeitüberschreitungen kommen.

Symptome

Die Vorgänge zur Knotenpoolerstellung erreichen das Zeitlimit, bevor sie abgeschlossen sind.

Ursache

Bei der Knotenpoolerstellung kann eine Zeitüberschreitung auftreten, wenn Sie eine große Anzahl von Knoten (z. B. 500) erstellen und der erste Knotenpool im Cluster ein Windows Server-Image verwendet.

Lösung

Reduzieren Sie die anfängliche Anzahl der Knoten beim Erstellen des Knotenpools. Nachdem der Knotenpool erstellt wurde, können Sie die Anzahl der Knoten erhöhen.

Windows-Knoten haben den Status NotReady mit dem Fehler PLEG is not healthy

Wenn Sie mehrere Windows-Container schnell auf einem einzelnen Knoten planen, kann der Pod-Lebenszyklus-Ereignisgenerator (Pod Lifecycle Event Generator, PLEG) überlastet werden.

Symptome

  • Windows-Knoten haben den Status NotReady.
  • In Ereignissen oder Logs wird die Fehlermeldung PLEG is not healthy angezeigt.

Ursache

Ein bekanntes Kubernetes Problem tritt auf, wenn mehrere Pods sehr schnell auf einem einzelnen Windows-Knoten gestartet werden.

Lösung

So beheben Sie PLEG-Fehler und verhindern, dass sie wieder auftreten:

  • Starten Sie den betroffenen Windows Server-Knoten neu.
  • Beschränken Sie die Erstellung von Windows-Pods auf maximal einen Pod alle 30 Sekunden.

Inkonsistente TerminationGracePeriod

Unterschiede zwischen den Shutdown-Timern für Windows-Container und den Kubernetes-Kulanzzeitraumeinstellungen können dazu führen, dass Container unerwartet beendet werden.

Symptome

Container werden von Windows zwangsweise beendet, bevor die im Feld TerminationGracePeriodSeconds konfigurierte Dauer abläuft.

Ursache

Das interne Windows-Systemzeitlimit für den Container unterscheidet sich vom Kulanzzeitraum, der im Kubernetes-Pod-Manifest angegeben ist.

Lösung

Ändern Sie das Windows-Container-Zeitlimit, indem Sie die lokalen Registrierungsschlüssel des Containers zum Zeitpunkt der Image-Erstellung bearbeiten. Passen Sie das Feld TerminationGracePeriodSeconds in Ihrem Pod-Manifest entsprechend an.

Probleme mit der Netzwerkverbindung

Unterschiede in der Größe der maximalen Übertragungseinheit (Maximum Transmission Unit, MTU) zwischen dem Windows Server-Container netzwerk und Google Cloud Netzwerken können zu verworfenen Paketen führen.

Symptome

Bei Anwendungen, die in Windows Server-Containern ausgeführt werden, treten Fehler bei der Netzwerkverbindung auf oder Pakete werden verworfen.

Ursache

Für das Windows Server-Containernetzwerk wird häufig eine Netzwerk-MTU von 1500 angenommen, die nicht mit der MTU von Google Cloud1460 kompatibel ist.

Lösung

Konfigurieren Sie sowohl die MTU der Container-Netzwerkschnittstelle als auch die MTU der Windows Server-Knoten-Netzwerkschnittstelle auf 1460 oder niedriger. Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter Bekannte Probleme für Windows-Container.

Probleme beim Starten von Knoten

Bei neuen Windows Server-Instanzen können Initialisierungsskripts möglicherweise nicht abgeschlossen werden oder sie können sich nicht auf der Steuerungsebene registrieren.

Symptome

Windows Server-Knoten können nicht initialisiert werden oder dem Cluster nicht beitreten.

Ursache

Fehler bei der Knoteninitialisierung verhindern, dass der Knoten gestartet wird oder dem Cluster beitritt.

Lösung

Prüfen Sie die serielle Portausgabe des Knotens, um festzustellen, welche Startfehler das Problem verursachen könnten:

gcloud compute instances get-serial-port-output NODE_NAME \
    --zone=COMPUTE_ZONE

Ersetzen Sie Folgendes:

  • NODE_NAME ist der Name des Knotens.
  • COMPUTE_ZONE: die Compute-Zone für den Knoten.

Intermittierend nicht erreichbare Dienste in Windows-Knoten mit einem Cluster, auf dem Version 1.24 oder früher ausgeführt wird

In Clustern mit Version 1.24 oder früher führt ein Neustart der Komponente kube-proxy zu vorübergehenden Verzögerungen beim Netzwerkrouting, während die Regeln für den Host-Netzwerkdienst-Load-Balancer (Host Network Service, HNS) neu verarbeitet werden.

Symptome

Dienste sind von Pods, die auf Windows-Knoten ausgeführt werden, zeitweise nicht erreichbar.

Ursache

Wenn in GKE-Clustern mit Version 1.24 oder früher ein Ereignis die Komponente kube-proxy auf einem Windows-Knoten neu startet (z. B. Knotenstart, Knotenupgrade oder manueller Neustart), muss die Komponente alle HNS-Load-Balancer-Regeln synchronisieren und neu erstellen. Wenn der Cluster eine große Anzahl dieser Regeln hat, kann es zu einer erheblichen Verzögerung bei der Verarbeitung kommen, die etwa 30 Sekunden pro Regel dauert. Während dieser Synchronisierungsverzögerung sind Dienste von Pods, die auf diesem Knoten ausgeführt werden, zeitweise nicht erreichbar. Weitere Informationen finden Sie im ursprünglichen Problem auf GitHub.

Lösung

Aktualisieren Sie die Steuerungsebene Ihres Clusters auf Version 1.25 oder höher. Dieses Verhalten wurde in neueren Versionen erheblich verbessert, wie im Pull-Anfrage auf GitHubbeschrieben.

Nächste Schritte