Einstellung der Wartungsarbeiten für Windows Server Semi-Annual Channel

Standard

Auf dieser Seite finden Sie Informationen über das Ende der Serviceleistungen für Windows Server Semi-Annual Channel (SAC) Knoten-Image-Typen in Standardclustern von Google Kubernetes Engine (GKE). Eine Anleitung zum Migrieren zu unterstützten Knoten-Images finden Sie unter Zu unterstützten Windows-Images migrieren.

Windows Server SAC entfernen

Microsoft entfernt den Semi-Annual Channel für Windows Server am 9. August 2022. Dies entspricht dem Ende der Wartung von Windows Server Version 20H2. Windows Server verwendet den Long-Term Servicing Channel (LTSC) als primären Releasekanal. Durch diese Änderung wird Microsoft keine kritischen Updates mehr veröffentlichen, einschließlich Sicherheitsupdates für Windows Server SAC-Images. Aus diesem Grund kann GKE für diese Images keinen Support mehr bieten.

Mit GKE Standard können Sie keine neuen Knotenpools mehr erstellen, die Windows Server SAC-Image-Typen verwenden. Wenn Sie in Ihren vorhandenen Knotenpools einen der folgenden Image-Typen verwenden, müssen Sie zu einem unterstützten Image-Typ migrieren, wenn Sie Ihre GKE-Version aktualisieren möchten.

windows_sac: Windows Server SAC mit Docker
windows_sac_containerd: Windows Server SAC mit containerd

Ihre vorhandenen Windows Server-SAC-Knotenpools funktionieren nach dem 9. August 2022 weiterhin wie erwartet. Sie riskieren jedoch, dass diese Knoten Sicherheitslücken aufweisen und die Plattform instabil wird, weil es keine zukünftigen Updates für SAC gibt.

Zeitachse und Meilensteine

Nach dem 9. August 2022 ist Folgendes nicht mehr möglich:

Neue Cluster erstellen, die Windows Server SAC-Knoten-Images verwenden.
Neue Knotenpools erstellen, die Windows Server SAC-Knoten-Images verwenden.
Automatische Knotenbereitstellung aktivieren, wobei das Flag --autoprovisioning-image-type auf windows_sac oder windows_sac_containerd gesetzt ist.
Upgrade der GKE-Version vorhandener Windows Server-SAC-Knoten durchführen.

Was sollten Sie tun?

Wir empfehlen, Ihre Windows Server-SAC-Knotenpools zum Knoten-Image-Typ windows_ltsc_containerd zu migrieren. In GKE-Version 1.23 und höher ist dies der einzige unterstützte Windows Server-Image-Typ für neue Cluster und Knotenpools.

Der Image-Typ windows_ltsc, der Docker als Containerlaufzeit verwendet, wird in GKE-Version 1.23 und höher aufgrund der Einstellung der Docker-Knoten-Images nicht unterstützt.

Führen Sie je nach aktueller GKE-Version folgende Schritte aus:

GKE-Version 1.20 und früher: Migrieren Sie Ihre Knotenpools zum Image windows_ltsc.
GKE-Version 1.21 und höher: Migrieren Sie Ihre Knotenpools zum Image windows_ltsc_containerd.

Auswirkungen der Migration

Wenn Sie derzeit das windows_sac-Image verwenden, das Docker als Containerlaufzeit hat, kann sich die Migration zum Image-Typ windows_ltsc_containerd auf alle vorhandenen Tools auswirken, die von Docker-Befehlen abhängen. Informationen zu den möglichen Auswirkungen der Migration zu einem Image-Typ, der containerd verwendet, finden Sie in der Liste der Situationen unter Einstellung des Docker-Knoten-Images.

Zu Windows Server LTSC migrieren

Der Migrationsprozess besteht aus den folgenden Schritten:

Container-Images für Architekturaktualisierungen identifizieren
Windows-Container-Images für mehrere Architekturen erstellen
Vorhandene Knotenpools auf Windows Server LTSC aktualisieren

Container-Images für Architekturaktualisierungen identifizieren

Container-Images mit einer Architektur, die auf Windows Server SAC ausgeführt werden, sind nicht mit Windows Server LTSC-Images kompatibel. Sie müssen inkompatible Container-Images ermitteln und die Aktualisierung ihrer Architektur vorbereiten. Wenn Sie über Images mit mehreren Architekturen verfügen, sollten Sie diese daraufhin überprüfen, ob die Images die Windows Server 2019 LTSC-Variante unterstützen, die die Versionsnummer 10.0.17763.X trägt.

Images für eine Architektur

Führen Sie den folgenden Befehl in einem Windows Server-SAC-Knoten aus, auf dem der Pod ausgeführt wird, um die unterstützte Windows-Version zu prüfen:

docker image inspect IMAGE_NAME

Ersetzen Sie IMAGE_NAME durch den Namen des Container-Image.

Wenn das Image die Windows Server-SAC-Variante unterstützt, sieht die Ausgabe in etwa so aus:

[
  {
    ...
    "Architecture": "amd64",
    "Os": "windows",
    "OsVersion": "10.0.19042.1645" // 1645 can be any build number
  }
]

Wenn das Image die Windows Server LTSC-Variante unterstützt, sieht die Ausgabe in etwa so aus:

[
  {
    ...
    "Architecture": "amd64",
    "Os": "windows",
    "OsVersion": "10.0.17763.2686" // 2686 can be any build number
  }
]

Images für mehrere Architekturen

Wenn Sie bereits Windows-Container-Images für mehrere Architekturen verwenden, prüfen Sie die Images, ob sie die Variante „Windows Server 2019 LTSC“ mit der Versionsnummer 10.0.17763.X unterstützen.

docker manifest inspect MANIFEST_NAME

Ersetzen Sie MANIFEST_NAME durch den Namen Ihres Docker-Manifests, z. B. eu.gcr.io/gke-release-staging/internet-explorer:v2.

Die Ausgabe sieht etwa so aus:

{
  {
    "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
    "size": 1575,
    "digest": "...",
    "platform": {
        "architecture": "amd64",
        "os": "windows",
        "os.version": "10.0.17763.1935"

  }
}

Windows-Container-Images für mehrere Architekturen erstellen

Nachdem Sie alle Images ermittelt haben, die Aktualisierungen zur Unterstützung der Variante „Windows Server 2019 LTSC“ benötigen, empfehlen wir, die Windows Server-Images für mehrere Architekturen zu erstellen.

Die Erstellung von Images mit mehreren Architekturen gewährleistet, dass Ihre Container auf jeder von GKE angebotenen Windows-Version laufen. Images mit mehreren Architekturen erleichtern Ihnen die Migration, denn containerd erkennt die Windows Server LTSC-Version auf Ihren migrierten Knotenpools und wählt das entsprechende Image aus Ihrem Manifest aus.

Sie können diese Images manuell oder mit dem Cloud Build-gke-windows-builder erstellen. Wir empfehlen den Cloud Build-Builder, der regelmäßig aktualisiert wird, um neue Windows Server LTSC-Images zu unterstützen, sobald sie verfügbar sind. Informationen zu manuellen Images und Cloud Build-Images für mehrere Architekturen finden Sie unter Windows Server-Images für mehrere Architekturen erstellen.

Upgrade von Knoten auf Windows Server LTSC durchführen

Nachdem Sie Ihre Container-Images aktualisiert haben, um die Windows Server LTSC-Variante zu unterstützen, migrieren Sie Ihre Knotenpools zum Windows Server LTSC-Knoten-Image. Wir empfehlen dringend, die Migration in einem Staging- oder Testcluster zu testen, um sicherzustellen, dass Ihre Bereitstellungen vor dem Upgrade Ihrer Produktionsumgebung wie vorgesehen funktionieren. Führen Sie einen der folgenden Schritte aus, um Ihr Image zu aktualisieren:

Neue Knotenpools erstellen und Arbeitslasten zu den neuen Knoten migrieren
Image-Typ auf vorhandenen Knotenpools aktualisieren

Neue Knotenpools erstellen

Neuen Knotenpool erstellen:
```
gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --image-type=WINDOWS_LTSC_IMAGE
```
Dabei gilt:
- NODE_POOL_NAME ist der Name des neuen Knotenpools.
- CLUSTER_NAME: Name Ihres GKE-Clusters.
- WINDOWS_LTSC_IMAGE: Das zu verwendende Windows Server LTSC-Image, entweder windows_ltsc_containerd oder windows_ltsc.
Fügen Sie den Arbeitslastmanifesten den folgenden nodeSelector hinzu:
```
spec:
  ...
  nodeSelector:
    kubernetes.io/os: windows
    cloud.google.com/gke-os-distribution: windows_ltsc
```
Sie können diesen nodeSelector auch mit windows_sac als Labelwert verwenden, um GKE anzuweisen, bestimmte Pods auf den neuen Knoten nicht zu planen.
Stellen Sie Ihre aktualisierten Manifeste bereit:
```
kubectl apply -f MANIFEST_NAME
```
Skalieren Sie Ihren alten Knotenpool auf null:
```
gcloud container node-pools update OLD_POOL \
    --cluster=CLUSTER_NAME \
    --min-nodes=0 \
    --max-nodes=NODE_COUNT
```
Dabei gilt:
- OLD_POOL: Der Name Ihres vorhandenen Windows Server SAC-Knotenpools.
- NODE_COUNT: Die maximale Anzahl von Knoten im Knotenpool. Skalieren Sie diese Zahl schrittweise auf 0, indem Sie diesen Befehl wiederholen. Wenn Probleme auftreten, skalieren Sie diesen Wert wieder hoch.

Löschen Sie nach der Migration den alten Knotenpool:

gcloud container node-pools delete OLD_POOL \
    --cluster=CLUSTER_NAME

Vorhandene Knotenpools aktualisieren

Ändern Sie den Knoten-Image-Typ in Ihren vorhandenen Windows Server-SAC-Knotenpools:
```
gcloud container clusters upgrade CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --node-pool=NODE_POOL \
    --image-type=WINDOWS_LTSC_IMAGE
```
Dabei gilt:
- CLUSTER_NAME: Name Ihres GKE-Clusters.
- COMPUTE_REGION ist die Compute Engine-Region des Clusters. Verwenden Sie für zonale Cluster --zone=COMPUTE_ZONE.
- NODE_POOL: Der Name des Windows Server-SAC-Knotenpools.
- WINDOWS_LTSC_IMAGE: Das zu verwendende Windows Server LTSC-Image, entweder windows_ltsc_containerd oder windows_ltsc.