Créer un conteneur Windows Server sur un cluster Azure Kubernetes Service (AKS) à l’aide d’Azure CLI

Article
03/09/2023
15 minutes de lecture

AKS (Azure Kubernetes Service) est un service Kubernetes managé qui vous permet de déployer et de gérer rapidement des clusters. Dans cet article, vous déployez un cluster AKS qui exécute des conteneurs Widnows Server 2019 à l’aide d’Azure CLI. Vous déployez également un exemple d’application ASP.NET dans un conteneur Windows Server vers le cluster.

Capture d’écran de la navigation vers l’exemple d’application ASP.NET.

Cet article suppose une compréhension élémentaire des concepts liés à Kubernetes. Pour plus d’informations, consultez Concepts de base de Kubernetes pour AKS (Azure Kubernetes Service).

Si vous n’avez pas d’abonnement Azure, créez un compte gratuit Azure avant de commencer.

Prérequis

Utilisez l’environnement Bash dans Azure Cloud Shell. Pour plus d’informations, consultez Démarrage rapide pour Bash dans Azure Cloud Shell.
Si vous préférez exécuter les commandes de référence de l’interface de ligne de commande localement, installez l’interface Azure CLI. Si vous exécutez sur Windows ou macOS, envisagez d’exécuter Azure CLI dans un conteneur Docker. Pour plus d’informations, consultez Guide pratique pour exécuter Azure CLI dans un conteneur Docker.
- Si vous utilisez une installation locale, connectez-vous à Azure CLI à l’aide de la commande az login. Pour finir le processus d’authentification, suivez les étapes affichées dans votre terminal. Pour connaître les autres options de connexion, consultez Se connecter avec Azure CLI.
- Lorsque vous y êtes invité, installez l’extension Azure CLI lors de la première utilisation. Pour plus d’informations sur les extensions, consultez Utiliser des extensions avec Azure CLI.
- Exécutez az version pour rechercher la version et les bibliothèques dépendantes installées. Pour effectuer une mise à niveau vers la dernière version, exécutez az upgrade.

Cet article nécessite la version 2.0.64 ou ultérieure de l’interface Azure CLI. Si vous utilisez Azure Cloud Shell, la version la plus récente est déjà installée.
L’identité que vous utilisez pour créer votre cluster dispose des autorisations minimales appropriées. Pour plus d’informations sur l’accès et l’identité pour AKS, consultez Options d’accès et d’identité pour Kubernetes Azure Service (AKS).
Si vous avez plusieurs abonnements Azure, sélectionnez l’ID d’abonnement approprié dans lequel les ressources doivent être facturées avec la commande az account.
Vérifiez que les fournisseurs Microsoft.OperationsManagement et Microsoft.OperationalInsights sont inscrits dans votre abonnement. Ce sont des fournisseurs de ressources Azure nécessaires pour prendre en charge Container Insights. Pour vérifier l’état de l’inscription, exécutez les commandes suivantes :
```
az provider show -n Microsoft.OperationsManagement -o table
az provider show -n Microsoft.OperationalInsights -o table
```
S’ils ne sont pas inscrits, inscrivez Microsoft.OperationsManagement et Microsoft.OperationalInsights en utilisant les commandes suivantes :
```
az provider register --namespace Microsoft.OperationsManagement
az provider register --namespace Microsoft.OperationalInsights
```
Notes

Si vous exécutez les commandes mentionnées dans ce guide de démarrage rapide localement plutôt que dans Azure Cloud Shell, veillez à le faire avec des privilèges d’administrateur.

Limites

Les limitations suivantes s’appliquent lorsque vous créez et gérez les clusters AKS prenant en charge plusieurs pools de nœuds :

Vous ne pouvez pas supprimer le premier pool de nœuds.

Les limitations supplémentaires suivantes s’appliquent aux pools de nœuds Windows Server :

