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. Windows Server-Knoten-Image auswählen
  2. gcloud aktualisieren und konfigurieren
  3. Cluster und Knotenpools erstellen
  4. kubectl-Anmeldedaten abrufen
  5. Auf die Clusterinitialisierung warten

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), Windows Server Version 20H2 (SAC) oder Windows Server Version 2022 (LTSC) 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.

Bei der Auswahl des Knoten-Images müssen Sie Folgendes beachten:

  • Supportzeitraum:
    • Der Supportzeitraum für ein Windows Server-Knoten-Image ist vom Supportzeitraum von Microsoft abhängig, wie unter Supportrichtlinie für Betriebssystem-Images erläutert. Sie können das Supportenddatum für GKE-Windows-Knoten-Images mit dem Befehl gcloud container get-server-config ermitteln, wie im Abschnitt GKE- und Windows-Versionen zuordnen erläutert.
    • 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. Weitere Informationen zur Unterstützung von Google beim Windows Server-Betriebssystem Wir empfehlen die Verwendung eines LTSC, da er einen längeren Lebenszyklus hat.
    • Wählen Sie SAC nicht aus, wenn Sie Ihren GKE-Cluster im stabilen Release-Kanal registrieren. SAC-Versionen werden von Microsoft nur für 18 Monate unterstützt. Es besteht das Risiko, dass das Image des SAC-Knoten-Images nicht mehr unterstützt wird, obwohl die stabile GKE-Version noch verfügbar ist.
  • Versionskompatibilität und -komplexität:
    • Wählen Sie SAC nur aus, wenn Sie ein Upgrade Ihres Knotenpools und der darin ausgeführten Container regelmäßig 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.
    • 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.
    • 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.
  • Neue Funktionen:
    • 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.
    • Ziehen Sie ein SAC in Betracht, wenn Sie von Funktionen abhängen, die noch nicht im LTSC-Release verfügbar sind.

  • Containerlaufzeit:

    • Sowohl für die Windows Server LTSC- als auch für die SAC-Knoten-Images kann die Containerlaufzeit "Docker" oder "containerd" sein. Für GKE-Knotenversionen ab 1.21.1-gke.2200 empfehlen wir die Verwendung der containerd-Laufzeit. Weitere Informationen finden Sie unter Knoten-Images.

gcloud aktualisieren und konfigurieren

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

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.

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 empfehlen wir, Autoscaling zu aktivieren, um sicherzustellen, dass Ihr Linux-Knotenpool über genügend Kapazität zum Ausführen von Cluster-Add-ons verfügt.

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 \
    --release-channel CHANNEL

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 ist die Anzahl der Linux-Knoten, 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 ist die spezifische Clusterversion, die Sie verwenden möchten, also 1.16.8-gke.9 oder höher. Wenn Sie keine Release-Version angeben, registriert GKE Ihren Cluster in der ausgereiftesten Release-Version, in der diese Version verfügbar ist.
  • CHANNEL ist der Release-Kanal für die Registrierung des Clusters, der entweder rapid, regular, stable oder None ist. Standardmäßig wird der Cluster in der Release-Version regular registriert, es sei denn, mindestens eines der folgenden Flags ist angegeben: --cluster-version, --release-channel, --no-enable-autoupgrade, --no-enable-autorepair. Sie müssen None angeben, wenn Sie eine Clusterversion auswählen und nicht möchten, dass Ihr Cluster in einer Release-Version registriert wird.

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 \
    --windows-os-version=WINDOWS_OS_VERSION

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: Sie können einen der folgenden Werte angeben:

    Weitere Informationen zu diesen Knoten-Images finden Sie im Abschnitt Windows Server-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.

  • WINDOWS_OS_VERSION: Definiert die Windows-Betriebssystemversion, die für den Image-Typ WINDOWS_LTSC_CONTAINERD verwendet werden soll. Dies ist ein optionales Flag. Wenn keine Angabe erfolgt, wird die Standardversion des Betriebssystems LTSC2019 verwendet. Legen Sie den Wert auf ltsc2022 fest, um einen Windows Server 2022-Knotenpool zu erstellen. Legen Sie den Wert auf ltsc2019 fest, um einen Windows Server 2019-Knotenpool zu erstellen.

