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

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.

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 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.
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.

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, 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 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 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 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), 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.

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 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.
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 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 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.

Installez la govc CLI en suivant les instructions du fichier readme govc on. 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. 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"
```

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.

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 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 <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 votre nouveau VMs, qui devrait 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