**Aidez à améliorer cette page**
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.
Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien **Modifier cette page sur** qui se trouve dans le volet droit de chaque page.
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.
# Préparer le système d’exploitation pour les nœuds hybrides
Bottlerocket, Amazon Linux 2023 (AL2023), Ubuntu et RHEL sont validés en permanence pour être utilisés comme système d'exploitation de nœuds pour les nœuds hybrides. Bottlerocket est uniquement pris en charge dans les environnements AWS vSphere VMware . AL2Le 023 n'est pas couvert par les plans de AWS Support lorsqu'il est exécuté en dehors d'Amazon EC2. AL2Le 023 ne peut être utilisé que dans des environnements virtualisés sur site. Consultez le [guide de l'utilisateur Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/outside-ec2.html) pour plus d'informations. AWS prend en charge l'intégration des nœuds hybrides avec les systèmes d'exploitation Ubuntu et RHEL, mais ne fournit pas de support pour le système d'exploitation lui-même.
Vous êtes responsable de la mise à disposition et de la gestion du système d’exploitation. Lorsque vous testez des nœuds hybrides pour la première fois, il est plus simple d’exécuter la CLI des nœuds hybrides Amazon EKS (`nodeadm`) sur un hôte déjà provisionné. Pour les déploiements en production, nous vous recommandons d’inclure `nodeadm` dans vos images de système d’exploitation une configuration permettant leur exécution en tant que service systemd afin de joindre automatiquement les hôtes aux clusters Amazon EKS au démarrage de l’hôte. Si vous utilisez Bottlerocket comme système d’exploitation de nœud sur vSphere, vous n’avez pas besoin d’utiliser `nodeadm`, car Bottlerocket contient déjà les dépendances requises pour les nœuds hybrides et se connectera automatiquement au cluster que vous configurez au démarrage de l’hôte.
## Compatibilité des versions
Le tableau ci-dessous présente les versions de système d’exploitation compatibles et validées pour être utilisées comme système d’exploitation de nœud pour les nœuds hybrides. Si vous utilisez d'autres variantes ou versions de système d'exploitation qui ne sont pas incluses dans ce tableau, la compatibilité des nœuds hybrides avec la variante ou la version de votre système d'exploitation n'est pas couverte par le AWS Support. Les nœuds hybrides sont indépendants de l’infrastructure sous-jacente et prennent en charge les architectures x86 et ARM.
| Système d’exploitation | Versions |
| --- | --- |
| Amazon Linux | Amazon Linux 2023 (AL2023) |
| Flacon Rocket | Variantes v1.37.0 et supérieures exécutant Kubernetes v1.28 et VMware versions ultérieures |
| Ubuntu | Ubuntu 20.04, Ubuntu 22.04, Ubuntu 24.04 |
| Utilisation de Red Hat Enterprise Linux | RHEL 8, RHEL 9 |
## Considérations relatives au système d’exploitation
### Général
+ La CLI des nœuds hybrides Amazon EKS (`nodeadm`) peut être utilisée pour simplifier l’installation et la configuration des composants et des dépendances des nœuds hybrides. Vous pouvez exécuter le processus `nodeadm install` pendant la création des pipelines d’image de votre système d’exploitation ou au moment de l’exécution sur chaque hôte sur site. Pour plus d’informations sur les composants installés `nodeadm`, consultez le [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md).
+ Si vous utilisez un proxy dans votre environnement sur site pour accéder à Internet, une configuration supplémentaire du système d’exploitation est nécessaire pour les processus d’installation et de mise à niveau afin de configurer votre gestionnaire de paquets pour qu’il utilise le proxy. Pour obtenir des instructions, consultez [Configurer le proxy pour les nœuds hybrides](hybrid-nodes-proxy.md).
### Flacon Rocket
+ Les étapes et les outils nécessaires pour connecter un nœud Bottlerocket diffèrent de ceux utilisés pour les autres systèmes d’exploitation et sont décrits séparément dans [Connectez des nœuds hybrides avec Bottlerocket](hybrid-nodes-bottlerocket.md), plutôt que dans [Connecter les nœuds hybrides](hybrid-nodes-join.md).
+ Les étapes pour Bottlerocket n’utilisent pas la CLI des nœuds hybrides, `nodeadm`.
+ Seules les VMware variantes de la version v1.37.0 et supérieures de Bottlerocket sont prises en charge avec les nœuds hybrides EKS. VMware des variantes de Bottlerocket sont disponibles pour les versions v1.28 et supérieures de Kubernetes. Les [autres variantes de Bottlerocket](https://bottlerocket.dev/en/os/1.36.x/concepts/variants) ne sont pas prises en charge en tant que système d’exploitation des nœuds hybrides. REMARQUE : les VMware variantes de Bottlerocket ne sont disponibles que pour l'architecture x86\_64.
### Containerd
+ Containerd est l’exécution de conteneur Kubernetes standard et est une dépendance pour les nœuds hybrides, ainsi que pour tous les types de calcul de nœuds Amazon EKS. La CLI des nœuds hybrides Amazon EKS (`nodeadm`) tente d’installer containerd pendant le processus `nodeadm install`. Vous pouvez configurer l’installation de containerd lors de l’exécution `nodeadm install` à l’aide de l’option de ligne de commande `--containerd-source`. Les options valides sont `none`, `distro` et `docker`. Si vous utilisez RHEL, `distro` n’est pas une option valide. Vous pouvez soit configurer `nodeadm` pour installer la version de containerd à partir des référentiels Docker, soit installer containerd manuellement. Lorsque vous utilisez AL2 023 ou Ubuntu, installez `nodeadm` par défaut containerd à partir de la distribution du système d'exploitation. Si vous ne souhaitez pas que nodeadm installe containerd, utilisez l’option `--containerd-source none`.
### Ubuntu
+ Si vous utilisez Ubuntu 24.04, vous devrez peut-être mettre à jour votre version de containerd ou modifier AppArmor votre configuration pour adopter un correctif permettant aux pods de s'arrêter correctement, [voir](https://bugs.launchpad.net/ubuntu/+source/containerd-app/\+bug/2065423) Ubuntu \#2065423. Un redémarrage est nécessaire pour appliquer les modifications au AppArmor profil. La dernière version d’Ubuntu 24.04 dispose d’une version mise à jour de containerd dans son gestionnaire de paquets avec le correctif (containerd version 1.7.19\+).
### ARM
+ Si vous utilisez du matériel ARM, un processeur compatible ARMv8 .2 avec l'extension de cryptographie (ARMv8.2\+crypto) est requis pour exécuter les versions 1.31 et supérieures du module complémentaire EKS kube-proxy. Tous les systèmes Raspberry Pi antérieurs au Raspberry Pi 5, ainsi que les processeurs basés sur Cortex-A72, ne répondent pas à cette exigence. Comme solution de contournement, vous pouvez continuer à utiliser la version 1.30 du module complémentaire EKS kube-proxy jusqu’à la fin de son support étendu en juillet 2026 (voir le [calendrier des versions Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)), ou utiliser une image kube-proxy personnalisée provenant de l’amont.
+ Le message d’erreur suivant dans le journal kube-proxy indique cette incompatibilité :
```
Fatal glibc error: This version of Amazon Linux requires a newer ARM64 processor compliant with at least ARM architecture 8.2-a with Cryptographic extensions. On EC2 this is Graviton 2 or later.
```
## Création d’images du système d’exploitation
Amazon EKS fournit des [exemples de modèles Packer](https://github.com/aws/eks-hybrid/tree/main/example/packer) que vous pouvez utiliser pour créer des images de système d’exploitation qui incluent `nodeadm` et configurent Packer pour qu’il s’exécute au démarrage de l’hôte. Ce processus est recommandé pour éviter de tirer individuellement les dépendances des nœuds hybrides sur chaque hôte et pour automatiser le processus de démarrage des nœuds hybrides. Vous pouvez utiliser les modèles Packer fournis à titre d’exemple avec une image ISO Ubuntu 22.04, Ubuntu 24.04, RHEL 8 ou RHEL 9 et générer des images aux formats suivants : OVA, Qcow2 ou raw.
### Conditions préalables
Avant d’utiliser les modèles Packer fournis à titre d’exemple, vous devez avoir installé les éléments suivants sur la machine à partir de laquelle vous exécutez Packer.
+ Packer version 1.11.0 ou supérieure. Pour obtenir des instructions sur l’installation de Packer, consultez la section [Installer Packer](https://developer.hashicorp.com/packer/tutorials/docker-get-started/get-started-install-cli) dans la documentation Packer.
+ En cas de compilation OVAs, VMware vSphere plugin 1.4.0 ou version ultérieure
+ Si vous créez `Qcow2` ou des images brutes, utilisez le plug-in QEMU version 1.x.
### Définir les variables d'environnement
Avant d’exécuter la compilation Packer, définissez les variables d’environnement suivantes sur la machine à partir de laquelle vous exécutez Packer.
**Général**
Les variables d’environnement suivantes doivent être définies pour créer des images avec tous les systèmes d’exploitation et formats de sortie.
| Variable d’environnement | Type | Description |
| --- | --- | --- |
| PKR\_SSH\_PASSWORD | String | Packer utilise les variables `ssh_username` et `ssh_password` pour se connecter via SSH à la machine créée lors du provisionnement. Cela doit correspondre aux mots de passe utilisés pour créer l’utilisateur initial dans les fichiers kickstart ou user-data du système d’exploitation concerné. La valeur par défaut est définie comme « builder » ou « ubuntu » selon le système d’exploitation. Lorsque vous définissez votre mot de passe, veillez à le modifier dans le fichier `ks.cfg` ou `user-data` correspondant afin qu’il corresponde. |
| ISO\_URL | String | URL de l’ISO à utiliser. Peut être un lien Web pour télécharger depuis un serveur ou un chemin absolu vers un fichier local |
| ISO\_CHECKSUM | String | Somme de contrôle associée pour l’ISO fournie. |
| CREDENTIAL\_PROVIDER | String | Fournisseur d’informations d’identification pour les nœuds hybrides. Les valeurs valides sont `ssm` (par défaut) pour les activations hybrides SSM et `iam` pour Rôles Anywhere IAM |
| K8S\_VERSION | String | Version Kubernetes pour les nœuds hybrides (par exemple `1.31`). Pour connaître les versions Kubernetes prises en charge, consultez la page [Versions Amazon EKS prises en charge](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html). |
| NODEADM\_ARCH | String | Architecture pour `nodeadm install`. Sélectionnez `amd` ou `arm`. |
**RHEL**
Si vous utilisez RHEL, les variables d’environnement suivantes doivent être définies.
| Variable d’environnement | Type | Description |
| --- | --- | --- |
| RH\_USERNAME | String | Nom d’utilisateur du gestionnaire d’abonnement RHEL |
| RH\_PASSWORD | String | Mot de passe du gestionnaire d’abonnements RHEL |
| RHEL\_VERSION | String | Version Rhel iso utilisée. Les valeurs valides sont `8` ou `9`. |
**Ubuntu**
Aucune variable d’environnement spécifique à Ubuntu n’est requise.
**vSphere**
Si vous créez un VMware vSphere OVA, les variables d'environnement suivantes doivent être définies.
| Variable d’environnement | Type | Description |
| --- | --- | --- |
| VSPHERE\_SERVER | String | Adresse du serveur vSphere |
| VSPHERE\_USER | String | Nom d’utilisateur vSphere |
| VSPHERE\_PASSWORD | String | Mot de passe vSphere |
| VSPHERE\_DATACENTER | String | Nom du centre de données vSphere |
| VSPHERE\_CLUSTER | String | Nom du cluster vSphere |
| VSPHERE\_DATASTORE | String | Nom de l’entrepôt de données vSphere |
| VSPHERE\_NETWORK | String | Nom du réseau vSphere |
| VSPHERE\_OUTPUT\_FOLDER | String | Dossier de sortie vSphere pour les modèles |
**QEMU**
| Variable d’environnement | Type | Description |
| --- | --- | --- |
| PACKER\_OUTPUT\_FORMAT | String | Format de sortie pour le générateur QEMU. Les valeurs valides sont `qcow2` et `raw`. |
**Valider le modèle**
Avant d’exécuter votre build, validez votre modèle à l’aide de la commande suivante après avoir défini vos variables d’environnement. Remplacez `template.pkr.hcl` si vous utilisez un nom différent pour votre modèle.
```
packer validate template.pkr.hcl
```
### Créer des images
Créez vos images à l’aide des commandes suivantes et utilisez l’indicateur `-only` pour spécifier la cible et le système d’exploitation de vos images. Remplacez `template.pkr.hcl` si vous utilisez un autre nom pour votre modèle.
**vSphere OVAs**
**Note**
Si vous utilisez RHEL avec vSphere, vous devez convertir les fichiers Kickstart en une image OEMDRV et la transmettre sous forme d’ISO pour démarrer à partir de celle-ci. Pour plus d'informations, consultez le fichier [Packer Readme](https://github.com/aws/eks-hybrid/tree/main/example/packer#utilizing-rhel-with-vsphere) dans le référentiel EKS Hybrid Nodes GitHub .
**Ubuntu 22.04 OVA**
```
packer build -only=general-build.vsphere-iso.ubuntu22 template.pkr.hcl
```
**Ubuntu 24.04 OVA**
```
packer build -only=general-build.vsphere-iso.ubuntu24 template.pkr.hcl
```
**RHEL 8 OVA**
```
packer build -only=general-build.vsphere-iso.rhel8 template.pkr.hcl
```
**RHEL 9 OVA**
```
packer build -only=general-build.vsphere-iso.rhel9 template.pkr.hcl
```
**QEMU**
**Note**
Si vous créez une image pour un processeur hôte spécifique qui ne correspond pas à votre hôte de compilation, consultez la documentation [QEMU](https://www.qemu.org/docs/master/system/qemu-cpu-models.html) pour trouver le nom qui correspond à votre processeur hôte et utilisez l’indicateur `-cpu` avec le nom du processeur hôte lorsque vous exécutez les commandes suivantes.
**Ubuntu 22.04 Qcow2 / Raw**
```
packer build -only=general-build.qemu.ubuntu22 template.pkr.hcl
```
**Ubuntu 24.04 Qcow2 / Raw**
```
packer build -only=general-build.qemu.ubuntu24 template.pkr.hcl
```
**RHEL 8 Qcow2 / Raw**
```
packer build -only=general-build.qemu.rhel8 template.pkr.hcl
```
**RHEL 9 Qcow2 / Raw**
```
packer build -only=general-build.qemu.rhel9 template.pkr.hcl
```
### Transmettre la configuration nodeadm via les données utilisateur
Vous pouvez transmettre la configuration pour `nodeadm` dans vos données utilisateur via cloud-init afin de configurer et de connecter automatiquement les nœuds hybrides à votre cluster EKS au démarrage de l’hôte. Vous trouverez ci-dessous un exemple de la manière d'y parvenir lorsque vous utilisez VMware vSphere comme infrastructure pour vos nœuds hybrides.
1. Installez la `govc` CLI en suivant les instructions du [fichier readme govc](https://github.com/vmware/govmomi/blob/main/govc/README.md) on. GitHub
1. Après avoir exécuté la compilation Packer dans la section précédente et provisionné votre modèle, vous pouvez cloner votre modèle pour créer plusieurs nœuds différents à l’aide de la commande suivante. Vous devez cloner le modèle pour chaque nouvelle machine virtuelle que vous créez et qui sera utilisée pour les nœuds hybrides. Remplacez les variables dans la commande ci-dessous par les valeurs correspondant à votre environnement. La `VM_NAME` commande ci-dessous est utilisée comme vôtre `NODE_NAME` lorsque vous injectez les noms de votre VMs via votre `metadata.yaml` fichier.
```
govc vm.clone -vm "/PATH/TO/TEMPLATE" -ds="YOUR_DATASTORE" \
-on=false -template=false -folder=/FOLDER/TO/SAVE/VM "VM_NAME"
```
1. Après avoir cloné le modèle pour chacun de vos nouveaux modèles VMs, créez un `userdata.yaml` et `metadata.yaml` pour votre VMs. VMs Vous pouvez les partager `userdata.yaml` `metadata.yaml` et vous les remplirez par machine virtuelle en suivant les étapes ci-dessous. La configuration `nodeadm` est créée et définie dans la section `write_files` de votre `userdata.yaml`. L'exemple ci-dessous utilise les activations hybrides AWS SSM comme fournisseur d'informations d'identification sur site pour les nœuds hybrides. Pour plus d’informations sur la configuration `nodeadm`, consultez le [Référence des nœuds hybrides `nodeadm`](hybrid-nodes-nodeadm.md).
**userdata.yaml :**
```
#cloud-config
users:
- name: # username for login. Use 'builder' for RHEL or 'ubuntu' for Ubuntu.
passwd: # password to login. Default is 'builder' for RHEL.
groups: [adm, cdrom, dip, plugdev, lxd, sudo]
lock-passwd: false
sudo: ALL=(ALL) NOPASSWD:ALL
shell: /bin/bash
write_files:
- path: /usr/local/bin/nodeConfig.yaml
permissions: '0644'
content: |
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: # Cluster Name
region: # AWS region
hybrid:
ssm:
activationCode: # Your ssm activation code
activationId: # Your ssm activation id
runcmd:
- /usr/local/bin/nodeadm init -c file:///usr/local/bin/nodeConfig.yaml >> /var/log/nodeadm-init.log 2>&1
```
**métadonnées.yaml :**
Créez un `metadata.yaml` pour votre environnement. Conservez le format variable `"$NODE_NAME"` dans le fichier, car il sera rempli avec des valeurs lors d’une étape ultérieure.
```
instance-id: "$NODE_NAME"
local-hostname: "$NODE_NAME"
network:
version: 2
ethernets:
nics:
match:
name: ens*
dhcp4: yes
```
1. Ajoutez les fichiers `userdata.yaml` et `metadata.yaml` sous forme de chaînes `gzip+base64` à l’aide des commandes suivantes. Les commandes suivantes doivent être exécutées pour chacune des commandes VMs que vous créez. Remplacez `VM_NAME` par le nom de la machine virtuelle que vous mettez à jour.
```
export NODE_NAME="VM_NAME"
export USER_DATA=$(gzip -c9 metadata.yaml.tmp
export METADATA=$(gzip -c9