Le cluster AKS peut comprendre au maximum 10 pools de nœuds.
Le cluster AKS peut comprendre au maximum 100 nœuds dans chaque pool de nœuds.
Le nom de pool de nœud Windows Server a une limite de 6 caractères.

Créer un groupe de ressources

Un groupe de ressources Azure est un groupe logique dans lequel des ressources Azure sont déployées et gérées. Lorsque vous créez un groupe de ressources, vous devez spécifier un emplacement. Il s’agit de l’emplacement de stockage des métadonnées de groupe de ressources. C’est également là que vos ressources s’exécutent dans Azure si vous ne spécifiez pas une autre région lors de la création de ressources. Créez un groupe de ressources avec la commande az group create.

L’exemple suivant crée un groupe de ressources nommé myResourceGroup à l’emplacement eastus.

Notes

Cet article utilise la syntaxe Bash pour les commandes dans ce didacticiel. Si vous utilisez Azure Cloud Shell, assurez-vous que la liste déroulante dans le coin supérieur gauche de la fenêtre de Cloud Shell est définie sur Bash.

az group create --name myResourceGroup --location eastus

L’exemple de sortie suivant montre que le groupe de ressources a été créé correctement :

{
  "id": "/subscriptions/<guid>/resourceGroups/myResourceGroup",
  "location": "eastus",
  "managedBy": null,
  "name": "myResourceGroup",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null,
  "type": null
}

Créer un cluster AKS

Pour pouvoir exécuter un cluster AKS qui prend en charge des pools de nœuds pour les conteneurs Windows Server, votre cluster doit appliquer une stratégie de réseau qui utilise un plug-in réseau Azure CNI (avancé). Pour plus d’informations sur la planification des plages de sous-réseau nécessaires et les considérations réseau, consultez Configurer le réseau Azure CNI. Utilisez la commande az aks create pour créer un cluster AKS nommé myAKSCluster. Cette commande crée les ressources réseau nécessaires si elles n’existent pas.

Le cluster est configuré avec deux nœuds.
Les paramètres --windows-admin-password et --windows-admin-username définissent les informations d’identification d’administrateur pour tous les nœuds Windows Server du cluster et doivent répondre aux exigences relatives aux mots de passe de Windows Server. Si vous ne spécifiez pas le paramètre --windows-admin-password, vous êtes invité à fournir une valeur.
Le pool de nœuds utilise VirtualMachineScaleSets.

Notes

Pour garantir un fonctionnement fiable de votre cluster, vous devez exécuter au moins 2 (deux) nœuds dans le pool de nœuds par défaut.

Créez un nom d’utilisateur à utiliser en tant qu’informations d’identification d’administrateur pour les nœuds Windows Server sur votre cluster. Les commandes suivantes vous invitent à entrer un nom d’utilisateur et à le définir sur WINDOWS_USERNAME en vue d’une utilisation dans une commande ultérieure (n’oubliez pas que, dans cet article, les commandes sont entrées dans un interpréteur de commandes BASH).

echo "Please enter the username to use as administrator credentials for Windows Server nodes on your cluster: " && read WINDOWS_USERNAME

Créez votre cluster en vous assurant que vous spécifiez le paramètre --windows-admin-username. L’exemple de commande suivant crée un cluster à l’aide de la valeur de WINDOWS_USERNAME que vous avez définie dans la commande précédente. Vous pouvez également fournir un nom d’utilisateur différent directement dans le paramètre au lieu d’utiliser WINDOWS_USERNAME. La commande suivante vous invite également à créer un mot de passe pour les informations d’identification d’administrateur des nœuds Windows Server sur votre cluster. Vous pouvez également utiliser le paramètre --windows-admin-password et y spécifier votre propre valeur.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 2 \
    --enable-addons monitoring \
    --generate-ssh-keys \
    --windows-admin-username $WINDOWS_USERNAME \
    --vm-set-type VirtualMachineScaleSets \
    --network-plugin azure

Notes

