Cluster mit Windows Server-Knotenpools erstellen

Auf dieser Seite erfahren Sie, wie Sie einen GKE-Cluster (Google Kubernetes Engine) mit Knotenpools erstellen, auf denen Microsoft Windows Server ausgeführt wird. Mit diesem Cluster können Sie Windows Server-Container verwenden. Microsoft Hyper-V-Container werden derzeit nicht unterstützt. Ähnlich wie Linux-Container bieten Windows Server-Container eine Prozess- und Namespace-Isolierung.

Ein Windows Server-Knoten benötigt mehr Ressourcen als ein typischer Linux-Knoten. Windows Server-Knoten benötigen die zusätzlichen Ressourcen, um das Windows-Betriebssystem auszuführen, und für die Windows Server-Komponenten, die nicht in Containern ausgeführt werden können. Da Windows Server-Knoten mehr Ressourcen benötigen, sind Ihre zuweisbaren Ressourcen niedriger als bei Linux-Knoten.

Cluster mit Windows Server-Knotenpools erstellen

In diesem Abschnitt erstellen Sie einen Cluster, der einen Windows Server-Container verwendet.

Zum Erstellen dieses Clusters müssen Sie die folgenden Schritte ausführen:

  1. gcloud aktualisieren und konfigurieren
  2. Knoten-Image auswählen
  3. Cluster und Knotenpools erstellen
  4. kubectl-Anmeldedaten abrufen
  5. Auf die Clusterinitialisierung warten

gcloud aktualisieren und konfigurieren

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

Mit den folgenden Methoden können Sie die gcloud-Einstellungen festlegen:

  • Verwenden Sie gcloud init, wenn Sie die Standardeinstellungen ansehen möchten.
  • Verwenden Sie gcloud config, um Ihre Projekt-ID, Zone und Region individuell festzulegen.

gcloud init verwenden

Wenn Sie die Fehlermeldung One of [--zone, --region] must be supplied: Please specify location erhalten, führen Sie diesen Abschnitt aus.

  1. Führen Sie gcloud init aus und folgen Sie der Anleitung:

    gcloud init

    Wenn Sie SSH auf einem Remote-Server verwenden, können Sie mit dem Flag --console-only verhindern, dass mit dem Befehl ein Browserfenster geöffnet wird:

    gcloud init --console-only
  2. Folgen Sie der Anleitung, um gcloud zur Verwendung Ihres Google Cloud-Kontos zu autorisieren.
  3. Erstellen Sie eine neue Konfiguration oder wählen Sie eine vorhandene aus.
  4. Wählen Sie ein Google Cloud-Projekt aus.
  5. Wählen Sie eine Compute Engine-Standardzone aus.

gcloud config verwenden

  • Legen Sie Ihre standardmäßige Projekt-ID fest:
    gcloud config set project project-id
  • Wenn Sie mit zonalen Clustern arbeiten, legen Sie die Compute-Standardzone fest:
    gcloud config set compute/zone compute-zone
  • Wenn Sie mit regionalen Clustern arbeiten, legen Sie die Standardregion für Compute Engine fest:
    gcloud config set compute/region compute-region
  • Aktualisieren Sie gcloud auf die neueste Version:
    gcloud components update

Windows Server-Knoten-Image auswählen

Zur Ausführung in GKE müssen Knoten-Images für Windows Server-Container auf Windows Server Version 2019 (LTSC) oder Windows Server Version 1909 (SAC) erstellt werden. Ein einzelner Cluster kann mehrere Windows Server-Knotenpools mit unterschiedlichen Windows Server-Versionen haben, aber jeder einzelne Knotenpool darf nur eine einzige Windows Server-Version verwenden.

