Aktualisieren der Betriebssystemversion (Os) für Ihre Azure Kubernetes Service (AKS)-Windows-Workloads

Wenn Sie die Betriebssystemversion einer ausgeführten Windows Workload auf Azure Kubernetes Service (AKS) aktualisieren, verwenden Sie eine der folgenden Migrationsmethoden:

• Direkte Migration: Aktualisieren Sie die Betriebssystem-SKU in einem vorhandenen Knotenpool, um von Windows Server 2022 zu Windows Server 2025 zu migrieren.
• Manuelle Migration: Erstellen Sie einen neuen Knotenpool mit der gewünschten Windows Server Betriebssystemversion, verschieben Sie Ihre Workloads in den neuen Knotenpool, und löschen Sie den alten Knotenpool.

Wenn eine neue Windows Server-Betriebssystemversion veröffentlicht wird, verpflichtet sich AKS, sie zu unterstützen. Es wird empfohlen, ein Upgrade auf die neueste Version durchzuführen, um die Korrekturen, Verbesserungen und neue Funktionen zu nutzen. AKS bietet ab Windows Server 2022 einen fünfjährigen Supportlebenszyklus für jede Windows Server-Version. In diesem Zeitraum veröffentlicht AKS eine neue Version, die eine neuere Version des Windows Server-Betriebssystems unterstützt, auf die Sie ein Upgrade durchführen können. Nach Ablauf des fünfjährigen Lebenszyklus müssen Sie Workloads zu neueren unterstützten Versionen migrieren, um Kompatibilität, Sicherheitsupdates und fortgesetzte Unterstützung von AKS sicherzustellen.

Die folgenden Einschränkungen gelten für Windows Server Betriebssystemversionsmigration:

• Das Knotenpoolupdate zum Migrieren von einer Windows Server Version zu einer anderen wird nur für Windows Server 2022-zu-Windows Server 2025-Migration mithilfe der aks-preview Azure CLI Erweiterung Version 22.0.0b6 oder höher unterstützt. Erstellen Sie für alle anderen Windows Server Betriebssystemversionsmigrationen einen neuen Knotenpool.
• Unterschiedliche Windows Server-Versionen können nicht im gleichen Knotenpool auf AKS vorhanden sein. Wenn Sie einen neuen Knotenpool erstellen, um die neue Betriebssystemversion zu hosten, stellen Sie sicher, dass Sie den Berechtigungen und dem Zugriff des vorherigen Knotenpools auf den neuen knotenpool entsprechen.
• Windows Server 2025 wird ab Kubernetes Version 1.32.0 unterstützt.

Prerequisites

• Aktualisieren Sie die FROM-Anweisung in Ihrem Dockerfile auf die neue Betriebssystemversion.
• Überprüfen Sie für Ihre Anwendung, ob die Container-App unter der neuen Betriebssystemversion funktioniert.
• Stellen Sie die überprüfte Container-App in AKS in einer Entwicklungs- oder Testumgebung bereit.
• Notieren Sie sich den neuen Imagenamen oder das Tag für die Verwendung in diesem Artikel.
• Installieren oder aktualisieren Sie für die direkte Migration von Windows Server 2022 zu Windows Server 2025 die aks-preview Azure CLI Erweiterung auf Version 22.0.0b6 oder höher.

Installieren Sie die aks-preview Azure CLI-Erweiterung

• Führen Sie den folgenden Befehl aus, um die Erweiterung „aks-preview“ zu installieren:

Direkte Migration von Windows Server 2022 zu Windows Server 2025

Sie können einen vorhandenen Windows Server 2022 Knotenpool zu Windows Server 2025 migrieren, indem Sie die Betriebssystem-SKU im vorhandenen Knotenpool mit dem az aks nodepool update Befehl aktualisieren. Dieser Migrationspfad verwendet die aks-preview Azure CLI Erweiterung Version 22.0.0b6 oder höher. Der Cluster muss Kubernetes, Version 1.32, bis 1.36 ausführen, wobei beide Betriebssystemversionen unterstützt werden.

Aspekte der In-Place-Migration

Beachten Sie die folgenden Details, bevor Sie einen Windows Server 2022 Knotenpool zu Windows Server 2025 migrieren:

• Windows Server 2025 verwendet standardmäßig FIPS-fähige Bilder. Wenn Ihr Windows Server 2022-Knotenpool noch kein FIPS-fähiges Image verwendet, geben Sie beim Ausführen des Aktualisierungsbefehls --enable-fips-image an.
• Der Updatebefehl löst eine automatische Neuimage des vorhandenen Knotenpools aus.
• Windows Server 2025 verwendet standardmäßig VMs der Generation 2. Sie benötigen keinen vorhandenen Knotenpool der Generation 2 mit Windows Server 2022, um eine direkte Migration durchzuführen. Standardmäßige Windows Server 2022 containerd Knotenpools werden unterstützt.
• Wenn die vorhandene VM-Größe die Generation 2 unterstützt, kann AKS während der Migration ein Windows Server 2025 Generation 2-Image auswählen. Diese Standardbildauswahl wirkt sich möglicherweise auf die Bildkompatibilität für einige Konfigurationen aus.