Das folgende Beispiel zeigt, wie Sie einen Windows Server 2022-Knotenpool erstellen:

gcloud container node-pools create node_pool_name \
    --cluster=cluster_name \
    --image-type=WINDOWS_LTSC_CONTAINERD \
    --windows-os-version=ltsc2022

Das folgende Beispiel zeigt, wie Sie einen vorhandenen Windows-Knotenpool aktualisieren, um das Windows Server 2022-Betriebssystem-Image zu verwenden:

gcloud container node-pools create node_pool_name \
    --cluster=cluster_name \
    --windows-os-version=ltsc2022

Console

  1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

    Zur Seite „Google Kubernetes Engine“

  2. Klicken Sie auf 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 Version der Steuerungsebene eine Release-Version aus oder geben Sie eine statische Version an. Die statische Version muss 1.16.8-gke.9 oder höher sein.

  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 für statische Knoten die Knotenversion 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 eines der folgenden Knoten-Images aus:

      • Windows Long-Term Servicing Channel mit Docker
      • Windows Long-Term Servicing Channel mit containerd
      • Windows Semi-Annual Channel mit Docker
      • Windows Semi-Annual Channel mit containerd

      Weitere Informationen 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. Entfernen Sie unter Automatisierung das Häkchen aus dem Kästchen Automatisches Knotenupgrade aktivieren. Lesen Sie vor dem Aktivieren von automatischen Upgrades den Abschnitt Upgrade von Windows Server-Knotenpools.

  9. Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.

    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_count = 1

  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_count = 1

  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: Sie können einen der folgenden Werte angeben:

    Weitere Informationen zu diesen Knoten-Images finden Sie im Abschnitt Windows Server-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 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 CLUSTER_NAME

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

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

GKE- und Windows-Versionen zuordnen

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.

Um die Versionszuordnung zwischen GKE-Versionen und Windows Server-Versionen aufzurufen, verwenden Sie den Befehl gcloud beta container get-server-config:

gcloud beta container get-server-config

Die Versionszuordnung wird im Feld windowsVersionMaps der Antwort zurückgegeben. Wenn Sie die Antwort filtern möchten, um die Versionszuordnung für bestimmte GKE-Versionen in Ihrem Cluster zu sehen, gehen Sie in einer Linux-Shell oder in Cloud Shell folgendermaßen vor:

  1. Legen Sie die folgenden Variablen fest:

    CLUSTER_NAME=CLUSTER_NAME
NODE_POOL_NAME=NODE_POOL_NAME
ZONE=COMPUTE_ZONE

    Dabei gilt:

    • CLUSTER_NAME: Der Name Ihres Clusters.
    • NODE_POOL_NAME ist der Name des Windows Server-Knotenpools.
    • COMPUTE_ZONE ist die Computing-Zone für den Cluster.

  2. Rufen Sie die Knotenpoolversion ab und speichern Sie sie in der Variable NODE_POOL_VERSION:

    NODE_POOL_VERSION=`gcloud container node-pools describe $NODE_POOL_NAME \
--cluster $CLUSTER_NAME --zone $ZONE --format="value(version)"`

  3. Rufen Sie die Windows Server-Versionen für NODE_POOL_VERSION ab:

    gcloud beta container get-server-config \
    --format="yaml(windowsVersionMaps.\"$NODE_POOL_VERSION\")"

    Die entsprechende Ausgabe sieht etwa so aus:

    windowsVersionMaps:
  1.18.6-gke.6601:
    windowsVersions:
    - imageType: WINDOWS_SAC
      osVersion: 10.0.18363.1198
      supportEndDate:
        day: 10
        month: 5
        year: 2022
    - imageType: WINDOWS_LTSC
      osVersion: 10.0.17763.1577
      supportEndDate:
        day: 9
        month: 1
        year: 2024

  4. Rufen Sie die Windows Server-Version für den Image-Typ WINDOWS_SAC ab:

    gcloud beta container get-server-config \
  --flatten=windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions \
  --filter="windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions.imageType=WINDOWS_SAC" \
  --format="value(windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions.osVersion)"

    Die entsprechende Ausgabe sieht etwa so aus:

    10.0.18363.1198

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 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 Ihnen, Upgrade-Benachrichtigungen mit Pub/Sub zu abonnieren, um proaktiv Informationen zu neuen GKE-Versionen und den von ihnen verwendeten Windows-Betriebssystemversionen zu erhalten.

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.