Achten Sie bei der Auswahl des Image-Typs auf Folgendes:

  • SAC-Versionen werden von Microsoft nach ihrer ursprünglichen Veröffentlichung nur 18 Monate lang unterstützt. Wenn Sie SAC als Image-Typ für Ihren Knotenpool auswählen, Ihren Knotenpool jedoch nicht auf neuere GKE-Versionen aktualisieren, die auf neuere SAC-Versionen abzielen, können Sie keine neuen Knoten in Ihrem Knotenpool erstellen, wenn der Supportlebenszyklus für die SAC-Version endet.

  • Wählen Sie SAC nur aus, wenn Sie ein Upgrade Ihres Knotenpools und der regelmäßig darin ausgeführten Container durchführen können. GKE aktualisiert regelmäßig die SAC-Version, die für Windows-Knotenpools in neuen GKE-Releases verwendet wird. Wenn Sie also SAC als Knotenpool-Image-Typ auswählen, müssen Sie Ihre Container häufiger neu erstellen.

  • Neue Windows Server-Features werden normalerweise zuerst in SAC-Versionen eingeführt. Aus diesem Grund werden neue Windows-Funktionen in GKE unter Umständen zuerst in SAC-Knotenpools eingeführt.

Wenn Sie sich nicht sicher sind, welchen Windows Server-Image-Typ Sie verwenden sollen, empfehlen wir Windows Server LTSC, um bei einem Upgrade Ihres Knotenpools Probleme mit der Versionskompatibilität zu vermeiden. Weitere Informationen finden Sie in der Microsoft-Dokumentation unter Windows Server-Wartungskanäle: LTSC und SAC.

Versionskompatibilität

Sowohl Windows Server Core als auch Nano Server können als Basis-Image für Ihre Container verwendet werden.

Windows Server-Container haben wichtige Anforderungen an die Versionskompatibilität:

  • Für LTSC erstellte Windows Server-Container können nicht auf SAC-Knoten ausgeführt werden und umgekehrt.
  • Windows Server-Container, die für eine bestimmte LTSC- oder SAC-Version erstellt wurden, werden nicht auf anderen LTSC- oder SAC-Versionen ausgeführt, ohne für die andere Version neu erstellt zu werden.

Wenn Sie Ihre Windows Server-Container-Images als Images für mehrere Architekturen erstellen, die auf mehrere Windows Server-Versionen angewendet werden können, können Sie diese Komplexität bei der Versionierung besser bewältigen.

Versionszuordnung

Microsoft veröffentlicht etwa alle sechs Monate neue SAC-Versionen und alle zwei bis drei Jahre neue LTSC-Versionen. Diese neuen Versionen sind normalerweise in neuen GKE-Nebenversionen verfügbar. Innerhalb einer GKE-Nebenversion bleiben die LTSC- und SAC-Versionen in der Regel unverändert.

Die folgende Tabelle zeigt die Zuordnung von GKE-Versionen zu Windows Server Core-Versionen:

1.15

GKE-Version SAC-Version LTSC-Version
1.15.x (nur Early Access) 10.0.17763 (Windows Server Version 1809 Core)

1.16

GKE-Version SAC-Version LTSC-Version
1.16.4-gke.25 – 1.16.7.x (nur Beta) 10.0.18363.592 (Windows Server Version 1909 Core) 10.0.17763.973 (Windows Server 2019 Core)
1.16.8-gke.8 bis 1.16.15-gke.1300 10.0.18363.720 (Windows Server Version 1909 Core) 10.0.17763.1098 (Windows Server 2019 Core)
1.16.15-gke.1400+ 10.0.18363.1082 (Windows Server Version 1909 Core) 10.0.17763.1457 (Windows Server 2019 Core)

1.17

GKE-Version SAC-Version LTSC-Version
1.17.x bis 1.17.4-gke.5 10.0.18363.592 (Windows Server Version 1909 Core) 10.0.17763.973 (Windows Server 2019 Core)
1.17.4-gke.6 bis 1.17.8-gke.2 10.0.18363.720 (Windows Server Version 1909 Core) 10.0.17763.1098 (Windows Server 2019 Core)
1.17.8-gke.16 bis 1.17.12-gke.1200 10.0.18363.900 (Windows Server Version 1909 Core) 10.0.17763.1282 (Windows Server 2019 Core)
1.17.12-gke.1500+ 10.0.18363.1082 (Windows Server Version 1909 Core) 10.0.17763.1457 (Windows Server 2019 Core)

1.18