Si vous recevez une erreur de validation du mot de passe, vérifiez que le mot de passe que vous avez défini respecte les exigences en matière de mot de passe de Windows Server. Si votre mot de passe répond aux conditions, essayez de créer votre groupe de ressources dans une autre région. Puis essayez de créer le cluster avec le nouveau groupe de ressources.

Si vous ne spécifiez pas un nom d’utilisateur et mot de passe d’administrateur lorsque vous définissez --vm-set-type VirtualMachineScaleSets et --network-plugin azure, le nom d’utilisateur est défini sur azureuser et le mot de passe sur une valeur aléatoire.

Le nom d’utilisateur de l’administrateur ne peut pas être modifié, mais vous pouvez modifier le mot de passe d’administrateur utilisé par votre cluster AKS pour les nœuds Windows Server à l’aide de la commande az aks update. Pour plus d’informations, consultez FAQ sur les pools de nœuds Windows Server.

Au bout de quelques minutes, la commande se termine et retourne des informations au format JSON sur le cluster. Parfois, le provisionnement du cluster peut prendre plus de quelques minutes. Autorisez jusqu’à 10 minutes dans ces cas de figure.

Ajouter un pool de nœuds Windows

Par défaut, un cluster AKS est créé avec un pool de nœuds qui peut exécuter des conteneurs Linux. Utilisez la commande az aks nodepool add pour ajouter un pool de nœuds supplémentaire qui peut exécuter des conteneurs Windows Server en même temps que le pool de nœuds Linux.

AKS prend en charge les pools de nœuds Windows Server 2019 et Windows Server 2022. Pour Kubernetes 1.25 et versions ultérieures, Windows Server 2022 est le système d’exploitation par défaut et la seule option sous Kubernetes 1.33 et versions ultérieures. Pour les versions antérieures, Windows Server 2019 est le système d’exploitation par défaut.

Utilisez la commande az aks nodepool add pour ajouter un pool de nœuds Windows :

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --os-type Windows \
    --name npwin \
    --node-count 1

La commande ci-dessus crée un pool de nœuds nommé npwin et l’ajoute à myAKSCluster. La commande ci-dessus utilise également le sous-réseau par défaut dans le réseau virtuel par défaut créé lors de l’exécution de az aks create. La référence SKU du système d’exploitation n’étant pas spécifiée, le pool de nœuds sera défini sur le système d’exploitation par défaut en fonction de la version de Kubernetes du cluster.

Ajouter un pool de nœuds Windows Server 2019

Notes

Windows Server 2019 est mis hors service à la fin de la version 1.32 de Kubernetes et ne sera pas pris en charge dans les versions ultérieures. Pour plus d’informations sur cette mise hors service, consultez les [notes de publication AKS][aks-release-notes].

Lors de la création d’un pool de nœuds Windows, sous Kubernetes 1.24 ou versions antérieures, le système d’exploitation par défaut sera Windows Server 2019. Pour utiliser des pools de nœuds Windows Server 2019 quand il ne s’agit pas de l’option par défaut, vous devez spécifier un type de référence SKU du système d’exploitation Windows2019.

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --os-type Windows \
    --os-sku Windows2019 \ 
    --name npwin \
    --node-count 1

La commande ci-dessus crée un pool de nœuds Windows Server 2019 nommé npwin et l’ajoute à myAKSCluster. La commande ci-dessus utilise également le sous-réseau par défaut dans le réseau virtuel par défaut créé lors de l’exécution de az aks create.

Ajouter un pool de nœuds Windows Server 2022

Lors de la création d’un pool de nœuds Windows, sous Kubernetes 1.25 ou versions ultérieures, le système d’exploitation par défaut sera Windows Server 2022. Pour utiliser des nœuds Windows Server 2022 quand il ne s’agit pas de l’option par défaut, vous devez spécifier un type de référence SKU du système d’exploitation Windows2022.

Notes

Windows Server 2022 requiert Kubernetes version « 1.23.0 » ou ultérieure.

