Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Exécution de charges de travail hétérogènes
Kubernetes prend en charge les clusters hétérogènes dans lesquels vous pouvez avoir un mélange de nœuds Linux et Windows dans le même cluster. Au sein de ce cluster, vous pouvez avoir un mélange de pods qui s'exécutent sous Linux et de pods qui s'exécutent sous Windows. Vous pouvez même exécuter plusieurs versions de Windows dans le même cluster. Cependant, plusieurs facteurs (tels que mentionnés ci-dessous) devront être pris en compte lors de la prise de cette décision.
## Meilleures pratiques en matière d'attribution de POD aux nœuds
Afin de conserver les charges de travail Linux et Windows sur leurs OS-specific nœuds respectifs, vous devez utiliser une combinaison de sélecteurs de nœuds et. taints/tolerations L'objectif principal de la planification des charges de travail dans un environnement hétérogène est d'éviter de compromettre la compatibilité des charges de travail Linux existantes.
## Veiller à ce que OS-specific les charges de travail arrivent sur le conteneur hôte approprié
Les utilisateurs peuvent s'assurer que les conteneurs Windows peuvent être planifiés sur l'hôte approprié à l'aide de NodeSelectors. Tous les nœuds Kubernetes portent aujourd'hui les libellés par défaut suivants :
```
kubernetes.io/os = [windows|linux]
kubernetes.io/arch = [amd64|arm64|...]
```
Si une spécification de Pod n'inclut pas de NodeSelector`"kubernetes.io/os": windows`, le Pod peut être planifié sur n'importe quel hôte, Windows ou Linux. Cela peut être problématique car un conteneur Windows ne peut fonctionner que sous Windows et un conteneur Linux ne peut fonctionner que sous Linux.
Dans les environnements d'entreprise, il n'est pas rare de disposer d'un grand nombre de déploiements préexistants pour les conteneurs Linux, ainsi que d'un écosystème de configurations prêtes à l'emploi, comme les cartes Helm. Dans ces situations, vous pouvez hésiter à apporter des modifications aux NodeSelectors d'un déploiement. **L'alternative est d'utiliser Taints.**
Par exemple : `--register-with-taints='os=windows:NoSchedule'`
Si vous utilisez EKS, eksctl propose des moyens d'appliquer des taches via ClusterConfig :
```
NodeGroups:
- name: windows-ng
amiFamily: WindowsServer2022FullContainer
...
labels:
nodeclass: windows2022
taints:
os: "windows:NoSchedule"
```
En altérant tous les nœuds Windows, le planificateur ne planifiera pas les pods sur ces nœuds à moins qu'ils ne tolèrent cette altération. Exemple de manifeste Pod :
```
nodeSelector:
kubernetes.io/os: windows
tolerations:
- key: "os"
operator: "Equal"
value: "windows"
effect: "NoSchedule"
```
## Gestion de plusieurs versions de Windows dans le même cluster
L'image de base du conteneur Windows utilisée par chaque pod doit correspondre à la même version de construction du noyau que le nœud. **Si vous souhaitez utiliser plusieurs versions de Windows Server dans le même cluster, vous devez définir des étiquettes de nœuds supplémentaires, des NodeSelectors ou utiliser une étiquette appelée windows-build.**
**Kubernetes 1.17 ajoute automatiquement une nouvelle étiquette node.kubernetes. io/windows-build** pour simplifier la gestion de plusieurs versions de Windows dans le même cluster. Si vous utilisez une ancienne version, il est recommandé d'ajouter cette étiquette manuellement aux nœuds Windows.
Cette étiquette indique les numéros de version majeure, mineure et de version de Windows qui doivent correspondre pour des raisons de compatibilité. Vous trouverez ci-dessous les valeurs utilisées aujourd'hui pour chaque version de Windows Server.
Il est important de noter que Windows Server passe au canal de Long-Term maintenance (LTSC) en tant que canal de publication principal. Le Semi-Annual canal Windows Server (SAC) a été retiré le 9 août 2022. Il n'y aura aucune future version SAC de Windows Server.
| Nom de produit | Numéro (s) de version |
| --- | --- |
| Serveur LTSC 2022 complet | 10,0.20348 |
| Noyau du serveur 2019 LTSC | 10,0.17763 |
Il est possible de vérifier la version de build du système d'exploitation à l'aide de la commande suivante :
```
kubectl get nodes -o wide
```
La KERNEL-VERSION sortie correspond à la version de build du système d'exploitation Windows.
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
ip-10-10-2-235.ec2.internal Ready 23m v1.24.7-eks-fb459a0 10.10.2.235 3.236.30.157 Windows Server 2022 Datacenter 10.0.20348.1607 containerd://1.6.6
ip-10-10-31-27.ec2.internal Ready 23m v1.24.7-eks-fb459a0 10.10.31.27 44.204.218.24 Windows Server 2019 Datacenter 10.0.17763.4131 containerd://1.6.6
ip-10-10-7-54.ec2.internal Ready 31m v1.24.11-eks-a59e1f0 10.10.7.54 3.227.8.172 Amazon Linux 2 5.10.173-154.642.amzn2.x86_64 containerd://1.6.19
```
L'exemple ci-dessous applique un NodeSelector supplémentaire au manifeste du pod afin de correspondre à la Windows-build version correcte lors de l'exécution de différentes versions du système d'exploitation de groupes de nœuds Windows.
```
nodeSelector:
kubernetes.io/os: windows
node.kubernetes.io/windows-build: '10.0.20348'
tolerations:
- key: "os"
operator: "Equal"
value: "windows"
effect: "NoSchedule"
```
## Simplification NodeSelector et tolérance dans les manifestes Pod à l'aide de RuntimeClass
Vous pouvez également l'utiliser RuntimeClass pour simplifier le processus d'utilisation des teintures et des tolérances. Cela peut être accompli en créant un RuntimeClass objet qui est utilisé pour encapsuler ces souillures et tolérances.
Créez un RuntimeClass en exécutant le manifeste suivant :
```
apiVersion: node.k8s.io/v1beta1
kind: RuntimeClass
metadata:
name: windows-2022
handler: 'docker'
scheduling:
nodeSelector:
kubernetes.io/os: 'windows'
kubernetes.io/arch: 'amd64'
node.kubernetes.io/windows-build: '10.0.20348'
tolerations:
- effect: NoSchedule
key: os
operator: Equal
value: "windows"
```
Une fois le Runtimeclass créé, attribuez-le en utilisant comme spécification sur le manifeste du Pod :
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: iis-2022
labels:
app: iis-2022
spec:
replicas: 1
template:
metadata:
name: iis-2022
labels:
app: iis-2022
spec:
runtimeClassName: windows-2022
containers:
- name: iis
```
## Support pour les groupes de nœuds gérés
Pour aider les clients à exécuter leurs applications Windows de manière plus rationalisée, AWS a lancé le support du [groupe de nœuds gérés (MNG) Amazon EKS pour les conteneurs Windows](https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-eks-automated-provisioning-lifecycle-management-windows-containers/) le 15 décembre 2022. Pour aider à aligner les équipes opérationnelles, les [MNG Windows sont](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) activés à l'aide des mêmes flux de travail et outils que les [MNG Linux](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html). Les versions complètes et principales de la famille AMI (Amazon Machine Image) de Windows Server 2019 et 2022 sont prises en charge.
Les familles d'AMI suivantes sont prises en charge pour les groupes de nœuds gérés (MNG).
| Famille AMI |
| --- |
| Windows\_Core\_2019\_x86\_64 |
| Windows\_Full\_2019\_x86\_64 |
| Windows\_Core\_2022\_x86\_64 |
| Windows\_Full\_2022\_x86\_64 |
## Documentations supplémentaires
Documentation officielle d'AWS : https://docs.aws.amazon.com/eks/latest/userguide/windows-support.html
Pour mieux comprendre le fonctionnement du Pod Networking (CNI), consultez le lien suivant : https://docs.aws.amazon.com/eks/latest/userguide/pod-networking.html
Blog AWS sur le déploiement d'un groupe de nœuds gérés pour Windows sur EKS : https://aws.amazon.com/blogs/containers/deploying-amazon-eks-windows-managed-node-groups/