Mettre à niveau la version du système d’exploitation pour vos charges de travail Windows Azure Kubernetes Service (AKS)

Lorsque vous mettez à niveau la version du système d’exploitation d’une charge de travail Windows en cours d’exécution sur Azure Kubernetes Service (AKS), utilisez l’une des méthodes de migration suivantes :

  • Migration sur place : mettez à jour la référence SKU du système d’exploitation sur un pool de nœuds existant pour migrer de Windows Server 2022 vers Windows Server 2025.
  • Migration manuelle : créez un pool de nœuds avec votre version de système d’exploitation souhaitée Windows Server, déplacez vos charges de travail vers le nouveau pool de nœuds et supprimez l’ancien pool de nœuds.

Lorsqu’une nouvelle version du système d’exploitation Windows Server est publiée, AKS s’engage à le prendre en charge. Nous vous recommandons de mettre à niveau vers la dernière version pour tirer parti des correctifs, améliorations et nouvelles fonctionnalités. AKS offre un cycle de vie de support de cinq ans pour chaque version de Windows Server, à compter de Windows Server 2022. Pendant cette période, AKS publie une nouvelle version qui prend en charge une version plus récente du système d’exploitation Windows Server vers laquelle effectuer la mise à niveau. Une fois le cycle de vie de cinq ans terminé, vous devez migrer des charges de travail vers des versions plus récentes prises en charge pour garantir la compatibilité, les mises à jour de sécurité et la prise en charge continue d’AKS.

Important

À compter du 30 juin 2028, Azure Kubernetes Service (AKS) ne prend plus en charge les pools de nœuds Windows Server 2022. Windows Server 2022 n'est pas pris en charge dans Kubernetes version 1.37 et ultérieure. À compter du 30 juin 2029, AKS supprime toutes les images de nœud existantes pour Windows Server 2022, ce qui signifie que les opérations de mise à l’échelle échouent. Pour obtenir davantage de détails sur cette mise à service, consultez le problème GitHub Retirement ainsi que l’annonce correspondante dans Azure Updates. Pour rester informé des annonces et des mises à jour, suivez les notes de publication AKS.

Les limitations suivantes s’appliquent à la migration de version du système d’exploitation pour Windows Server :

  • La mise à jour du pool de nœuds pour migrer d’une version de Windows Server vers une autre n’est prise en charge que pour la migration de Windows Server 2022 vers Windows Server 2025 à l’aide de la version 22.0.0b6 ou ultérieure de l’extension Azure CLI aks-preview. Pour toutes les autres migrations de versions de système d’exploitation Windows Server, créez un pool de nœuds.
  • Différentes versions de Windows Server ne peuvent pas coexister sur le même pool de nœuds sur AKS. Si vous créez un pool de nœuds pour héberger la nouvelle version du système d’exploitation, veillez à mettre en correspondance les autorisations et l’accès du pool de nœuds précédent à celui-ci.
  • Windows Server 2025 est pris en charge à partir de Kubernetes version 1.32.0.

Prerequisites

  • Mettez à jour l’instruction FROM dans votre Dockerfile vers la nouvelle version de système d’exploitation.
  • Passez en revue votre application et vérifiez que l’application conteneur fonctionne sur la nouvelle version de système d’exploitation.
  • Déployez l’application conteneur vérifiée sur AKS dans un environnement de développement ou de test.
  • Notez le nouveau nom d’image ou la nouvelle étiquette utilisés dans cet article.
  • Pour la migration sur place de Windows Server 2022 vers Windows Server 2025, installez ou mettez à jour l’extension aks-preview Azure CLI vers la version 22.0.0b6 ou ultérieure.

Remarque

Pour savoir comment générer un Dockerfile pour les charges de travail Windows, consultez Dockerfile sur Windows et Optimiser les fichiers Dockerfile Windows.

Important

Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les versions préliminaires sont fournies « en l’état » et « selon leur disponibilité » et ne sont pas couvertes par les accords de niveau de service ni par la garantie limitée. Les versions préliminaires d’AKS sont partiellement couvertes par le support client, dans la limite du raisonnable. Par conséquent, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