GKE-Version SAC-Version LTSC-Version
1.18.x bis 1.18.9-gke.1200 10.0.18363.900 (Windows Server Version 1909 Core) 10.0.17763.1282 (Windows Server 2019 Core)
1.18.9-gke.1300+ 10.0.18363.1082 (Windows Server Version 1909 Core) 10.0.17763.1457 (Windows Server 2019 Core)

Cluster und Knotenpools erstellen

Zum Ausführen von Windows Server-Containern muss Ihr Cluster mindestens einen Windows- und einen Linux-Knotenpool haben. Sie können einen Cluster nicht nur mit einem Windows Server-Knotenpool erstellen. Der Linux-Knotenpool ist erforderlich, um kritische Cluster-Add-ons auszuführen.

Aufgrund seiner Bedeutung sollten Sie den Linux-Knotenpool nicht auf null verkleinern und sicherstellen, dass er über genügend Kapazität verfügt, um Cluster-Add-ons auszuführen.

gcloud

Erstellen Sie einen Cluster mit den folgenden Feldern:

  gcloud container clusters create cluster-name \
    --enable-ip-alias \
    --num-nodes=number-of-nodes \
    --cluster-version=version-number

Dabei gilt:

  • cluster-name ist der von Ihnen für den Cluster ausgewählte Name.
  • --enable-ip-alias aktiviert die Alias-IP. Für Windows Server-Knoten ist eine Alias-IP erforderlich. Weitere Informationen zu den Vorteilen finden Sie unter Understanding native container routing with Alias IPs.
  • number-of-nodes gibt die Anzahl der Linux-Knoten an, die Sie erstellen. Sie sollten genügend Rechenressourcen bereitstellen, um Cluster-Add-ons auszuführen. Dies ist ein optionales Feld und verwendet den Standardwert 3, falls nichts angegeben wird.
  • version-number muss mindestens 1.16.8-gke.9 sein. Sie können auch das Flag --release-channel verwenden, um eine Release-Version mit der Standardversion 1.16.8-gke.9 oder höher auszuwählen.

Erstellen Sie den Windows Server-Knotenpool mit den folgenden Feldern.

  gcloud container node-pools create node-pool-name \
    --cluster=cluster-name \
    --image-type=image-name \
    --no-enable-autoupgrade \
    --machine-type=machine-type-name

Dabei gilt:

  • node-pool-name ist der Name, den Sie für den Windows Server-Knotenpool auswählen.
  • cluster-name ist der Name des Clusters, den Sie oben erstellt haben.
  • image-name ist WINDOWS_SAC oder WINDOWS_LTSC. Weitere Informationen zu diesen Knoten-Images finden Sie im Abschnitt Windows-Knoten-Image auswählen.
  • --no-enable-autoupgrade deaktiviert das automatische Knotenupgrade. Lesen Sie vor der Aktivierung den Abschnitt Windows Server-Knotenpools aktualisieren.
  • machine-type-name definiert den Maschinentyp. n1-standard-2 ist der empfohlene Mindestmaschinentyp, da Windows Server-Knoten zusätzliche Ressourcen benötigen. Die Maschinentypen f1-micro und g1-small werden nicht unterstützt. Jeder Maschinentyp wird unterschiedlich abgerechnet. Weitere Informationen finden Sie in der Preisübersicht für Maschinentypen.