Kommunikation von Windows-Pods und -Diensten steuern

Sie können die Kommunikation von Windows-Pods und -Diensten mithilfe von Netzwerkrichtlinien steuern.

Sie können einen Windows Server-Container auf Clustern verwenden, für die die Netzwerkrichtlinie in GKE ab Version 1.22.2 aktiviert ist. Dieses Feature ist für Cluster verfügbar, die die Knoten-Image-Typen WINDOWS_LTSC oder WINDOWS_LTSC_CONTAINERD verwenden.

Wenn Ihre Steuerungsebenen oder Knoten frühere Versionen ausführen, können Sie Ihre Knotenpools zu einer Version migrieren, die Netzwerkrichtlinie unterstützt. Dazu aktualisieren Sie Ihre Knotenpools und Ihre Steuerungsebene auf GKE-Version 1.22.2 oder höher. Diese Option ist nur verfügbar, wenn Sie Ihren Cluster mit dem Flag --enable-dataplane-v2 erstellt haben.

Nachdem Sie die Netzwerkrichtlinie aktiviert haben, sind alle zuvor konfigurierten Richtlinien, einschließlich der Richtlinien, die in Windows Server-Containern nicht funktioniert haben, bevor Sie das Feature aktiviert haben, gültig.

Einige Cluster können nicht mit Windows Server-Containern auf Clustern mit aktivierter Netzwerkrichtlinie verwendet werden. Weitere Informationen finden Sie im Abschnitt Einschränkungen.

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.

gMSA verwenden

In den folgenden Schritten wird die Verwendung eines Group Managed Service Accounts (gSAS) mit Ihren Windows Server-Knotenpools beschrieben.

  1. Konfigurieren Sie Windows Server-Knoten im Cluster für den automatischen Beitritt zur AD-Domain. Eine Anleitung dazu finden Sie unter Windows Server-Knoten für den automatischen Beitritt zu einer Active Directory-Domain konfigurieren.

  2. Erstellen Sie einen gMSA-Zugriff auf die Sicherheitsgruppe, die vom Domain-Join-Dienst automatisch erstellt wird. Dieser Schritt muss auf einem Computer mit Administratorzugriff auf Ihre AD-Domain ausgeführt werden.

    $instanceGroupUri = gcloud container node-pools describe NODE_POOL_NAME --cluster CLUSTER_NAME --format="value(instanceGroupUrls)"
$securityGroupName = ([System.Uri]$instanceGroupUri).Segments[-1]
$securityGroup = dsquery group -name $securityGroupName
$gmsaName = GMSA_NAME
$dnsHostName = DNS_HOST_NAME

New-ADServiceAccount -Name $gmsaName -DNSHostName $dnsHostName -PrincipalsAllowedToRetrieveManagedPassword $securityGroup

Get-ADServiceAccount $gmsaName
Test-ADServiceAccount $gmsaName

    Dabei gilt:

    • NODE_POOL_NAME ist der Name des Windows Server-Knotenpools. Die automatisch erstellte Sicherheitsgruppe hat den gleichen Namen wie der Windows Server-Knotenpool.
    • CLUSTER_NAME: Der Name Ihres Clusters.
    • GMSA_NAME ist der Name, den Sie für den neuen gMSA auswählen.
    • DNS_HOST_NAME ist der vollständig qualifizierte Domainname (Fully Qualified Domain Name, FQDN) des von Ihnen erstellten Dienstkontos. Beispiel: Wenn GMSA_NAME webapp01 und die Domain example.com ist, dann ist DNS_HOST_NAME der Wert webapp01.example.com.

  3. Konfigurieren Sie Ihre gMSA, indem Sie den Anweisungen im Tutorial GMSA für Windows-Pods und -Container konfigurieren folgen.

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 NODE_POOL_NAME \
    --cluster=CLUSTER_NAME

