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. Windows Server-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 für zonale Cluster oder eine Region für regionale oder Autopilot-Cluster 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 Standardzone für Compute Engine fest:
    gcloud config set compute/zone COMPUTE_ZONE
  • Wenn Sie mit Autopilot oder regionalen Clustern arbeiten, legen Sie die Compute-Standardregion 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:

  • Der Zeitpunkt des Supports für ein Windows Server-Knoten-Image unterliegt der Supportzeit von Microsoft, wie unter Lebenszyklus der Betriebssysteme und Supportrichtlinie beschrieben. Wir empfehlen die Verwendung eines LTSC, da er einen längeren Lebenszyklus hat. Ziehen Sie ein SAC in Betracht, wenn Sie von Funktionen abhängen, die noch nicht im LTSC-Release verfügbar sind.

  • 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

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

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

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 für die Windows Server LTSC- als auch 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.

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 Versionszuordnung zwischen GKE-Versionen und Windows Server-Versionen können Sie mit dem gcloud-Befehlszeilentool oder in der Versionszuordnungstabelle in diesem Dokument einsehen.

Versionszuordnung mit dem gcloud-Tool, um abrufen

Führen Sie Folgendes aus, um die Versionszuordnung zwischen GKE-Versionen und Windows Server Core-Versionen für alle verfügbaren GKE-Versionen aufzurufen:

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 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 Ausgabe sieht etwa so aus:

    10.0.18363.1198
    

Tabelle zur Versionszuordnung

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

1.16

GKE-Version SAC-Version LTSC-Version
1.16.8-gke.8 – 1.16.13-gke.401 10.0.18363.720 (Windows Server Version 1909 Core) 10.0.17763.1098 (Windows Server 2019 Core)
1.16.13-gke.402 – 1.16.13-gke.404 10.0.18363.1082 (Windows Server Version 1909 Core) 10.0.17763.1457 (Windows Server 2019 Core)
1.16.15-gke.500 10.0.18363.720 (Windows Server Version 1909 Core) 10.0.17763.1098 (Windows Server 2019 Core)
1.16.15-gke.1600 – 1.16.15-gke.3500 10.0.18363.1082 (Windows Server Version 1909 Core) 10.0.17763.1457 (Windows Server 2019 Core)
1.16.15-gke.4300– 1.16.15-gke.7400 10.0.18363.1016 (Windows Server-Version 1909 Core) 10.0.17763.1397 (Windows Server 2019 Core)
1.16.15-gke.7800 – 1.16.15-gke.11800 (außer 1.16.15-gke.7801) 10.0.18363.1198 (Windows Server-Version 1909 Core) 10.0.17763.1577 (Windows Server 2019 Core)
1.16.15-gke.7801+ (außer 1.16.15-gke.10600 und 1.16.15-gke.11800) 10.0.18363.1379 (Windows Server-Version 1909 Core) 10.0.17763.1757 (Windows Server 2019 Core)

1.17

GKE-Version SAC-Version LTSC-Version
1.17.9-gke.1504 – 1.17.12-gke.500 10.0.18363.900 (Windows Server Version 1909 Core) 10.0.17763.1282 (Windows Server 2019 Core)
1.17.12-gke.1501 10.0.18363.1082 (Windows Server Version 1909 Core) 10.0.17763.1457 (Windows Server 2019 Core)
1.17.12-gke.1504 – 1.17.13-gke.600 10.0.18363.900 (Windows Server Version 1909 Core) 10.0.17763.1282 (Windows Server 2019 Core)
1.17.13-gke.1400 – 1.17.14-gke.1600 10.0.18363.1016 (Windows Server-Version 1909 Core) 10.0.17763.1397 (Windows Server 2019 Core)
1.17.15-gke.300 – 1.17.17-gke.1500 (außer 1.17.17-gke.1101) 10.0.18363.1198 (Windows Server-Version 1909 Core) 10.0.17763.1577 (Windows Server 2019 Core)
1.17.17-gke.1101+ (außer 1.17.17-gke.1500) 10.0.18363.1379 (Windows Server-Version 1909 Core) 10.0.17763.1757 (Windows Server 2019 Core)

1.18

GKE-Version SAC-Version LTSC-Version
1.18.6-gke.3503 – 1.18.9-gke.801 10.0.18363.900 (Windows Server Version 1909 Core) 10.0.17763.1282 (Windows Server 2019 Core)
1.18.9-gke.1501 10.0.18363.1082 (Windows Server Version 1909 Core) 10.0.17763.1457 (Windows Server 2019 Core)
1.18.9-gke.2501 – 1.18.10-gke.601 10.0.18363.900 (Windows Server Version 1909 Core) 10.0.17763.1282 (Windows Server 2019 Core)
1.18.10-gke.1500 – 1.18.12-gke.1700 (schließt 1.18.12-gke.1201 aus) 10.0.18363.1016 (Windows Server-Version 1909 Core) 10.0.17763.1397 (Windows Server 2019 Core)
1.18.12-gke.1201 10.0.18363.1198 (Windows Server-Version 1909 Core) 10.0.17763.1577 (Windows Server 2019 Core)
1.18.14-gke.1200 – 1.18.15-gke.1500 (außer 1.18.15-gke.1102) 10.0.18363.1198 (Windows Server-Version 1909 Core) 10.0.17763.1577 (Windows Server 2019 Core)
1.18.15-gke.1102+ (außer 1.18.15-gke.1500) 10.0.18363.1379 (Windows Server-Version 1909 Core) 10.0.17763.1757 (Windows Server 2019 Core)

1.19

GKE-Version SAC-Version LTSC-Version
1.19.6-gke.600 – 1.19.7-gke.1500 10.0.18363.658 (Windows Server Version 1909 Core) 10.0.17763.1577 (Windows Server 2019 Core)
1.19.8-gke.1600+ 10.0.19042.804 (Windows Server Version 20H2 Core) 10.0.17763.1757 (Windows Server 2019 Core)

1,20

GKE-Version SAC-Version LTSC-Version
1.20.2-gke.1500 10.0.18363.658 (Windows Server Version 1909 Core) 10.0.17763.1757 (Windows Server 2019 Core)
1.20.4-gke.500+ 10.0.19042.804 (Windows Server Version 20H2 Core) 10.0.17763.1757 (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 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. Sie können auch das Flag --release-channel verwenden, um einen Release-Kanal auszuwählen.
  • 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, wenn die folgenden Flags nicht angegeben sind: --cluster-version, --release-channel, --no-enable-autoupgrade und --no-enable-autorepair.

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

    • WINDOWS_LTSC_CONTAINERD: Windows Server LTSC mit containerd
    • WINDOWS_SAC_CONTAINERD: Windows Server SAC mit containerd
    • WINDOWS_LTSC: Windows Server LTSC mit Docker
    • WINDOWS_SAC: Windows Server SAC mit Docker

    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.

Console

  1. Rufen Sie in der 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:

    • WINDOWS_LTSC_CONTAINERD: Windows Server SAC mit containerd
    • WINDOWS_SAC_CONTAINERD: Windows Server LTSC mit containerd
    • WINDOWS_LTSC: Windows Server LTSC mit Docker
    • WINDOWS_SAC: Windows Server SAC mit Docker

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

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

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 AD-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 Cloud Console zu löschen:

  1. Rufen Sie in der 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:

Die folgenden Funktion werden für Windows Server-Knotenpools nicht unterstützt:

  • GPUs (--accelerator)

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
      

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.

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.

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.

Nächste Schritte