Console

  1. Rufen Sie in der Cloud Console das Kubernetes Engine-Menü auf.

    Zum Google Kubernetes Engine-Menü

  2. Klicken Sie auf Cluster erstellen.

  3. Geben Sie im Bereich Clustergrundlagen Folgendes ein:

    1. Geben Sie den Namen für den Cluster ein.
    2. Wählen Sie als Standorttyp die gewünschte Region oder Zone für den Cluster aus.
    3. Wählen Sie unter Masterversion die statische Version 1.16.8-gke.9 oder höher aus.
      Oder:
      Wählen Sie unter Masterversion eine Release-Version mit der Standardversion 1.16.8-gke.9 oder höher aus.
  4. Klicken Sie im Navigationsbereich unter Knotenpools auf Standardpool, um Ihren Linux-Knotenpool zu erstellen. Beim Konfigurieren dieses Knotenpools sollten Sie genügend Rechenressourcen bereitstellen, um Cluster-Add-ons auszuführen. Sie müssen außerdem verfügbare Ressourcenkontingente für die Knoten und ihre Ressourcen (z. B. Firewallrouten) haben.

  5. Klicken Sie oben auf der Seite auf Knotenpool hinzufügen, um Ihren Windows Server-Knotenpool zu erstellen.

  6. Geben Sie im Bereich Knotenpooldetails Folgendes ein:

    1. Geben Sie einen Namen für den Knotenpool ein.
    2. Wählen Sie die Knotenversion für Ihre Knoten aus.
    3. Geben Sie die Anzahl der Knoten ein, die im Knotenpool erstellt werden sollen.
  7. Klicken Sie im Navigationsbereich unter Knotenpools auf Knoten.

    1. Wählen Sie in der Drop-down-Liste Image-Typ die Option Windows Server Semi-Annual Channel oder Windows Server Long-Term Servicing Channel aus. Weitere Informationen zu diesen Knoten-Images finden Sie im Abschnitt Windows-Knoten-Image auswählen.
    2. Wählen Sie die Maschinenkonfiguration aus, die standardmäßig für die Instanzen verwendet werden soll. n1-standard-2 ist die empfohlene Mindestgröße, da Windows Server-Knoten zusätzliche Ressourcen benötigen. Die Maschinentypen f1-micro und g1-small werden nicht unterstützt. Jeder Maschinentyp wird unterschiedlich abgerechnet. Weitere Informationen finden Sie in der Preisübersicht für Maschinentypen.
  8. Wählen Sie im Navigationsbereich den Namen Ihres Windows Server-Knotenpools aus. Dadurch kehren Sie zur Seite Knotenpooldetails zurück.

    1. Deaktivieren Sie unter Automatisierung die Option Automatisches Knotenupgrade aktivieren. Lesen Sie vor der Aktivierung den Abschnitt Windows Server-Knotenpools aktualisieren.
  9. Wählen Sie im Navigationsbereich die Option Netzwerk aus.

    1. Achten Sie darauf, dass unter Erweiterte Netzwerkoptionen die Option VPC-natives Traffic-Routing aktivieren (verwendet Alias-IP) ausgewählt aus. Für Windows Server-Knoten ist eine Alias-IP erforderlich. Weitere Informationen zu den Vorteilen finden Sie unter Natives Containerrouting mit Alias-IP-Adressen verstehen.
  10. Klicken Sie auf Erstellen.

Terraform

Sie können mit dem Google Terraform-Anbieter einen GKE-Cluster mit einem Windows Server-Knotenpool erstellen.

Fügen Sie Ihrer Terraform-Konfiguration den folgenden Block hinzu:

resource "google_container_cluster" "cluster" {
  project  = "project-id"
  name     = "cluster-name"
  location = "location"

  min_master_version = "version-number"

  # Enable Alias IPs to allow Windows Server networking.
  ip_allocation_policy {
    cluster_ipv4_cidr_block  = "/14"
    services_ipv4_cidr_block = "/20"
  }

  # Removes the implicit default node pool, recommended when using
  # google_container_node_pool.
  remove_default_node_pool = true
  initial_node_count       = 1
}

# Small Linux node pool to run some Linux-only Kubernetes Pods.
resource "google_container_node_pool" "linux_pool" {
  name     = "linux-pool"
  project  = google_container_cluster.cluster.project
  cluster  = google_container_cluster.cluster.name
  location = google_container_cluster.cluster.location

  node_config {
    image_type = "COS_CONTAINERD"
  }
}

# Node pool of Windows Server machines.
resource "google_container_node_pool" "windows_pool" {
  name     = "node-pool-name"
  project  = google_container_cluster.cluster.project
  cluster  = google_container_cluster.cluster.name
  location = google_container_cluster.cluster.location

  node_config {
    image_type   = "image-name"
    machine_type = "machine-type-name"
  }

  # The Linux node pool must be created before the Windows Server node pool.
  depends_on = [google_container_node_pool.linux_pool]
}