Installer l’extension aks-preview Azure CLI

  • Exécutez la commande suivante pour installer l’extension aks-preview :

Migration sur place de Windows Server 2022 vers Windows Server 2025

Vous pouvez migrer un pool de nœuds Windows Server 2022 existant vers Windows Server 2025 en place en mettant à jour la référence SKU du système d’exploitation sur le pool de nœuds existant avec la az aks nodepool update commande. Ce chemin de migration utilise l’extension aks-preview Azure CLI version 22.0.0b6 ou ultérieure. Le cluster doit exécuter Kubernetes version 1.32 à 1.36 où les deux versions du système d’exploitation sont prises en charge.

Considérations relatives à la migration sur place

Tenez compte des détails suivants avant de migrer un pool de nœuds Windows Server 2022 vers Windows Server 2025 :

  • Windows Server 2025 utilise des images compatibles FIPS par défaut. Si votre pool de nœuds Windows Server 2022 n'utilise pas encore d'image compatible FIPS, incluez --enable-fips-image quand vous exécutez la commande de mise à jour.
  • La commande de mise à jour déclenche une réimage automatique du pool de nœuds existant.
  • Windows Server 2025 utilise des machines virtuelles de génération 2 par défaut. Vous n’avez pas besoin de disposer d’un pool de nœuds Windows Server 2022 de 2e génération existant pour effectuer une migration sur place. Les pools de nœuds standard Windows Server 2022 containerd sont pris en charge.
  • Si la taille de machine virtuelle existante prend en charge la génération 2, AKS peut sélectionner une image Windows Server 2025 Génération 2 pendant la migration. Cette sélection d’image par défaut peut affecter la compatibilité des images pour certaines configurations.

Le tableau suivant décrit les configurations sources qui prennent en charge la migration sur place avec la commande de mise à jour. Pour les configurations non prises en charge, utilisez plutôt la migration manuelle .

Configuration existante Support Result
Image standard Windows Server 2022 containerd génération 1 avec une taille de machine virtuelle de génération 1 uniquement Oui Migre vers Windows Server 2025 Génération 1.
Image standard Windows Server 2022 containerd génération 1 avec une taille de machine virtuelle compatible génération 2 Oui Migre vers Windows Server 2025 Génération 2.
Image standard Windows Server 2022 containerd génération 2 avec une taille de machine virtuelle compatible génération 2 Oui Migre vers Windows Server 2025 Génération 2.

Mettre à jour le pool de nœuds Windows Server 2022 existant vers Windows Server 2025

  1. Mettez à jour le SKU du système d’exploitation du pool de nœuds vers Windows2025 à l’aide de la commande az aks nodepool update.

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

  2. Vérifiez qu’un nœud dans le pool de nœuds mis à jour utilise la Windows2025 référence SKU du système d’exploitation et une image Windows Server 2025 à l’aide de la kubectl describe node commande.

    kubectl describe node <node-name>

    L’exemple de sortie condensée suivant montre l’étiquette SKU du Windows2025 système d’exploitation et l’image du système d’exploitation Windows Server 2025 :

    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

Migration manuelle vers un nouveau pool de nœuds

La migration manuelle utilise un nouveau pool de nœuds au lieu de mettre à jour le pool de nœuds existant. Utilisez la migration manuelle pour les migrations de version du système d’exploitation Windows Server qui ne prennent pas en charge la mise à niveau sur place, ou lorsque votre configuration source n’est pas compatible avec une mise à niveau sur place. Pour migrer manuellement, créez un pool de nœuds avec votre version de système d’exploitation souhaitée Windows Server et déplacez vos charges de travail vers le nouveau pool de nœuds.

Ajouter un nouveau pool de nœuds à un cluster existant

Ajoutez un pool de nœuds avec votre version de système d’exploitation souhaitée à votre cluster existant :

Les pools de nœuds Windows Server 2025 nécessitent une image avec FIPS activé. Lorsque vous ajoutez un pool de nœuds Windows Server 2025, incluez --enable-fips-image (Azure CLI) ou -EnableFIPS (Azure PowerShell).