Utilisez la commande az aks nodepool add pour ajouter un pool de nœuds Windows Server 2022 :

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --os-type Windows \
    --os-sku Windows2022 \ 
    --name npwin \
    --node-count 1

Facultatif : utilisation de `containerd` avec des pools de nœuds Windows Server

Depuis Kubernetes 1.20 et versions ultérieures, vous pouvez spécifier containerd comme runtime de conteneur pour des pools de nœuds Windows Server 2019. À compter de Kubernetes 1.23, containerd est le runtime de conteneur par défaut et le seul possible pour Windows.

Important

Lors de l’utilisation containerd de avec des pools de nœuds Windows Server 2019 :

Le plan de contrôle et les pools de nœuds Windows Server 2019 doivent utiliser Kubernetes version 1.20 ou ultérieure.
Lors de la création ou de la mise à jour d’un pool de nœuds pour exécuter des conteneurs Windows Server, la valeur par défaut de --node-vm-size est Standard_D2s_v3, soit la taille minimale recommandée pour des pools de nœuds Windows Server 2019 antérieurs à Kubernetes version 1.20. La taille minimale recommandée pour des pools de nœuds Windows Server 2019 utilisant containerd est Standard_D4s_v3. Si vous définissez le paramètre --node-vm-size, consultez la liste des tailles de machines virtuelles limitées.
Il est fortement recommandé d’utiliser des teintes ou des étiquettes avec vos pools de nœuds Windows Server 2019 exécutant containerd, et des tolérances ou des sélecteurs de nœud avec vos déploiements pour garantir que vos charges de travail sont correctement planifiées.

Ajouter un pool de nœuds Windows Server avec `containerd`

Utilisez la commande az aks nodepool add pour ajouter un pool de nœuds pouvant exécuter des conteneurs Windows Server avec le runtime containerd.

Notes

Si vous ne spécifiez pas l’en-tête personnalisé WindowsContainerRuntime=containerd, le pool de nœuds continue d’utiliser containerd comme runtime de conteneur par défaut.

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --os-type Windows \
    --name npwcd \
    --node-vm-size Standard_D4s_v3 \
    --kubernetes-version 1.20.5 \
    --aks-custom-headers WindowsContainerRuntime=containerd \
    --node-count 1

La commande ci-dessus crée un pool de nœuds Windows Server en utilisant containerd en tant que runtime nommé npwcd, et l’ajoute à myAKSCluster. La commande ci-dessus utilise également le sous-réseau par défaut dans le réseau virtuel par défaut créé lors de l’exécution de az aks create.

Mettre à niveau un pool de nœuds Windows Server existant vers `containerd`

Utilisez la commande az aks nodepool upgrade pour mettre à niveau un pool de nœuds spécifique de Docker vers containerd.

az aks nodepool upgrade \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name npwd \
    --kubernetes-version 1.20.7 \
    --aks-custom-headers WindowsContainerRuntime=containerd

La commande ci-dessus met à niveau un pool de nœuds nommé npwd vers le runtime containerd.

Pour mettre à niveau tous les pools de nœuds existants dans un cluster afin d’utiliser le runtime containerd pour tous les pools de nœuds Windows Server :

az aks upgrade \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --kubernetes-version 1.20.7 \
    --aks-custom-headers WindowsContainerRuntime=containerd

La commande ci-dessus met à niveau tous les pools de nœuds Windows Server dans myAKSCluster pour utiliser le runtime containerd.

Notes

Lors de l’exécution de la commande de mise à niveau, la --kubernetes-version spécifiée doit être supérieure à la version actuelle du pool de nœuds.

Se connecter au cluster

Pour gérer un cluster Kubernetes, vous utilisez kubectl, le client de ligne de commande Kubernetes. Si vous utilisez Azure Cloud Shell, kubectl est déjà installé. Pour installer kubectl en local, utilisez la commande az aks install-cli :

az aks install-cli

Pour configurer kubectl afin de vous connecter à votre cluster Kubernetes, exécutez la commande az aks get-credentials. Cette commande télécharge les informations d’identification et configure l’interface CLI Kubernetes pour les utiliser.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

