Adapter les applications pour une utilisation dans les clusters Kubernetes de système d’exploitation mixte
S’applique à : AKS sur Azure Stack HCI 22H2, AKS sur Windows Server
AKS activé par Azure Arc vous permet d’exécuter des clusters Kubernetes avec des nœuds Linux et Windows, mais vous devez apporter de petites modifications à vos applications pour les utiliser dans ces clusters de système d’exploitation mixte. Dans ce guide pratique, vous apprendrez à vous assurer que votre application est planifiée sur le système d’exploitation hôte approprié à l’aide de sélecteurs de nœuds ou de teintes et de tolérances.
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 hybrid.
Sélecteurs de nœud
Un sélecteur de nœud est un champ simple dans le YAML de spécification de pod qui contraint les pods à être planifiés uniquement sur des nœuds sains correspondant au système d’exploitation. Dans votre spécification de pod YAML, spécifiez un nodeSelector
: Windows ou Linux, comme illustré dans les exemples suivants :
kubernetes.io/os = Windows
ou
kubernetes.io/os = Linux
Pour plus d’informations sur les nodeSelectors, consultez Sélecteurs de nœuds.
Teintes et tolérances
Les aversions et les tolérances fonctionnent ensemble pour s’assurer que les pods ne sont pas planifiés sur les nœuds de manière involontaire. Un nœud peut être « teinté » pour rejeter les pods qui ne tolèrent pas explicitement sa teinte par le biais d’une « tolérance » dans la spécification de pod YAML.
Les nœuds de système d’exploitation Windows dans AKS Arc peuvent être contaminés lorsqu’ils sont créés avec les commandes New-AksHciNodePool ou New-AksHciCluster . Vous pouvez également utiliser ces commandes afin de marquer pour aversion des nœuds de système d’exploitation Linux. L’exemple suivant teinte les nœuds Windows.
Appliquer une teinte au nouveau cluster
Si vous créez également un cluster, exécutez la commande suivante pour créer un pool de nœuds Windows avec une teinte. Si vous avez un cluster existant auquel vous souhaitez ajouter un pool de nœuds avec une teinte, consultez l’exemple suivant, qui utilise la New-AksHciNodePool
commande .
New-AksHciCluster -name mycluster -nodePoolName taintnp -nodeCount 1 -osType Windows -osSku Windows2022 -taints sku=Windows:NoSchedule
Ajouter un pool de nœuds contaminés à un cluster existant
Pour ajouter un pool de nœuds marqué pour aversion à un cluster existant, exécutez la commande suivante :
New-AksHciNodePool -clusterName <cluster-name> -nodePoolNAme taintnp -count 1 -osType Windows -osSku Windows2022 -taints sku=Windows:NoSchedule
Pour vérifier que le pool de nœuds a été déployé correctement avec l’aversion, exécutez la commande suivante :
Get-AksHciNodePool -clusterName <cluster-name> -name taintnp
Exemple de sortie :
Status : {Phase, Details}
ClusterName : mycluster
NodePoolName : taintnp
Version : v1.20.7-kvapkg.1
OsType : Windows
NodeCount : 0
VmSize : Standard_K8S3_v1
Phase : Deployed
Taints : {sku=Windows:NoSchedule}
Spécifier la tolérance pour le pod
Vous pouvez spécifier une tolérance pour un pod dans la spécification de pod YAML. La tolérance suivante « correspond » à la teinte créée par la kubectl
ligne de teinte indiquée dans l’exemple précédent. Le résultat est qu’un pod avec la tolérance peut planifier sur les nœuds contaminés.
tolerations:
- key: node.kubernetes.io/os
operator: Equal
value: Windows
effect: NoSchedule
Les étapes décrites dans cette section fonctionnent bien si vous contrôlez la spécification de pod que vous déployez. Toutefois, dans certains cas, les utilisateurs disposent d’un grand nombre de déploiements pour les conteneurs Linux, ainsi que d’un écosystème de configurations courantes, telles que les graphiques Helm de la communauté. Vous n’aurez pas accès à la spécification de pod, sauf si vous souhaitez télécharger et modifier le graphique.
Si vous déployez ces graphiques Helm dans un environnement de cluster mixte avec des nœuds Worker Linux et Windows, vos pods d’application échouent avec l’erreur « ImagePullBackOff ». Par exemple :
kubectl get pods
NAMESPACE NAME READY STATUS RESTARTS AGE
default nginx-deployment-558fc78868-795dp 0/1 ImagePullBackOff 0 6m24s
default nginx-deployment-6b474476c4-gpb77 0/1 ImagePullBackOff 0 11m
Dans cette instance, vous pouvez utiliser des teintes pour y remédier. Les nœuds Windows Server peuvent être contaminés par la paire node.kubernetes.io/os=windows:NoSchedule
clé-valeur .
Pour plus d’informations sur les teintes et les tolérances, consultez Teintes et tolérances.
Étapes suivantes
Dans ce guide pratique, vous avez appris à ajouter des sélecteurs de nœuds ou des teintes et des tolérances à vos clusters Kubernetes à l’aide de kubectl. À présent, vous pouvez :
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultezEnvoyer et afficher des commentaires pour