Compatibilité des versions Considérations relatives au système d’exploitation Création d’images du système d’exploitation

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 des nœuds hybrides. Bottlerocket est pris en charge par AWS uniquement dans les environnements VMware vSphere. AL2023 n’est pas couvert par les plans d’assistance AWS lorsqu’il est exécuté en dehors d’Amazon EC2. AL2023 ne peut être utilisé que dans des environnements virtualisés sur site. Pour plus d’informations, consultez le Guide de l’utilisateur Amazon Linux 2023. 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 du système d’exploitation qui ne figurent pas dans ce tableau, la compatibilité des nœuds hybrides avec votre variante ou version du système d’exploitation n’est pas couverte par l’assistance AWS. 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)
Bottlerocket	v1.37.0 et versions ultérieures Variantes VMware exécutant Kubernetes v1.28 et 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.
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.

Bottlerocket

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, plutôt que dans Connecter les nœuds hybrides.
Les étapes pour Bottlerocket n’utilisent pas la CLI des nœuds hybrides, nodeadm.
Seules les variantes VMware de Bottlerocket version v1.37.0 et supérieure sont prises en charge avec les nœuds hybrides EKS. Les variantes VMware de Bottlerocket sont disponibles pour les versions v1.28 et supérieures de Kubernetes. Les autres variantes de Bottlerocket ne sont pas prises en charge en tant que système d’exploitation des nœuds hybrides. REMARQUE : Les variantes VMware de Bottlerocket sont uniquement disponibles 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 AL2023 ou Ubuntu, l’installation nodeadm installe 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 votre configuration AppArmor afin d’adopter un correctif permettant aux pods de se terminer correctement, voir Ubuntu #2065423. Un redémarrage est nécessaire pour appliquer les modifications apportées au profil AppArmor. 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 cryptographique (ARMv8.2+crypto) est nécessaire pour exécuter la version 1.31 et les versions ulté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), 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 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.

Prérequis

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 dans la documentation Packer.
Si vous créez des OVA, VMware vSphere plug-in 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	Chaîne	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	Chaîne	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	Chaîne	Somme de contrôle associée pour l’ISO fournie.
CREDENTIAL_PROVIDER	Chaîne	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	Chaîne	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.
NODEADM_ARCH	Chaîne	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	Chaîne	Nom d’utilisateur du gestionnaire d’abonnement RHEL
RH_PASSWORD	Chaîne	Mot de passe du gestionnaire d’abonnements RHEL
RHEL_VERSION	Chaîne	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 fichier OVA VMware vSphere, les variables d’environnement suivantes doivent être définies.

Variable d’environnement	Type	Description
VSPHERE_SERVER	Chaîne	Adresse du serveur vSphere
VSPHERE_USER	Chaîne	Nom d’utilisateur vSphere
VSPHERE_PASSWORD	Chaîne	Mot de passe vSphere
VSPHERE_DATACENTER	Chaîne	Nom du centre de données vSphere
VSPHERE_CLUSTER	Chaîne	Nom du cluster vSphere
VSPHERE_DATASTORE	Chaîne	Nom de l’entrepôt de données vSphere
VSPHERE_NETWORK	Chaîne	Nom du réseau vSphere
VSPHERE_OUTPUT_FOLDER	Chaîne	Dossier de sortie vSphere pour les modèles

QEMU

Variable d’environnement	Type	Description
PACKER_OUTPUT_FORMAT	Chaîne	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.

OVA vSphere

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 Lisez-moi du packer dans le référentiel GitHub des nœuds hybrides EKS.

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 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 illustrant comment procéder lorsque vous utilisez VMware vSphere comme infrastructure pour vos nœuds hybrides.

Installez l’interface CLI govc en suivant les instructions fournies dans le fichier Lisez-moi de govc sur GitHub.
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. Le VM_NAME dans la commande ci-dessous est utilisé comme votre NODE_NAME lorsque vous injectez les noms de vos machines virtuelles via votre fichier metadata.yaml.
```
govc vm.clone -vm "/PATH/TO/TEMPLATE" -ds="YOUR_DATASTORE" \
    -on=false -template=false -folder=/FOLDER/TO/SAVE/VM "VM_NAME"
```

Après avoir cloné le modèle pour chacune de vos nouvelles machines virtuelles, créez un userdata.yaml et un metadata.yaml pour vos machines virtuelles. Vos machines virtuelles peuvent partager les mêmes userdata.yaml et metadata.yaml, que vous renseignerez pour chacune d’entre elles dans 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 SSM AWS 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.

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

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 machines virtuelles 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 <userdata.yaml | base64)

govc vm.change -dc="YOUR_DATASTORE" -vm "$NODE_NAME" -e guestinfo.userdata="${USER_DATA}"
govc vm.change -dc="YOUR_DATASTORE" -vm "$NODE_NAME" -e guestinfo.userdata.encoding=gzip+base64

envsubst '$NODE_NAME' < metadata.yaml > metadata.yaml.tmp
export METADATA=$(gzip -c9 <metadata.yaml.tmp | base64)

govc vm.change -dc="YOUR_DATASTORE" -vm "$NODE_NAME" -e guestinfo.metadata="${METADATA}"
govc vm.change -dc="YOUR_DATASTORE" -vm "$NODE_NAME" -e guestinfo.metadata.encoding=gzip+base64

Allumez vos nouvelles machines virtuelles, qui devraient se connecter automatiquement au cluster EKS que vous avez configuré.
```
govc vm.power -on "${NODE_NAME}"
```

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Préparez votre réseau

Préparation des informations d’identification