Considérations relatives au conteneur Windows avec Azure Kubernetes Service

Lorsque vous créez des déploiements qui utilisent des conteneurs Windows Server sur Azure Kubernetes Service (AKS), il y a quelques différences par rapport aux déploiements Linux que vous devez garder à l’esprit. Pour une comparaison détaillée des différences entre Windows et Linux dans Kubernetes en amont, consultez Conteneurs Windows dans Kubernetes.

Certaines des principales différences sont les suivantes :

• Identité : Windows Server utilise un identificateur de sécurité binaire (SID) plus long qui est stocké dans la base de données Windows Security Access Manager (SAM). Cette base de données n’est pas partagée entre l’hôte et les conteneurs, ou entre conteneurs.
• Autorisations de fichiers : Windows Server utilise une liste de contrôle d’accès basée sur les SID, plutôt qu’un masque de bits d’autorisations et d’UID et GID.
• Chemins de fichiers : La convention sur Windows Server consiste à utiliser \ au lieu de /. Dans les spécifications de pod qui montent des volumes, spécifiez le chemin d’accès correctement pour les conteneurs Windows Server. Par exemple, au lieu d’un point de montage de /mnt/volume dans un conteneur Linux, spécifiez une lettre de lecteur et un emplacement comme /K/Volume à monter en tant que lecteur K: .

Remarque

Pour les versions 1.25 et supérieures de Kubernetes, Windows Server 2022 est le système d’exploitation par défaut. Windows Server 2019 est mis hors service après la version 1.32 de Kubernetes et ne sera pas pris en charge dans les versions ultérieures. Pour plus d’informations, consultez les notes de publication de la version AKS.

Cet article couvre les considérations importantes à garder à l’esprit lors de l’utilisation de conteneurs Windows au lieu de conteneurs Linux dans Kubernetes. Pour une comparaison approfondie des conteneurs Windows et Linux, consultez Comparaison avec linux.

À propos de l’installation

Fonction	Considérations Windows
Création du cluster	• Le premier pool de nœuds du système doit être Linux. • Le nombre maximal de nœuds par cluster est de 5000. • Le nom de pool de nœud serveur Windows a une limite de 6 caractères.
Conteneurs privilégiés	Non pris en charge. L’équivalent est conteneurs HOSTProcess Containers (HPC).
Conteneurs HPC	• Les conteneurs HostProcess sont l’alternative Windows aux conteneurs privilégiés Linux. Pour plus d’informations, consultez Créer un pod Windows HostProcess.
Gestionnaire de stratégies réseau Azure (Azure)	Azure Network Policy Manager ne prend pas en charge : • Ports nommés • Protocole SCTP • Étiquettes de correspondance négative ou sélecteurs d’espace de noms (toutes les étiquettes à l’exception de « debug=true ») • Blocs CIDR « except » (CIDR avec exceptions) • Windows Server 2019
Mise à niveau de nœud	Les nœuds Windows Server sur AKS n’appliquent pas automatiquement les mises à jour Windows. Au lieu de cela, vous effectuez une mise à niveau d’un pool de nœuds ou une mise à niveau d’image de nœud. Ces mises à niveau déploient de nouveaux nœuds avec la dernière image de nœud de base de Window Server 2019 et Windows Server 2022 et des correctifs de sécurité.
Nettoyeur d’image AKS	Non pris en charge.
BYOCNI	Non pris en charge.
Open Service Mesh	Non pris en charge.
GPU	Pris en charge en préversion.
Multi-instances GPU	Non pris en charge.
Machines virtuelles de 2e génération (préversion)	Pris en charge.
Configuration de nœuds personnalisés	• La configuration de nœud personnalisée a deux configurations : • kubelet : pris en charge. • Configuration du système d’exploitation : non prise en charge.

Étapes suivantes

Pour plus d’informations sur les conteneurs Windows, voir la FAQ sur les conteneurs Windows Server.