Dabei gilt:

  • project-id ist die ID des Projekts, in dem der Cluster erstellt wird.
  • cluster-name ist der Name des GKE-Clusters.
  • location ist der Standort (Region oder Zone), in dem der Cluster erstellt wird.
  • version-number muss mindestens 1.16.8-gke.9 sein.
  • node-pool-name ist der Name, den Sie für den Windows Server-Knotenpool auswählen.
  • image-name ist WINDOWS_SAC oder WINDOWS_LTSC. Weitere Informationen zu diesen Knoten-Images finden Sie im Abschnitt Windows-Knoten-Image auswählen.
  • machine-type-name definiert den Maschinentyp. n1-standard-2 ist der empfohlene Mindestmaschinentyp, da Windows Server-Knoten zusätzliche Ressourcen benötigen. Die Maschinentypen f1-micro und g1-small werden nicht unterstützt. Jeder Maschinentyp wird unterschiedlich abgerechnet. Weitere Informationen finden Sie in der Preisübersicht für Maschinentypen.

Nachdem Sie einen Windows Server-Knotenpool erstellt haben, wechselt der Cluster für einige Minuten in den Status RECONCILE, während die Steuerungsebene (Master) aktualisiert wird.

kubectl-Anmeldedaten abrufen

Verwenden Sie den Befehl get-credentials, um kubectl für die Arbeit mit dem von Ihnen erstellten Cluster zu aktivieren.

gcloud container clusters get-credentials 

Weitere Informationen zum Befehl get-credentials finden Sie in der SDK-Dokumentation unter get-credentials.

Auf die Clusterinitialisierung warten

Warten Sie vor der Verwendung des Clusters einige Sekunden, bis windows.config.common-webhooks.networking.gke.io erstellt wurde. Dieser Webhook fügt Planungstoleranzen zu Pods hinzu, die mit dem Knotenselektor kubernetes.io/os: windows erstellt wurden, um sicherzustellen, dass sie auf Windows Server-Knoten ausgeführt werden können. Außerdem wird der Pod geprüft, damit er nur Funktionen verwendet, die unter Windows unterstützt werden.

Führen Sie den folgenden Befehl aus, um sicherzustellen, dass der Webhook erstellt wird:

kubectl get mutatingwebhookconfigurations

Die Ausgabe sollte den ausgeführten Webhook zeigen:

NAME                                              CREATED AT
windows.config.common-webhooks.networking.gke.io  2019-12-12T16:55:47Z

Jetzt haben Sie einen Cluster mit zwei Knotenpools (einem Linux- und einem Windows-Knotenpool) und können eine Windows-Anwendung bereitstellen.

Windows Server-Knotenpools upgraden

Die Anforderungen an die Versionskompatibilität von Windows Server-Containern bedeuten, dass Ihre Container-Images unter Umständen neu erstellt werden müssen, damit sie mit der Windows Server-Version für eine neue GKE-Version übereinstimmen, bevor Sie ein Upgrade Ihrer Knotenpools ausführen.

Damit Ihre Container-Images mit Ihren Knoten kompatibel bleiben, sollten Sie sich die Tabelle mit der Versionszuordnung ansehen und Ihre Windows Server-Container-Images als Images für mehrere Architekturen erstellen, die gezielt verschiedene Windows Server-Versionen beliefern. Sie haben dann die Möglichkeit, Ihre Container-Bereitstellungen so zu aktualisieren, dass sie auf die Images für mehrere Architekturen abzielen, die sowohl in der aktuellen als auch in der nächsten GKE-Version funktionieren, bevor Sie manuell ein GKE-Knotenpool-Upgrade aufrufen. Manuelle Knotenpool-Upgrades müssen regelmäßig durchgeführt werden, da Knoten nicht mehr als zwei Nebenversionen hinter der Version der Steuerungsebene liegen dürfen.