Pour vérifier la connexion à votre cluster, utilisez la commande kubectl get pour retourner une liste des nœuds du cluster.

kubectl get nodes -o wide

L’exemple de sortie suivant montre tous les nœuds du cluster. Vérifiez que l’état de tous les nœuds est Prêt :

NAME                                STATUS   ROLES   AGE    VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                         KERNEL-VERSION     CONTAINER-RUNTIME
aks-nodepool1-12345678-vmss000000   Ready    agent   34m    v1.20.7   10.240.0.4    <none>        Ubuntu 18.04.5 LTS               5.4.0-1046-azure   containerd://1.4.4+azure
aks-nodepool1-12345678-vmss000001   Ready    agent   34m    v1.20.7   10.240.0.35   <none>        Ubuntu 18.04.5 LTS               5.4.0-1046-azure   containerd://1.4.4+azure
aksnpwcd123456                      Ready    agent   9m6s   v1.20.7   10.240.0.97   <none>        Windows Server 2019 Datacenter   10.0.17763.1879    containerd://1.4.4+unknown
aksnpwin987654                      Ready    agent   25m    v1.20.7   10.240.0.66   <none>        Windows Server 2019 Datacenter   10.0.17763.1879    docker://19.3.14

Notes

Le runtime de conteneur pour chaque pool de nœuds est affiché sous CONTAINER-RUNTIME. Notez que aksnpwin987654 commence par docker://, ce qui signifie qu’il utilise Docker pour le runtime de conteneur. Notez que aksnpwcd123456 commence par containerd://, ce qui signifie qu’il utilise containerd pour le runtime de conteneur.

Déployer l’application

Un fichier manifeste Kubernetes définit un état souhaité pour le cluster, notamment les images conteneur à exécuter. Dans cet article, un manifeste est utilisé pour créer tous les objets nécessaires pour exécuter l’exemple d’application ASP.NET dans un conteneur Windows Server. Ce manifeste comprend un déploiement Kubernetes pour l’exemple d’application ASP.NET et un service Kubernetes externe pour accéder à l’application à partir d’Internet.

L’exemple d’application ASP.NET est fourni dans le cadre des Exemples .NET Framework et s’exécute dans un conteneur Windows Server. AKS exige que les conteneurs Windows Server soient basés sur des images de Windows Server 2019 ou versions supérieures. Le fichier manifeste Kubernetes doit également définir un sélecteur de nœud pour indiquer à votre cluster AKS d’exécuter le pod de votre exemple d’application ASP.NET sur un nœud qui peut exécuter des conteneurs Windows Server.

Créez un fichier nommé sample.yaml, et copiez-y la définition YAML suivante. Si vous utilisez Azure Cloud Shell, vous pouvez créer ce fichier à l’aide de code, vi ou nano comme si vous travailliez sur un système virtuel ou physique :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample
  labels:
    app: sample
spec:
  replicas: 1
  template:
    metadata:
      name: sample
      labels:
        app: sample
    spec:
      nodeSelector:
        "kubernetes.io/os": windows
      containers:
      - name: sample
        image: mcr.microsoft.com/dotnet/framework/samples:aspnetapp
        resources:
          limits:
            cpu: 1
            memory: 800M
        ports:
          - containerPort: 80
  selector:
    matchLabels:
      app: sample
---
apiVersion: v1
kind: Service
metadata:
  name: sample
spec:
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 80
  selector:
    app: sample

Pour obtenir une décomposition des fichiers manifeste YAML, consultez Déploiements et manifestes YAML.

Déployez l’application à l’aide de la commande kubectl apply et spécifiez le nom de votre manifeste YAML :

kubectl apply -f sample.yaml

L’exemple de sortie suivant montre que le déploiement et le service ont été créés correctement :

deployment.apps/sample created
service/sample created

Test de l’application

