Foire aux questions relative aux pools de nœuds Windows Server dans AKS

  • Article

Dans Azure Kubernetes Service (AKS), vous pouvez créer un pool de nœuds qui exécute Windows Server en tant que système d’exploitation invité sur les nœuds. Ces nœuds peuvent exécuter des applications de conteneur Windows natives, comme celles reposant sur .NET Framework. Il existe des différences dans la manière dont les systèmes d’exploitation Linux et Windows prennent en charge les conteneurs. Certaines fonctionnalités courantes relatives à Linux Kubernetes et aux pods ne sont pas actuellement disponibles pour les pools de nœuds Windows.

Cet article présente certaines des questions fréquemment posées et quelques concepts de système d’exploitation pour les nœuds Windows Server dans AKS.

Quels sont les types de disques pris en charge pour Windows ?

Les disques et fichiers Azure sont les types de volumes pris en charge, et sont accessibles en tant que volumes NTFS dans le conteneur Windows Server.

Linux et Windows prennent-ils en charge les machines virtuelles de génération 2 ?

Les machines virtuelles de génération 2 sont prises en charge sur Linux et Windows uniquement pour WS2022. Pour plus d’informations, consultez Prise en charge des machines virtuelles de 2e génération dans Azure.

Comment corriger mes nœuds Windows ?

Afin d’obtenir les derniers correctifs pour les nœuds Windows, vous pouvez soit mettre à niveau le pool de nœuds, soit mettre à niveau l’image de nœud. Les mises à jour Windows ne sont pas activées sur les nœuds dans AKS. AKS met en production de nouvelles images de pool de nœuds dès que des correctifs sont disponibles. Il incombe à l’utilisateur de mettre à niveau les pools de nœuds pour rester à jour en matière de correctifs. Le processus correctif est également vrai pour la version de Kubernetes utilisée. Les notes de publication d’AKS indiquent quand de nouvelles versions sont disponibles. Pour plus d’informations sur la mise à niveau d’un pool de nœuds Windows Server, consultez Mettre à niveau un pool de nœuds. Si vous souhaitez uniquement mettre à jour l’image de nœud, consultez Mises à niveau d’une image de nœud AKS.

Notes

L’image Windows Server mise à jour n’est utilisée que si une mise à niveau de cluster (mise à niveau de plan de contrôle) a été effectuée avant la mise à niveau du pool de nœuds.

La conservation de l’adresse IP source du client est-elle prise en charge ?

À l’heure actuelle, la préservation de l’adresse IP source du client n’est pas prise en charge avec les nœuds Windows.

Puis-je modifier le nombre maximal de pods par nœud ?

Oui. Pour connaître les implications d’une telle modification et les options disponibles, consultez Nombre maximal de pods.

Quel est le délai d’expiration TCP par défaut dans le système d’exploitation Windows ?

Le délai d’expiration TCP par défaut dans le système d’exploitation Windows est de 4 minutes. Cette valeur n’est pas configurable. Lorsqu’une application utilise un délai d’expiration plus long, les connexions TCP entre différents conteneurs dans le même nœud se ferment au bout de quatre minutes.

Pourquoi un message d’erreur s’affiche-t-il lorsque j’essaie de créer un pool d’agents Windows ?

Si vous avez créé votre cluster avant février 2020 et n’avez jamais effectué d’opérations de mise à niveau du cluster, le cluster utilise toujours une ancienne image Windows. Vous avez peut-être rencontré une erreur ressemblant à ceci :

« La liste suivante d’images référencées à partir du modèle de déploiement est introuvable : Éditeur : MicrosoftWindowsServer, Offre : WindowsServer, référence (SKU) : 2019-datacenter-core-smalldisk-2004, Version : dernière. Consultez Rechercher et utiliser des images de machine virtuelle de Place de marché Azure avec Azure PowerShell pour obtenir des instructions sur la recherche d’images disponibles. »

Pour résoudre ce problème :

  1. Mettez à niveau le plan de contrôle du cluster pour mettre à jour l’offre et l’éditeur de l’image.
  2. Créez des pools d’agents Windows.
  3. Déplacez les pod Windows des pools d’agents Windows existants vers les nouveaux pools d’agents Windows.
  4. Supprimez les anciens pools d’agents Windows.

Pourquoi un message d’erreur s’affiche-t-il lorsque j’essaie de déployer des pods Windows ?

Si vous spécifiez une valeur dans --max-pods inférieure au nombre de pods que vous souhaitez créer, l’erreur No available addresses peut s’afficher.