Wir empfehlen, automatische Knotenupgrades nur zu aktivieren, wenn Sie fortlaufend Windows Server-Container-Images für mehrere Architekturen erstellen, die auf die neuesten Windows Server-Versionen abzielen, insbesondere wenn Sie Windows Server SAC als Knoten-Image-Typ verwenden. Bei automatischen Knotenupgrades treten weniger Probleme mit dem Image-Typ des Windows Server LTSC-Knotens auf. Es besteht jedoch weiterhin das Risiko, dass Probleme mit der Versionskompatibilität auftreten.

Windows-Updates

Windows-Updates sind für Windows Server-Knoten deaktiviert. Automatische Updates können dazu führen, dass Knoten zu unvorhersehbaren Zeiten neu gestartet werden. Alle nach einem Knotenstart installierten Windows-Updates gehen verloren, wenn der Knoten von GKE neu erstellt wird. Die in neuen GKE-Releases verwendeten Windows Server-Knoten-Images werden regelmäßig aktualisiert, damit in GKE Windows-Updates verfügbar werden. Zwischen der Veröffentlichung von Windows-Updates durch Microsoft und ihrer Bereitstellung in GKE kann es eine Verzögerung geben. Wenn wichtige Sicherheitsupdates veröffentlicht werden, aktualisiert GKE die Windows Server-Knoten-Images so schnell wie möglich.

Logs ansehen und abfragen

Logging wird in GKE-Clustern automatisch aktiviert. Sie können die Logs der Container und die Logs anderer Dienste auf den Windows Server-Knoten mithilfe von Kubernetes Engine Monitoring ansehen.

Das folgende Beispiel zeigt einen Filter zum Abrufen des Container-Logs:

resource.type="k8s_container"
resource.labels.cluster_name="your_cluster_name"
resource.labels.namespace_name="your_namespace_id"
resource.labels.container_name="your_container_name"
resource.labels.Pod_name="your_Pod_name"

Mit Remote Desktop Protocol (RDP) auf einen Windows Server-Knoten zugreifen

Mit RDP können Sie eine Verbindung zu einem Windows Server-Knoten in Ihrem Cluster herstellen. Eine Anleitung zum Herstellen einer Verbindung finden Sie in der Compute Engine-Dokumentation unter Mit Windows-Instanzen verbinden.

Images für mehrere Architekturen erstellen

Sie können die Images für mehrere Architekturen manuell erstellen oder einen Cloud Build-Builder verwenden. Eine Anleitung hierzu finden Sie unter Windows-Images für mehrere Architekturen erstellen.

Windows Server-Knotenpools löschen

Löschen Sie einen Windows Server-Knotenpool mit gcloud oder der Google Cloud Console.

gcloud

gcloud container node-pools delete --cluster=cluster-name node-pool-name

Console

Führen Sie die folgenden Schritte aus, um einen Windows Server-Knotenpool mithilfe der Cloud Console zu löschen:

  1. Rufen Sie in der Cloud Console das Kubernetes Engine-Menü auf.

    Zum Google Kubernetes Engine-Menü

  2. Klicken Sie auf das Stiftsymbol Bearbeiten neben dem Cluster, der den zu löschenden Knotenpool enthält.

  3. Klicken Sie im Abschnitt Knotenpools neben dem zu löschenden Knotenpool auf das Papierkorbsymbol Löschen.

  4. Wenn Sie zur Bestätigung des Vorgangs aufgefordert werden, klicken Sie noch einmal auf Löschen.

Beschränkungen

Einige Kubernetes-Features werden für Windows Server-Container noch nicht unterstützt. Außerdem sind einige Funktionen Linux-spezifisch und funktionieren nicht unter Windows. Eine vollständige Liste der unterstützten und nicht unterstützten Kubernetes-Funktionen finden Sie in der Kubernetes-Dokumentation.

Außerdem werden einige GKE-Funktionen nicht unterstützt.

Für Cluster werden die folgenden Funktionen von Windows Server-Knotenpools nicht unterstützt:

Die folgenden Funktionen von Windows Server-Knotenpools werden nicht unterstützt:

Fehlerbehebung

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

Windows-Pods können nicht gestartet werden

Eine nicht übereinstimmende Version des Windows Server-Containers und des Windows-Knotens, der versucht, den Container auszuführen, kann dazu führen, dass Ihre Windows-Pods nicht gestartet werden.