Quand l’application s’exécute, un service Kubernetes expose le front-end de l’application sur Internet. L’exécution de ce processus peut prendre plusieurs minutes. Parfois, le provisionnement du service peut prendre plus de quelques minutes. Autorisez jusqu’à 10 minutes dans ces cas de figure.

Pour surveiller la progression, utilisez la commande kubectl get service avec l’argument --watch.

kubectl get service sample --watch

Dans un premier temps, la valeur EXTERNAL-IP pour l’exemple de service apparaît comme étant en attente.

NAME               TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
sample             LoadBalancer   10.0.37.27   <pending>     80:30572/TCP   6s

Quand l’adresse EXTERNAL-IP passe de l’état pending à une adresse IP publique réelle, utilisez CTRL-C pour arrêter le processus de surveillance kubectl. L’exemple de sortie suivant montre une adresse IP publique valide affectée au service :

sample  LoadBalancer   10.0.37.27   52.179.23.131   80:30572/TCP   2m

Pour voir l’exemple d’application en action, ouvrez un navigateur web en utilisant l’adresse IP externe de votre service.

Capture d’écran de la navigation vers l’exemple d’application ASP.NET.

Notes

Si vous dépassez le délai d’expiration en tentant de charger la page, vous devez vérifier que l’exemple d’application est prêt avec la commande [kubectl get pods --watch] suivante. Parfois, le conteneur Windows n’est pas démarré au moment où votre adresse IP externe est disponible.

Supprimer un cluster

Pour éviter les frais Azure, si vous ne prévoyez pas d’effectuer les tutoriels qui suivent, utilisez la commande az group delete pour supprimer le groupe de ressources, le service de conteneur et toutes les ressources associées.

az group delete --name myResourceGroup --yes --no-wait

Notes

Le cluster AKS a été créé avec une identité managée affectée par le système (option d’identité par défaut utilisée dans ce guide de démarrage rapide), cette identité est gérée par la plateforme et ne nécessite pas de suppression.

Étapes suivantes

Dans cet article, vous avez déployé un cluster Kubernetes et déployé un exemple d’application ASP.NET dans un conteneur Windows Server vers ce cluster.

Pour en savoir plus sur AKS et parcourir le code complet de l’exemple de déploiement, passez au tutoriel sur le cluster Kubernetes.

Didacticiel AKS

Créer un conteneur Windows Server sur un cluster Azure Kubernetes Service (AKS) à l’aide d’Azure CLI

Prérequis

Limites

Créer un groupe de ressources

Créer un cluster AKS

Ajouter un pool de nœuds Windows

Ajouter un pool de nœuds Windows Server 2019

Ajouter un pool de nœuds Windows Server 2022

Facultatif : utilisation de `containerd` avec des pools de nœuds Windows Server

Ajouter un pool de nœuds Windows Server avec `containerd`

Mettre à niveau un pool de nœuds Windows Server existant vers `containerd`

Se connecter au cluster

Déployer l’application

Test de l’application

Supprimer un cluster

Étapes suivantes

Ressources supplémentaires

Ressources supplémentaires

Créer un conteneur Windows Server sur un cluster Azure Kubernetes Service (AKS) à l’aide d’Azure CLI

Prérequis

Limites

Créer un groupe de ressources

Créer un cluster AKS

Ajouter un pool de nœuds Windows

Ajouter un pool de nœuds Windows Server 2019

Ajouter un pool de nœuds Windows Server 2022

Facultatif : utilisation de containerd avec des pools de nœuds Windows Server

Ajouter un pool de nœuds Windows Server avec containerd

Mettre à niveau un pool de nœuds Windows Server existant vers containerd

Se connecter au cluster

Déployer l’application

Test de l’application

Supprimer un cluster

Étapes suivantes

Ressources supplémentaires

Ressources supplémentaires

Facultatif : utilisation de `containerd` avec des pools de nœuds Windows Server

Ajouter un pool de nœuds Windows Server avec `containerd`

Mettre à niveau un pool de nœuds Windows Server existant vers `containerd`