Console

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

  1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

    Zur Seite "Google Kubernetes Engine"

  2. Klicken Sie neben dem Cluster, den Sie bearbeiten möchten, auf Aktionen  und dann auf Bearbeiten .

  3. Wählen Sie den Tab Knoten aus.

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

  5. 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.

Zusätzlich zu den nicht unterstützten Kubernetes-Features gibt es einige GKE-Features, die nicht unterstützt werden.

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

Eine Lokale Richtlinie für externen Traffic für den Windows-Knotenpool wird nur mit der GKE-Version 1.23.4-gke.400 oder höher unterstützt.

Andere Google Cloud-Produkte, die Sie mit GKE-Clustern verwenden möchten, unterstützen Windows Server-Knotenpools möglicherweise nicht. Informationen zu spezifischen Einschränkungen finden Sie in der Dokumentation des Produkts.

Fehlerbehebung

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

Probleme mit Containerd-Knoten

Informationen zu bekannten Problemen bei der Verwendung eines Containerd-Knoten-Images finden Sie unter Bekannte Probleme.

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.

Wenn das Pull-Image häufig auftritt, sollten Sie Knotenpools mit einer höheren CPU-Spezifikation verwenden. Die Containerextraktion wird parallel über Kerne ausgeführt, sodass Maschinentypen mit mehr Kernen die Gesamtabrufzeit verkürzen.

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 `
"(?s)${name}.*(C:.*kubelet\.exe.*)"
       
      PS C:\> $kubelet_cmd = $Matches[1] -replace `
"--image-pull-progress-deadline=.* ","" -replace "\r\n"," "

    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=40m "

    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

Image-Familie hat End of Life erreicht

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.

Wählen Sie zur Behebung dieses Fehlers 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 Befehl gcloud container get-server-config ermitteln, wie im Abschnitt GKE- und Windows-Versionen zuordnen erläutert.

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.

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.

Überprüfen Sie, ob sowohl die MTU der Netzwerkschnittstelle im Container als auch die Netzwerkschnittstellen des Windows Server-Knotens auf denselben Wert gesetzt sind (d. h. 1460 oder weniger). Informationen zum Festlegen der MTU finden Sie unter Bekannte Probleme bei Windows-Containern.

Probleme beim Starten von Knoten

Wenn Knoten im Cluster nicht starten oder dem Cluster nicht erfolgreich beitreten können, überprüfen Sie die Diagnoseinformationen, die in der Ausgabe des seriellen Ports des Knotens enthalten sind.

Führen Sie den folgenden Befehl aus, um die Ausgabe des seriellen Ports anzusehen:

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

Dabei gilt:

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

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

Wenn Sie Windows-Knoten in Kubernetes-Clustern mit einer großen Anzahl an Regeln für Host-Netzwerkdienst-Load-Balancer starten, kommt es zu einer Verzögerung bei der Verarbeitung der Regeln. Dienste sind während der Verzögerung von etwa 30 Sekunden pro Regel zeitweise nicht erreichbar. Die Gesamtverzögerung kann beträchtlich sein, wenn genügend Regeln vorhanden sind. Weitere Informationen finden Sie im ursprünglichen Problem in GitHub.

Für GKE-Cluster mit Version 1.24 oder früher sind bei allen Windows-Knoten, auf denen kube-proxy neu gestartet wurde (z. B. Knotenstart, Knotenupgrade, manueller Neustart), alle Dienste, die von einem auf diesem Konoten ausgeführten Pod erreicht werden, nicht erreichbar, bis alle Regeln von der Komponente synchronisiert wurden.

Für GKE-Cluster mit Version 1.25 oder höher wurde dieses Verhalten erheblich verbessert. Weitere Informationen zu dieser Verbesserung finden Sie in der Pull-Anfrage in GitHub. Wenn dieses Problem auftritt, empfehlen wir ein Upgrade der Steuerungsebene Ihres Clusters auf Version 1.25 oder höher.

Nächste Schritte