In der folgenden Tabelle wird beschrieben, welche Quellkonfigurationen die direkte Migration mit dem Updatebefehl unterstützen. Verwenden Sie für nicht unterstützte Konfigurationen stattdessen die manuelle Migration .

Aktualisieren des vorhandenen Windows Server 2022 Knotenpools auf Windows Server 2025

1. Aktualisieren Sie die Betriebssystem-SKU des Knotenpools mithilfe des Befehls az aks nodepool update auf Windows2025.

   az aks nodepool update \
       --resource-group <resource-group-name> \
       --cluster-name <cluster-name> \
       --name <node-pool-name> \
       --os-sku Windows2025 \
       --enable-fips-image
   

2. Stellen Sie sicher, dass ein Knoten im aktualisierten Knotenpool die Windows2025 Betriebssystem-SKU und ein Windows Server 2025-Image mithilfe des kubectl describe node Befehls verwendet.

   kubectl describe node <node-name>
   

   Die folgende komprimierte Beispielausgabe zeigt die Windows2025 Betriebssystem-SKU-Bezeichnung und Windows Server 2025-Betriebssystemimage:

   Labels:
     kubernetes.azure.com/os-sku=Windows2025
     kubernetes.io/os=windows
   ...
   System Info:
     OS Image:                   Windows Server 2025 Datacenter
     Container Runtime Version:  containerd://2.0.4+azure
   

Manuelle Migration zu einem neuen Knotenpool

Bei der manuellen Migration wird ein neuer Knotenpool verwendet, anstatt den vorhandenen Knotenpool zu aktualisieren. Verwenden Sie die manuelle Migration für Windows Server Betriebssystemversionsmigrationen, die keine direkte Migration unterstützen oder wenn Ihre Quellkonfiguration für die direkte Migration nicht unterstützt wird. Um manuell zu migrieren, erstellen Sie einen neuen Knotenpool mit der gewünschten Windows Server Betriebssystemversion, und verschieben Sie Ihre Workloads in den neuen Knotenpool.

Hinzufügen eines neuen Knotenpools zu einem vorhandenen Cluster

Fügen Sie ihrem vorhandenen Cluster einen Knotenpool mit der gewünschten Betriebssystemversion hinzu:

• Verwenden Sie CLI, um einem vorhandenen Cluster einen Windows-Knotenpool hinzuzufügen .
• Verwenden Sie Portal, um einem vorhandenen Cluster einen Windows-Knotenpool hinzuzufügen .
• Verwenden Sie PowerShell, um einem vorhandenen Cluster einen Windows-Knotenpool hinzuzufügen .
• Verwenden Sie Terraform, um einem vorhandenen Cluster einen Windows-Knotenpool hinzuzufügen .

Windows Server 2025-Knotenpools benötigen ein FIPS-fähiges Image. Wenn Sie einen Windows Server 2025-Knotenpool hinzufügen, schließen Sie --enable-fips-image (Azure CLI) oder -EnableFIPS (Azure PowerShell) ein.

Aktualisieren der YAML-Datei

Die Knotenauswahl ist die am häufigsten verwendete und empfohlene Option für die Platzierung von Windows-Pods auf Windows-Knoten.

1. Fügen Sie Ihrer YAML-Datei den Knotenselektor hinzu, indem Sie die folgende Anmerkung hinzufügen:

         nodeSelector:
           "kubernetes.io/os": windows
   

   Die Anmerkung findet alle verfügbaren Windows-Knoten und platziert den Pod auf diesem Knoten (gemäß allen anderen Planungsregeln). Beim Upgrade Ihrer Betriebssystemversion müssen Sie die Platzierung auf einem Windows-Knoten und einem Knoten mit der neuesten Betriebssystemversion erzwingen. Um dies zu erreichen, besteht eine Option darin, eine andere Anmerkung zu verwenden. Aktualisieren Sie <OSSKU>, um die ossku Ihrer gewünschten Windows-Betriebssystemversion zuzuordnen, z. B. Windows2025.

         nodeSelector:
           "kubernetes.azure.com/os-sku": <OSSKU>
   

2. Nachdem Sie den nodeSelector in der YAML-Datei aktualisiert haben, müssen Sie auch das zu verwendende Containerimage aktualisieren. Sie können diese Informationen aus dem vorherigen Schritt abrufen, in dem Sie eine neue Version der containerisierten Anwendung erstellt haben. Ändern Sie dazu die FROM-Anweisung in Ihrer Dockerfile-Datei.

   Hinweis

   Sie sollten dieselbe YAML-Datei verwenden, die Sie für die anfängliche Bereitstellung der Anwendung verwendet haben. Dadurch wird sichergestellt, dass sich außer dem Containerimage und nodeSelector keine weiteren Konfigurationsänderungen ändern.

Anwenden der aktualisierten YAML-Datei auf die vorhandene Workload

