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 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 une utilisation dans ces clusters de système d’exploitation mixte. Ce guide pratique explique comment s’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 les concepts fondamentaux de Kubernetes pour AKS activés par Arc.
Sélecteurs de nœud
Un sélecteur de nœuds est un champ simple dans la spécification de pod YAML qui limite 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 une nodeSelector
valeur de Windows ou Linux, comme indiqué dans les exemples suivants :
kubernetes.io/os = Windows
ou
kubernetes.io/os = Linux
Pour plus d’informations sur les sélecteurs de nœuds, consultez sélecteurs de nœuds.
Teintes et tolérances
Les teintes et les tolérances fonctionnent ensemble pour s’assurer que les pods ne sont pas planifiés involontairement sur les nœuds. Un nœud peut être « teinte » pour rejeter les pods qui ne tolèrent pas explicitement sa teinte par le biais d’une « tolérance » dans la spécification du pod YAML.
Les nœuds de système d’exploitation Windows dans AKS Arc peuvent être teintes lors de la création avec new-AksHciNodePool ou les commandes 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 à un 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 disposez d’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é à 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 du 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 correctement 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 du 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 cet exemple, vous pouvez utiliser des teintes pour vous aider à cela. 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 Taints et Tolerations.
É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 :