Mettre à jour le fichier YAML

Le sélecteur de nœuds est l’option recommandée et la plus courante pour le placement des pods Windows sur les nœuds Windows.

  1. Ajoutez le sélecteur de nœud à votre fichier YAML en ajoutant l’annotation suivante :

          nodeSelector:
        "kubernetes.io/os": windows

    L’annotation recherche un nœud Windows disponible et place le pod sur ce nœud (en suivant toutes les autres règles de planification). Lors de la mise à niveau de la version de votre système d’exploitation, vous devez imposer le placement sur un nœud Windows et un nœud utilisant la dernière version du système d’exploitation. Pour ce faire, une option consiste à utiliser une autre annotation. Mettez à jour <OSSKU> pour correspondre à l'ossku de la version de Windows que vous souhaitez, par exemple Windows2025.

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

  2. Une fois que vous avez mis à jour nodeSelector dans le fichier YAML, vous devez également mettre à jour l’image conteneur à utiliser. Vous pouvez obtenir ces informations à l’étape précédente où vous avez créé une version de l’application conteneurisée en changeant l’instruction FROM dans votre Dockerfile.

    Remarque

    Vous devez utiliser le même fichier YAML que celui que vous avez utilisé pour déployer initialement l’application. Cela garantit qu’aucune autre configuration ne change en dehors de nodeSelector et de l’image conteneur.

Appliquer le fichier YAML mis à jour à la charge de travail existante

  1. Affichez les nœuds de votre cluster en utilisant la commande kubectl get nodes.

    kubectl get nodes -o wide

    L’exemple de sortie suivant montre tous les nœuds du cluster, y compris le nouveau pool de nœuds que vous avez créé et les pools de nœuds existants :

    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. Appliquez le fichier YAML mis à jour à la charge de travail existante en utilisant la commande kubectl apply et spécifiez le nom du fichier YAML.

    kubectl apply -f <filename>

    L’exemple de sortie suivant montre un état configuré pour le déploiement :

    deployment.apps/sample configured
service/sample unchanged

    À ce stade, AKS démarre le processus de fin des pods existants et de déploiement de nouveaux pods sur les nœuds avec l’annotation nodeSelector .

  3. Vérifiez l’état du déploiement avec la commande kubectl get pods.

    kubectl get pods -o wide

    L’exemple de sortie suivant montre les pods dans l’espace de noms default :

    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>

Mettre à jour la configuration de la sécurité et de l’authentification

Si vous utilisez des comptes de service administrés de groupe (gMSA), vous devez mettre à jour la configuration de l’identité managée du nouveau pool de nœuds. gMSA utilise un secret (compte d’utilisateur et mot de passe) pour que le nœud qui exécute le pod Windows puisse authentifier le conteneur sur Microsoft Entra ID. Pour accéder à ce secret sur Azure Key Vault, le nœud utilise une identité managée qui permet au nœud d’accéder à la ressource. Étant donné que les identités managées sont configurées par pool de nœuds et que le pod réside désormais sur un nouveau pool de nœuds, vous devez mettre à jour cette configuration. Pour plus d’informations, consultez Activer les comptes de service administrés de groupe (gMSA) pour vos nœuds Windows Server sur votre cluster Azure Kubernetes Service (AKS).

Le même principe s’applique aux identités managées utilisées pour tout autre pod ou pool de nœuds en cas d’accès à d’autres ressources Azure. Vous devez mettre à jour tout accès fourni par l’identité managée pour refléter le nouveau pool de nœuds. Pour afficher les activités de mise à jour et de connexion, consultez Comment afficher l’activité de l’identité managée.

Étapes suivantes

Dans cet article, vous avez appris à mettre à niveau la version de système d’exploitation des charges de travail Windows sur AKS. Pour en savoir plus sur les charges de travail Windows sur AKS, consultez Déployer une application conteneur Windows sur Azure Kubernetes Service (AKS).

  • Dernière mise à jour :