Fehlerbehebung bei Windows Server-Knotenpools

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

In diesem Dokument erfahren Sie, wie Sie diese häufigen Probleme diagnostizieren und beheben können, damit 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 gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Allgemeinere Anleitungen finden Sie in der Kubernetes-Dokumentation zum Debuggen von Pods und Diensten.

Probleme mit Containerd-Knoten

Informationen zum Beheben von Problemen bei Verwendung eines containerd-Knoten-Images finden Sie unter Probleme in Windows Server-Knotenpools.

Windows-Pods können nicht gestartet werden

Inkompatibilitäten zwischen dem Basis-Image und den Windows Server-Host-Betriebssystemversionen 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 mit der Windows Server-Version des Hostknotens inkompatibel ist.

Lösung

Erstellen Sie Ihre Container-Images mit Windows-Basis-Images, die die Windows-Updates von März 2020 oder höher enthalten. Weitere Informationen zur Kompatibilität von Microsoft-Containern finden Sie in der Dokumentation von Microsoft zum Problem mit der Kompatibilitä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 haben den Status ErrImagePull.

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 für den kubelet-Agent ein Zeitlimit überschritten wird und er beim Herunterladen und Extrahieren der Containerebenen fehlschlägt.

Lösung

Versuchen Sie Folgendes, um diese Fehler beim Abrufen von Bildern zu beheben:

  • Knoten-CPU erhöhen: Das Extrahieren von Containern wird parallel auf mehreren Kernen ausgeführt. Maschinentypen mit mehr Kernen verkürzen die gesamte Pull-Zeit.
  • Bild-Ebenen optimieren: Um das Docker-Ebenen-Caching zu verbessern und die Wahrscheinlichkeit zu erhöhen, dass das Abrufen von Images wiederholt erfolgreich ist, teilen Sie Ihre Anwendungsebenen in kleinere Ebenen auf. Weitere Informationen finden Sie in der Dokumentation zum Docker-Speichertreiber unter Images und Ebenen.
  • Manuelle Pulls verwenden: Stellen Sie eine Verbindung zu Ihren Windows Server-Knoten her und führen Sie den Befehl docker pull manuell für Container-Images aus, bevor Sie Ihre Pods erstellen.

Allgemeine Hinweise finden Sie unter Fehlerbehebung bei Image-Abrufen.

Image-Familie hat End of Life erreicht

GKE stellt ältere Windows Server-Imagefamilien regelmäßig ein, wenn der Anbietersupport 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-Imagefamilie wird in GKE nicht mehr unterstützt.

Lösung

Wählen Sie ein verfügbares und unterstütztes Windows-Image aus. Das Enddatum des Supports für GKE-Windows-Knoten-Images finden Sie mit dem Befehl gcloud container get-server-config, 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

Bei Vorgängen zum Erstellen von Knotenpools tritt eine Zeitüberschreitung auf, bevor sie abgeschlossen werden.

Ursache

Die Erstellung eines Knotenpools kann zu einer Zeitüberschreitung führen, wenn Sie eine große Anzahl von Knoten erstellen (z. B. 500) und es sich um den ersten Knotenpool im Cluster handelt, der ein Windows Server-Image verwendet.

Lösung

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

Windows-Knoten sind im Status NotReady mit folgendem Fehler: PLEG is not healthy

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

Symptome

  • Windows-Knoten haben den Status NotReady.
  • In Ereignissen oder Protokollen 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.
  • Das Erstellen von Windows-Pods auf maximal einen Pod alle 30 Sekunden beschränken.

Inkonsistent TerminationGracePeriod

Unterschiede zwischen den Shutdown-Timern für Windows-Container und den Einstellungen für die Kulanzfrist in Kubernetes 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 von dem im Kubernetes-Pod-Manifest angegebenen Kulanzzeitraum.

Lösung

Sie können das Zeitlimit für Windows-Container ändern, indem Sie die containerlokalen Registrierungsschlüssel beim Erstellen des Images bearbeiten. Richten Sie das Feld TerminationGracePeriodSeconds in Ihrem Pod-Manifest entsprechend aus.

Probleme mit der Netzwerkverbindung

Nicht übereinstimmende MTU-Größen (Maximum Transmission Unit) zwischen der Netzwerkfunktion des Windows Server-Containers 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 oder Paketverluste auf.

Ursache

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

Lösung

Konfigurieren Sie sowohl den MTU-Wert der Container-Netzwerkschnittstelle als auch den MTU-Wert der Windows Server-Knoten-Netzwerkschnittstelle auf 1460 oder niedriger. Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter Bekannte Probleme bei Windows-Containern.

Probleme beim Starten von Knoten

Bei neuen Windows Server-Instanzen kann es vorkommen, dass Initialisierungsskripts nicht abgeschlossen oder nicht bei der Steuerungsebene registriert werden.

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 beitreten kann.

Lösung

Sehen Sie sich die Ausgabe des seriellen Ports des Knotens an, um herauszufinden, 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 Computing-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 kube-proxy-Komponente zu vorübergehenden Verzögerungen beim Netzwerkrouting, während die Regeln für Host Network Service (HNS) Load Balancer neu verarbeitet werden.

Symptome

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

Ursache

Für GKE-Cluster mit Version 1.24 oder früher muss die Komponente bei einem Ereignis, das die kube-proxy-Komponente auf einem Windows-Knoten neu startet (z. B. Knotenstart, Knotenupgrade oder manueller Neustart), 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 in der Pull-Anfrage auf GitHub beschrieben.

Nächste Schritte