Pour corriger cette erreur, utilisez la commande az aks nodepool add avec une valeur --max-pods suffisamment élevée :

az aks nodepool add \
    --cluster-name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP \
    --name $NODEPOOL_NAME \
    --max-pods 3

Pour obtenir des informations plus détaillées, consultez la documentation --max-pods.

Pourquoi existe-t-il un utilisateur inattendu nommé « sshd » sur mon nœud de machine virtuelle ?

AKS ajoute un utilisateur nommé « sshd » lors de l’installation du service OpenSSH. Cet utilisateur n’est pas malveillant. Nous recommandons aux clients de mettre à jour leurs alertes pour ignorer ce compte d’utilisateur inattendu.

Comment faire pivoter le principal du service pour mon pool de nœuds Windows ?

Les pools de nœuds Windows ne prennent pas en charge la rotation du principal de service. Pour mettre à jour le principal du service, créez un pool de nœuds Windows, puis migrez vos pods de l’ancien pool vers le nouveau. Une fois que vos pods ont migré vers le nouveau pool, supprimez l’ancien pool de nœuds.

Au lieu des principaux de service, utilisez des identités managées, qui sont essentiellement des wrappers autour des principaux de service. Pour plus d’informations, voir Utiliser les identités managées dans Azure Kubernetes Service.

Comment modifier le mot de passe d’administrateur pour les nœuds Windows Server sur mon cluster ?

Lorsque vous créez votre cluster AKS, vous spécifiez les paramètres --windows-admin-password et --windows-admin-username afin de définir les informations d’identification d’administrateur pour tous les nœuds Windows Server du cluster. Si vous n’avez pas spécifié d’informations d’identification d’administrateur lors de la création d’un cluster à l’aide du portail Azure ou lors de la définition de --vm-set-type VirtualMachineScaleSets et --network-plugin azure à l’aide d’Azure CLI, le nom d’utilisateur est défini par défaut sur azureuser et un mot de passe aléatoire.

Pour modifier le mot de passe d’administrateur, utilisez la commande az aks update suivante :

az aks update \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --windows-admin-password $NEW_PW

Important

Effectuer l’opération az aks update met à niveau uniquement les pools de nœuds Windows Server et entraîne un redémarrage. Les pools de nœuds Linux ne sont pas affectés.

Lorsque vous modifiez --windows-admin-password, le nouveau mot de passe doit comporter au moins 14 caractères et répondre aux exigences de mot de passe de Windows Server.

Combien de pools de nœuds puis-je créer ?

Un cluster AKS avec des pools de nœuds Windows n’a pas de limite de ressource AKS différente de la valeur par défaut spécifiée pour le service AKS. Pour plus d’informations, consultez Quotas, restrictions de taille de machine virtuelle et disponibilité des régions dans Azure Kubernetes Service (AKS).

Comment puis-je nommer mes pools de nœuds Windows ?

Un pool de nœuds Windows peut avoir un nom à six caractères.

Toutes les fonctionnalités sont-elles prises en charge avec les nœuds Windows ?

Kubenet n’est actuellement pas pris en charge sur les nœuds Windows.

Puis-je exécuter des contrôleurs d’entrée sur des nœuds Windows ?

Oui, un contrôleur d’entrée prenant en charge les conteneurs Windows Server peut s’exécuter sur des nœuds Windows dans AKS.

Mes conteneurs Windows Server peuvent-ils utiliser gMSA ?

La prise en charge du compte de service géré par groupe (gMSA) est généralement disponible pour Windows sur AKS. Consultez Activer les comptes de services gérés de groupe (gMSA) pour vos nœuds Windows Server sur votre cluster Azure Kubernetes Service (AKS)

Puis-je utiliser Azure Monitor pour des conteneurs avec des nœuds et conteneurs Windows ?

Oui, vous pouvez. Toutefois, Azure Monitor est en préversion publique pour la collecte des journaux (stdout, stderr) et des métriques des conteneurs Windows. Vous pouvez aussi établir un attachement au flux en direct des journaux stdout à partir d’un conteneur Windows.

Existe-t-il des limites au nombre de services sur un cluster avec des nœuds Windows ?

Un cluster avec des nœuds Windows peut avoir environ 500 services (parfois moins) avant d’être confronté à l’épuisement des ports. Cette limitation s’applique à un service Kubernetes avec une stratégie de trafic externe définie sur « Cluster ».

