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:NoScheduleclé-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 :