Wenn die Version Ihres Windows-Knotenpools 1.16.8-gke.8 oder höher ist, lesen Sie die Dokumentation von Microsoft zum Problem mit der Kompatibilität von Windows Server-Containern vom Februar 2020 und erstellen Sie Ihre Container-Images mit Windows-Basis-Images, die die Windows-Updates von März 2020 enthalten. Container-Images, die auf früheren Windows-Basis-Images erstellt wurden, werden auf diesen Windows-Knoten möglicherweise nicht ausgeführt. Außerdem kann der Knoten mit dem Status NotReady ausfallen.

Fehler beim Abrufen des Images

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

Dieses Problem ist unter Umständen aufgetreten, wenn Sie die Fehlermeldungen "Image konnte nicht abgerufen werden" oder "Image-Pull-Kontext abgebrochen" oder den Status ErrImagePull für Ihre Pods sehen.

Probieren Sie die folgenden Optionen aus, um Ihre Windows Server-Container erfolgreich abzurufen:

  • Teilen Sie die Anwendungsebenen des Windows Server-Container-Images in kleinere Ebenen auf, die jeweils schneller abgerufen und extrahiert werden können. Dies kann das Caching der Docker-Ebenen effektiver und Image-Pull-Wiederholungsversuche erfolgreicher machen. Weitere Informationen zu Ebenen finden Sie im Docker-Artikel Über Images, Container und Speichertreiber.

  • Stellen Sie eine Verbindung zu Ihren Windows Server-Knoten her und verwenden Sie manuell den Befehl docker pull für Ihre Container-Images, bevor Sie Ihre Pods erstellen.

  • Legen Sie das Flag image-pull-progress-deadline für den Dienst kubelet fest, um das Zeitlimit für das Abrufen von Container-Images zu erhöhen.

    Legen Sie das Flag fest, indem Sie eine Verbindung zu Ihren Windows-Knoten herstellen und die folgenden PowerShell-Befehle ausführen.

    1. Rufen Sie die vorhandene Befehlszeile für den Kubelet-Dienst aus der Windows-Registry ab.

      PS C:\> $regkey = "HKLM\SYSTEM\CurrentControlSet\Services\kubelet"
      
      PS C:\> $name = "ImagePath"
      
      PS C:\> $(reg query ${regkey} /v ${name} | Out-String) -match `
      "${name}.*(C:.*kubelet\.exe.*)\r"
      
      PS C:\> $kubelet_cmd = $Matches[1]
      
    2. Legen Sie eine neue Befehlszeile für den Kubelet-Dienst mit einem zusätzlichen Flag fest, um das Zeitlimit zu erhöhen.

      PS C:\> reg add ${regkey} /f /v ${name} /t REG_EXPAND_SZ /d "${kubelet_cmd} `
      --image-pull-progress-deadline=15m
      
    3. Bestätigen Sie, dass die Änderung erfolgreich war.

      PS C:\> reg query ${regkey} /v ${name}
      
    4. Starten Sie den kubelet-Dienst neu, damit das neue Flag wirksam wird.

      PS C:\> Restart-Service kubelet
      
    5. Bestätigen Sie, dass der kubelet-Dienst erfolgreich neu gestartet wurde.

      PS C:\> Get-Service kubelet # ensure state is Running
      

Zeitüberschreitung beim Erstellen des Knotenpools

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.

Reduzieren Sie die Anzahl der Knoten, die Sie erstellen, um dieses Problem zu beheben. Sie können die Anzahl der Knoten später erhöhen.

gMSA verwenden

Wenn Sie Probleme bei der Verwendung eines gMSA (verwaltetes Dienstkonto für die Gruppe) haben, kann dies an den Beschränkungen für den Computernamen in Active Directory liegen. Active Directory beschränkt Computernamen auf 15 Zeichen. Wenn Sie GKE verwenden, wird dieser Name vom GKE-Knotennamen abgeleitet. Knotennamen stammen aus dem Namen des Knotenpools, gefolgt von einem eindeutigen String. Wenn der Name des Knotens 15 Zeichen überschreitet, wird er wieder auf 15 Zeichen gekürzt.