1. Zeigen Sie die Knoten in Ihrem Cluster mit dem Befehl kubectl get nodes an.

   kubectl get nodes -o wide
   

   Die folgende Beispielausgabe zeigt alle Knoten im Cluster, einschließlich des neuen Knotenpools, den Sie erstellt haben, und den vorhandenen Knotenpools:

   NAME                                STATUS   ROLES   AGE     VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE                         KERNEL-VERSION     CONTAINER-RUNTIME
   aks-agentpool-18877473-vmss000000   Ready    agent   5h40m   v1.33.12   10.240.0.4     <none>        Ubuntu 22.04.5 LTS               5.15.0-1116-azure  containerd://1.7.33-1
   akspoolws000000                     Ready    agent   3h15m   v1.33.12   10.240.0.208   <none>        Windows Server 2022 Datacenter   10.0.20348.825     containerd://1.6.6+azure
   akspoolws000001                     Ready    agent   3h17m   v1.33.12   10.240.0.239   <none>        Windows Server 2022 Datacenter   10.0.20348.825     containerd://1.6.6+azure
   akspoolws000002                     Ready    agent   3h17m   v1.33.12   10.240.1.14    <none>        Windows Server 2022 Datacenter   10.0.20348.825     containerd://1.6.6+azure
   akswspool000000                     Ready    agent   5h37m   v1.33.12   10.240.0.115   <none>        Windows Server 2025 Datacenter   10.0.26100.32995    containerd://2.0.4+azure
   akswspool000001                     Ready    agent   5h37m   v1.33.12   10.240.0.146   <none>        Windows Server 2025 Datacenter   10.0.26100.32995    containerd://2.0.4+azure
   akswspool000002                     Ready    agent   5h37m   v1.33.12   10.240.0.177   <none>        Windows Server 2025 Datacenter   10.0.26100.32995    containerd://2.0.4+azure
   

2. Wenden Sie die aktualisierte YAML-Datei mithilfe des Befehls kubectl apply auf die vorhandene Workload an, und geben Sie den Namen der YAML-Datei an.

   kubectl apply -f <filename>
   

   Die folgende Beispielausgabe zeigt einen konfigurierten Status für die Bereitstellung:

   deployment.apps/sample configured
   service/sample unchanged
   

   An diesem Punkt startet AKS den Prozess der Terminierung vorhandener Pods und der Bereitstellung neuer Pods auf den Knoten mit der Anmerkung nodeSelector.

3. Überprüfen Sie mit dem Befehl kubectl get pods den Status der Bereitstellung.

   kubectl get pods -o wide
   

   Die folgende Beispielausgabe zeigt die Pods im default-Namespace:

   NAME                      READY   STATUS    RESTARTS   AGE     IP             NODE              NOMINATED NODE   READINESS GATES
   sample-7794bfcc4c-k62cq   1/1     Running   0          2m49s   10.240.0.238   akspoolws000000   <none>           <none>
   sample-7794bfcc4c-rswq9   1/1     Running   0          2m49s   10.240.1.10    akspoolws000001   <none>           <none>
   sample-7794bfcc4c-sh78c   1/1     Running   0          2m49s   10.240.0.228   akspoolws000000   <none>           <none>
   

Aktualisieren der Sicherheits- und Authentifizierungskonfiguration

Wenn Sie gruppenverwaltete Dienstkonten (gMSAs, Group Managed Service Accounts) nutzen, müssen Sie die Konfiguration für verwaltete Identitäten für den neuen Knotenpool aktualisieren. gMSA verwendet ein Geheimnis (Benutzerkonto und Kennwort), damit der Knoten, auf dem der Windows-Pod ausgeführt wird, den Container für Microsoft Entra ID authentifizieren kann. Um auf dieses Geheimnis in Azure Key Vault zuzugreifen, verwendet der Knoten eine verwaltete Identität, mit der der Knoten auf die Ressource zugreifen kann. Da verwaltete Identitäten pro Knotenpool konfiguriert werden und sich der Pod jetzt in einem neuen Knotenpool befindet, müssen Sie diese Konfiguration aktualisieren. Weitere Informationen finden Sie unter Aktivieren von gruppenverwalteten Dienstkonten (Group Managed Service Account, GMSA) für Ihre Windows Server-Knoten auf Ihrem Azure Kubernetes Service (AKS)-Cluster.

Dasselbe Prinzip gilt für verwaltete Identitäten, die für einen anderen Pod oder Knotenpool beim Zugriff auf andere Azure-Ressourcen verwendet werden. Sie müssen alle Zugriffsrechte, die verwaltete Identität Identity bereitstellt, aktualisieren, um den neuen Knotenpool zu berücksichtigen. Informationen zum Anzeigen von Update- und Anmeldeaktivitäten finden Sie unter Anzeigen von Update- und Anmeldeaktivitäten für verwaltete Identitäten.

Nächste Schritte

In diesem Artikel haben Sie erfahren, wie die Betriebssystemversion für Windows-Workloads auf AKS aktualisiert wird. Weitere Informationen zu Windows-Workloads in AKS finden Sie unter Bereitstellen einer Windows-Containeranwendung auf Azure Kubernetes Service (AKS).