Lorsque la stratégie de trafic externe sur un service est configurée en tant que cluster, le trafic subit une NAT source supplémentaire sur le nœud, ce qui entraîne également la réservation d’un port à partir du pool de ports dynamiques TCPIP. Ce pool de ports est une ressource limitée (environ 16 000 ports par défaut) et de nombreuses connexions actives à un ou plusieurs services peuvent conduire à un épuisement dynamique du pool de ports entraînant des baisses de connexion.

Si le service Kubernetes est configuré avec la stratégie de trafic externe définie sur « Local », les problèmes d’épuisement des ports ne sont pas susceptibles de se produire à 500 services.

Puis-je utiliser Azure Hybrid Benefit avec des nœuds Windows ?

Oui. Azure Hybrid Benefit pour Windows Server réduit les coûts d’exploitation en vous permettant de placer votre licence Windows Server locale sur des nœuds Windows AKS.

Azure Hybrid Benefit peut être utilisé sur l’ensemble de votre cluster AKS ou sur des nœuds individuels. Pour les nœuds individuels, vous devez accéder au groupe de ressources des nœuds et appliquer Azure Hybrid Benefit aux nœuds directement. Pour plus d’informations relatives à l’application d’Azure Hybrid Benefit sur des nœuds individuels, consultez Azure Hybrid Benefit pour Windows Server.

Pour utiliser Azure Hybrid Benefit sur un nouveau cluster AKS, utilisez la commande az aks create et l’argument --enable-ahub.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-sku Standard \
    --windows-admin-password 'Password1234$' \
    --windows-admin-username azure \
    --network-plugin azure
    --enable-ahub

Pour utiliser Azure Hybrid Benefit sur un cluster AKS existant, exécutez la commande az aks update et utilisez la mise à jour du cluster à l’aide de l’argument --enable-ahub.

az aks update \
    --resource-group myResourceGroup
    --name myAKSCluster
    --enable-ahub

Pour vérifier si Azure Hybrid Benefit est défini sur les nœuds Windows du cluster, exécutez la commande az vmss show avec les arguments --name et --resource-group pour interroger le groupe de machines virtuelles identiques. Pour identifier le groupe de ressources crée par le groupe identique pour le pool de nœuds Windows, vous pouvez exécuter la commande az vmss list -o table.

az vmss show --name myScaleSet --resource-group MC_<resourceGroup>_<clusterName>_<region>

Si les nœuds Windows du groupe identique ont Azure Hybrid Benefit activés, la sortie az vmss show est similaire à ce qui suit :

""hardwareProfile": null,
    "licenseType": "Windows_Server",
    "networkProfile": {
      "healthProbe": null,
      "networkApiVersion": null,

Comment modifier le fuseau horaire d’un conteneur en cours d’exécution ?

Pour modifier le fuseau horaire d’un conteneur Windows Server en cours d’exécution, connectez-vous au conteneur en cours d’exécution avec une session PowerShell. Par exemple :

kubectl exec -it CONTAINER-NAME -- powershell

Dans le conteneur en cours d’exécution, utilisez Set-TimeZone pour définir le fuseau horaire du conteneur en cours d’exécution. Par exemple :

Set-TimeZone -Id "Russian Standard Time"

Pour afficher le fuseau horaire actuel du conteneur en cours d’exécution ou une liste de fuseaux horaires disponible, utilisez Get-TimeZone.

Puis-je maintenir l’affinité de session des connexions des clients aux pods avec des conteneurs Windows ?

Bien que le maintien de l’affinité de session entre les connexions des clients et les pods avec des conteneurs Windows sera pris en charge dans la version du système d’exploitation Windows Server 2022, vous obtenez actuellement l’affinité de session par l’adresse IP du client en limitant votre pod souhaité à l’exécution d’une seule instance par nœud et en configurant votre service Kubernetes pour diriger le trafic vers le pod sur le nœud local.

Utilisez la configuration suivante :

  1. Utilisez un cluster AKS avec une version minimale de 1.20.
  2. Limitez votre pod à une seule instance par nœud Windows. Vous pouvez y parvenir en utilisant l’anti-affinité dans votre configuration de déploiement.
  3. Dans la configuration de votre service Kubernetes, définissez externalTrafficPolicy=Local. Cela garantit que le service Kubernetes dirige le trafic uniquement vers les pods du nœud local.
  4. Dans la configuration de votre service Kubernetes, définissez sessionAffinity: ClientIP. Cela garantit que l’équilibreur de charge Azure est configuré avec l’affinité de session.

Étapes suivantes

Pour vous lancer avec des conteneurs Windows Server dans AKS, consultez Créer un pool de nœuds qui exécute Windows Server dans AKS.