Wenn ein Knoten zum Beispiel gke-cluster-windows--node-pool-window-3d3afc34- wnnn heißt, wird er auf GKE-CLUSTER-WIN gekürzt.

Wenn ein anderer Knoten den Namen gke-cluster-windows--node-pool-window-123gtj12-aabb hat, wird er ebenfalls auf GKE-CLUSTER-WIN gekürzt.

Active Directory hat eine Eins-zu-Eins-Beziehung zwischen Computern und Namen. Wenn also zwei Computer denselben Namen haben, tritt ein Fehler auf.

Benennen Sie den Computer um, wenn Sie Active Directory anfügen, um dieses Problem zu vermeiden. Nachdem Sie den Computer umbenannt haben, müssen Sie auch die Kubelet- und Kube-Proxy-Konfiguration des Knotens aktualisieren, um das Problem zu vermeiden, dass der Knoten keine Verbindung mehr mit dem Cluster herstellen kann. Hängen Sie dazu das Flag --hostname-override an den Pfad der Kubelet- und Kube-Proxydienste an. Setzen Sie das Flag auf den Instanznamen Ihres Knotens und starten Sie die Dienste neu.

Führen Sie den folgenden Befehl aus, um die Konfiguration zu aktualisieren:

sc.exe config service-name binPath="existing-service-binpath --hostname-override=node-instance-name"

Dabei gilt:

  • service-name ist kubelet oder kube-proxy. Führen Sie dieses Skript einmal pro Dienst aus.
  • existing-service-binpath ist der binPath des Dienstes. Diesen können Sie mit sc.exe qc service-name abrufen.
  • node-instance-name ist der Instanzname der Knoten-VM.

Dadurch wird das Problem behoben und die Knoten- und Host-Pods können angezeigt werden. Außerdem werden Namenskonflikte in Active Directory vermieden.

Hinweis zu Managed Service for Microsoft Active Directory

In Managed Service for Microsoft Active Directory sind zum Einrichten eines gMSA einige zusätzliche Schritte erforderlich. Der Prozess unterscheidet sich aufgrund von Abweichungen zwischen den Standardobjekten und -berechtigungen in Managed Microsoft AD und Standard-AD ein wenig. So erstellen Sie ein gMSA in Managed Microsoft AD

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

Dies ist ein bekanntes Kubernetes-Problem, das auftritt, wenn mehrere Pods sehr schnell auf einem einzelnen Windows-Knoten gestartet werden. Starten Sie zum Beheben dieses Problems den Windows Server-Knoten neu. Sie können dieses Problem vermeiden, wenn Sie die Rate, mit der Windows-Pods erstellt werden, auf einen Pod alle 30 Sekunden beschränken.

TerminationGracePeriod nicht konsistent

Das Windows-Systemzeitlimit für den Container kann von dem von Ihnen konfigurierten Kulanzzeitraum abweichen. Dieser Unterschied kann dazu führen, dass Windows das Beenden des Containers vor Ablauf des an die Laufzeit übergebenen Kulanzzeitraums erzwingt.

Sie können das Windows-Zeitlimit ändern, indem Sie den lokalen Registrierungsschlüssel des Containers zum Zeitpunkt der Image-Erstellung bearbeiten. Wenn Sie das Windows-Zeitlimit ändern, müssen Sie unter Umständen auch die TerminationGracePeriodSeconds entsprechend anpassen.

Probleme mit der Netzwerkverbindung

Wenn bei Ihren Windows Server-Containern Netzwerkverbindungsprobleme auftreten, kann dies daran liegen, dass für das Windows Server-Containernetzwerk häufig eine Netzwerk-MTU von 1500 angenommen wird, die nicht mit der Google Cloud-MTU von 1460 kompatibel ist.

Prüfen Sie, ob die MTU der Netzwerkschnittstelle im Container und die Netzwerkschnittstellen des Windows Server-Knotens 1460 oder kleiner sind. Informationen zum Festlegen der MTU finden Sie unter Bekannte Probleme bei Windows-Containern.

Nächste Schritte