**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.
# Créez des nœuds avec Amazon Linux optimisé AMIs
Amazon Elastic Kubernetes Service (Amazon EKS) fournit des AMIs images Amazon Machine () spécialisées optimisées pour exécuter des nœuds de travail Kubernetes. Ces Amazon Linux (AL) optimisés pour EKS AMIs sont préconfigurés avec des composants essentiels, tels que l'AWS `kubelet` IAM Authenticator et, pour garantir une intégration et une sécurité sans faille au sein de vos clusters. `containerd` Ce guide détaille les versions d'AMI disponibles et décrit les options spécialisées pour le calcul accéléré et les architectures basées sur ARM.
## Considérations
+ Vous pouvez suivre les événements liés à la sécurité ou à la confidentialité pourAmazon Linux dans le [centre de sécurité Amazon Linux](https://alas.aws.amazon.com/) en sélectionnant l’onglet correspondant à la version souhaitée. Vous pouvez également vous abonner au flux RSS applicable. Les événements de sécurité et de confidentialité incluent une présentation du problème, les packages concernés et la manière de mettre à jour vos instances pour résoudre le problème.
+ Avant de déployer une AMI accélérée ou une AMI Arm, consultez les informations contenues dans [Amazon Linux AMIs accéléré optimisé pour Amazon EKS](#gpu-ami) et. [Arm optimisé pour Amazon EKS \$1 Amazon Linux AMIs](#arm-ami)
+ Les EC2 `P2` instances Amazon ne sont pas prises en charge sur Amazon EKS car elles nécessitent la version 470 ou antérieure du `NVIDIA` pilote.
+ Tous les groupes de nœuds gérés nouvellement créés dans des clusters de la version `1.30` ou d'une version plus récente utiliseront automatiquement par défaut AL2 023 comme système d'exploitation du nœud.
## Amazon Linux accéléré optimisé pour Amazon EKS AMIs
Amazon Linux (AL) AMIs accéléré optimisé pour Amazon EKS repose sur le système Amazon Linux standard optimisé pour EKS. AMIs Ils sont configurés pour servir d’images optionnelles pour les nœuds Amazon EKS afin de prendre en charge les charges de travail basées sur GPU, [Inferentia](https://aws.amazon.com/machine-learning/inferentia/) et [Trainium](https://aws.amazon.com/machine-learning/trainium/).
Pour de plus amples informations, veuillez consulter [Utiliser l'accélérateur optimisé pour EKS AMIs pour les instances GPU](ml-eks-optimized-ami.md).
## Arm optimisé pour Amazon EKS \$1 Amazon Linux AMIs
Les instances Arm apportent des économies significatives en termes de coût et sont bien adaptées aux applications dimensionnables et basées sur Arm, telles que serveurs web, microservices conteneurisés, flottes de cache et magasins de données distribuées. Lorsque vous ajoutez des nœuds Arm à votre cluster, passez en revue les considérations suivantes.
+ Si votre cluster a été déployé avant le 17 août 2020, vous devez effectuer une mise à niveau unique des manifestes des modules complémentaires critiques du cluster. Ceci afin que Kubernetes puisse extraire l'image correcte pour chaque architecture matérielle utilisée dans votre cluster. Pour plus d'informations sur la mise à jour des modules complémentaires de clusters, consultez [Étape 1 : préparer la mise à niveau](update-cluster.md#update-existing-cluster). Si vous avez déployé votre cluster à partir du 17 août 2020, vos modules complémentaires CoreDNS, `kube-proxy` et le plug-in CNI Amazon VPC pour Kubernetes sont déjà compatibles avec plusieurs architectures.
+ Les applications déployées sur les nœuds Arm doivent être compilées pour Arm.
+ Si vous en avez DaemonSets déployé dans un cluster existant, ou si vous souhaitez les déployer sur un nouveau cluster dans lequel vous souhaitez également déployer des nœuds Arm, vérifiez que vous DaemonSet pouvez les exécuter sur toutes les architectures matérielles de votre cluster.
+ Vous pouvez exécuter des groupes de nœuds Arm et des groupes de nœuds x86 dans le même cluster. Si vous procédez de la sorte, envisagez de déployer des images de conteneur multi-architecture dans un registre de conteneurs tel qu’Amazon Elastic Container Registry, puis d’ajouter des sélecteurs de nœuds à vos manifestes afin que Kubernetes connaisse l’architecture matérielle dans laquelle un pod peut être déployé. Pour de plus amples informations, consultez [Transmission d'une image multi-architecture](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-multi-architecture-image.html) dans le *Guide de l'utilisateur Amazon ECR* et l'article de blog [Présentation d'images de conteneurs multi-architectures pour Amazon ECR](https://aws.amazon.com/blogs/containers/introducing-multi-architecture-container-images-for-amazon-ecr).
## En savoir plus
Pour plus d'informations sur l'utilisation d'Amazon Linux optimisé pour Amazon EKS AMIs, consultez les sections suivantes :
+ Pour utiliser Amazon Linux avec des groupes de nœuds gérés, veuillez consulter la rubrique [Simplifiez le cycle de vie des nœuds avec des groupes de nœuds gérés](managed-node-groups.md).
+ Pour lancer des nœuds Amazon Linux autogérés, veuillez consulter la rubrique [Récupérez l'AMI Amazon Linux recommandée IDs](retrieve-ami-id.md).
+ Pour plus d'informations sur la version, consultez [Récupérer les informations sur la version Amazon Linux AMI](eks-linux-ami-versions.md).
+ Pour accéder à la dernière version IDs d'Amazon Linux optimisée pour Amazon EKS AMIs, consultez. [Récupérez l'AMI Amazon Linux recommandée IDs](retrieve-ami-id.md)
+ Pour les scripts open source utilisés pour créer l'Amazon EKS optimisé, consultez AMIs. [Créez une AMI Amazon Linux personnalisée optimisée pour EKS](eks-ami-build-scripts.md)
# Mise à niveau d’Amazon Linux 2 vers Amazon Linux 2023
**Avertissement**
Amazon EKS a cessé de publier Amazon Linux 2 (AL2) optimisé pour EKS AMIs le 26 novembre 2025. AL2023 et Bottlerocket basés sur AMIs Amazon EKS sont disponibles pour toutes les versions de Kubernetes prises en charge, y compris les versions 1.33 et supérieures.
AL2023 est un système d'exploitation basé sur Linux conçu pour fournir un environnement sécurisé, stable et performant pour vos applications cloud. Il s’agit de la nouvelle génération d’Amazon Linux proposée par Amazon Web Services et est disponible pour toutes les versions Amazon EKS prises en charge.
AL2023 propose plusieurs améliorations par rapport à AL2. Pour une comparaison complète, consultez [Comparing AL2 et Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) dans le *guide de l'utilisateur Amazon Linux 2023*. Plusieurs packages ont été ajoutés, mis à niveau et supprimés AL2. Il est vivement recommandé de tester vos applications AL2023 avant de procéder à la mise à niveau. Pour obtenir la liste de toutes les modifications apportées aux packages AL2023, consultez la section [Modifications de package dans Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/release-notes/compare-packages.html) dans les *notes de mise à jour d'Amazon Linux 2023*.
En plus de ces modifications, prenez en compte les éléments suivants :
+ AL2023 introduit un nouveau processus d'initialisation des nœuds `nodeadm` qui utilise un schéma de configuration YAML. Si vous utilisez des groupes de nœuds autogérés ou une AMI avec un modèle de lancement, vous devez désormais fournir explicitement des métadonnées de cluster supplémentaires lors de la création d’un nouveau groupe de nœuds. Un [exemple](https://awslabs.github.io/amazon-eks-ami/nodeadm/) des paramètres minimum requis est présenté ci-dessous, où `apiServerEndpoint`, `certificateAuthority` et le service `cidr` sont désormais obligatoires :
```
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
```
Dans AL2, les métadonnées de ces paramètres ont été découvertes à partir de l'appel d'`DescribeCluster`API Amazon EKS. Avec AL2023, ce comportement a changé car l'appel d'API supplémentaire risque d'être limité lors de la mise à l'échelle de nœuds à grande échelle. Cette modification ne vous affecte pas si vous utilisez des groupes de nœuds gérés sans modèle de lancement, ou si vous utilisez Karpenter. Pour plus d’informations sur `certificateAuthority` et le service `cidr`, consultez [https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html) dans la *Référence de l’API Amazon EKS*.
+ Pour AL2023, modifie `nodeadm` également le format pour appliquer des paramètres à chaque nœud utilisant [https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec). `kubelet` En AL2, cela a été fait avec le `--kubelet-extra-args` paramètre. Ceci est couramment utilisé pour ajouter des étiquettes et des rejets aux nœuds. L’exemple ci-dessous illustre l’application de `maxPods` et `--node-labels` sur le nœud.
```
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: test-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
kubelet:
config:
maxPods: 110
flags:
- --node-labels=karpenter.sh/capacity-type=on-demand,karpenter.sh/nodepool=test
```
+ La version CNI d'Amazon VPC `1.16.2` ou supérieure est requise pour. AL2023
+ AL2023 nécessite `IMDSv2` par défaut. `IMDSv2`présente plusieurs avantages qui contribuent à améliorer la posture de sécurité. Il utilise une méthode d’authentification orientée session qui nécessite la création d’un jeton secret dans une simple requête HTTP PUT pour démarrer la session. La durée de validité du jeton de session peut avoir une valeur quelconque entre 1 seconde et 6 heures. Pour plus d'informations sur la manière de passer de `IMDSv1` à`IMDSv2`, consultez [Transition vers l'utilisation du service de métadonnées d'instance version 2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html) et [Profitez pleinement des avantages de votre AWS infrastructure IMDSv2 et désactivez-la IMDSv1 dans l'ensemble de celle-ci](https://aws.amazon.com/blogs/security/get-the-full-benefits-of-imdsv2-and-disable-imdsv1-across-your-aws-infrastructure). Si vous souhaitez continuer à utiliser `IMDSv1`, vous pouvez le faire en surchargant manuellement les paramètres via les propriétés de lancement de l’instance.
**Note**
Pour `IMDSv2` with AL2023, le nombre de sauts par défaut pour les groupes de nœuds gérés peut varier :
Lorsque vous n’utilisez pas de modèle de lancement, la valeur par défaut est définie sur `1`. Cela signifie que les conteneurs n’auront pas accès aux informations d’identification du nœud via IMDS. Si vous avez besoin d’un accès par conteneur aux informations d’identification du nœud, vous pouvez toujours le faire en utilisant un [modèle de lancement Amazon EC2 personnalisé](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-launchtemplate-metadataoptions.html).
Lorsque vous utilisez un AMI personnalisée dans un modèle de lancement, la valeur `HttpPutResponseHopLimit` par défaut est définie sur `2`. Vous pouvez modifier manuellement `HttpPutResponseHopLimit` dans le modèle de lancement.
Vous pouvez également utiliser [Identité du pod Amazon EKS](pod-identities.md) pour fournir des informations d’identification, plutôt que d’utiliser `IMDSv2`.
+ AL2023 propose la nouvelle génération de hiérarchie unifiée des groupes de contrôle (`cgroupv2`). `cgroupv2`est utilisé pour implémenter un environnement d'exécution de conteneur, et par`systemd`. Bien qu'elle contienne AL2023 toujours du code permettant au système de fonctionner`cgroupv1`, cette configuration n'est ni recommandée ni prise en charge. Cette configuration sera complètement supprimée dans une prochaine version majeure d’Amazon Linux.
+ `eksctl`une version `0.176.0` ou supérieure est requise `eksctl` pour le support AL2023.
Pour les groupes de nœuds gérés existants, vous pouvez effectuer une mise à niveau sur place ou une mise à blue/green niveau en fonction de la manière dont vous utilisez un modèle de lancement :
+ Si vous utilisez une AMI personnalisée avec un groupe de nœuds gérés, vous pouvez effectuer une mise à niveau sur place en remplaçant l’ID de l’AMI dans le modèle de lancement. Vous devez vous assurer que vos applications et toutes les données utilisateur sont transférées vers le AL2023 premier avant de mettre en œuvre cette stratégie de mise à niveau.
+ Si vous utilisez des groupes de nœuds gérés avec le modèle de lancement standard ou avec un modèle de lancement personnalisé qui ne précise pas l'ID de l'AMI, vous devez effectuer une mise à niveau à l'aide d'une blue/green stratégie. Une blue/green mise à niveau est généralement plus complexe et implique la création d'un tout nouveau groupe de nœuds dans lequel vous devez spécifier AL2023 le type d'AMI. Le nouveau groupe de nœuds devra ensuite être configuré avec soin pour garantir que toutes les données personnalisées du groupe de AL2 nœuds sont compatibles avec le nouveau système d'exploitation. Une fois le nouveau groupe de nœuds testé et validé avec vos applications, vous pouvez migrer les pods de l’ancien groupe vers le nouveau. Après la migration, vous pouvez supprimer l’ancien groupe de nœuds.
Si vous utilisez Karpenter et que vous souhaitez l'utiliser AL2023, vous devez modifier le `EC2NodeClass` `amiFamily` champ avec AL2023. Par défaut, la fonction de dérive est activée dans Karpenter. Cela signifie qu’une fois le champ `amiFamily` modifié, Karpenter mettra automatiquement à jour vos composants master avec la dernière AMI lorsqu’elle sera disponible.
## Informations supplémentaires sur nodeadm
Lorsque vous utilisez une AMI Amazon Linux 2023 optimisée pour EKS ou que vous créez une AMI EKS Amazon Linux 2023 personnalisée via les scripts Packer fournis dans le amazon-eks-ami GitHub référentiel officiel, vous devez éviter d'exécuter explicitement nodeadm init dans les données utilisateur EC2 ou dans le cadre de votre AMI personnalisée.
Si vous souhaitez générer une dynamique NodeConfig dans vos données utilisateur, vous pouvez écrire cette configuration dans un fichier yaml ou json intégré. `/etc/eks/nodeadm.d` Ces fichiers de configuration seront fusionnés et appliqués à votre nœud lorsque nodeadm init sera automatiquement lancé ultérieurement dans le processus de démarrage. Par exemple :
```
cat > /etc/eks/nodeadm.d/additional-node-labels.yaml << EOF
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
kubelet:
flags:
- --node-labels=foo=bar
EOF
```
Amazon Linux 2023, optimisé pour EKS, exécute AMIs automatiquement nodeadm init en deux phases via des services systemd distincts : nodeadm-config s'exécute avant l'exécution des données utilisateur, tandis que nodeadm-run s'exécute ensuite. Le service nodeadm-config établit des configurations de base pour containerd et kubelet avant l'exécution des données utilisateur. Le service nodeadm-run exécute certains démons du système et effectue toutes les configurations finales après l'exécution des données utilisateur. Si la commande nodeadm init est exécutée une fois de plus, via les données utilisateur ou une AMI personnalisée, elle risque de briser les hypothèses concernant l'ordre d'exécution et d'entraîner des résultats inattendus, notamment des erreurs de configuration. ENIs
# Récupérer les informations sur la version Amazon Linux AMI
Les AMI optimisées par Amazon EKS Linux sont versionnées par la version Kubernetes et la date de sortie de l’AMI dans le format suivant :
```
k8s_major_version.k8s_minor_version.k8s_patch_version-release_date
```
Chaque version AMI comprend différentes versions de [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/), du noyau Linux et de [containerd](https://containerd.io/). Les AMI accélérées comprennent également différentes versions du pilote NVIDIA. Vous trouverez ces informations sur la version dans le [journal des modifications](https://github.com/awslabs/amazon-eks-ami/blob/main/CHANGELOG.md) sur GitHub.
# Récupérez l'AMI Amazon Linux recommandée IDs
Lors du déploiement de nœuds, vous pouvez spécifier un identifiant pour une image Amazon Machine Image (AMI) optimisée pour Amazon EKS pré-créée. Pour récupérer un ID d'AMI correspondant à la configuration souhaitée, interrogez l'API du magasin de paramètres AWS Systems Manager. L'utilisation de cette API élimine le besoin de rechercher manuellement l'AMI optimisée pour Amazon EKS IDs. Pour de plus amples informations, veuillez consulter [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html). Le [principal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que vous utilisez doit disposer de l'autorisation IAM `ssm:GetParameter` pour récupérer les métadonnées de l'AMI optimisée pour Amazon EKS.
Vous pouvez récupérer l’ID d’image de la dernière AMI Amazon Linux optimisée pour Amazon EKS recommandée à l’aide de la commande suivante, qui utilise le sous-paramètre `image_id`. Si nécessaire, apportez les modifications suivantes à la commande, puis exécutez la commande modifiée :
+ Veuillez remplacer `` par une [version prise en charge par Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ *ami-type*Remplacez-le par l'une des options suivantes. Pour plus d'informations sur les types d' EC2 instances Amazon, consultez la section [Types d' EC2 instances Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html).
+ *amazon-linux-2023/x86\$164/standard*À utiliser pour les instances `x86` basées sur Amazon Linux 2023 (AL2023).
+ *amazon-linux-2023/arm64/standard*À utiliser pour AL2 023 instances ARM, telles que les instances basées sur [AWS Graviton](https://aws.amazon.com/ec2/graviton/).
+ *amazon-linux-2023/x86\$164/nvidia*À utiliser pour les dernières instances NVIDIA AL2 `x86` 023 approuvées.
+ *amazon-linux-2023/arm64/nvidia*À utiliser pour les dernières instances NVIDIA AL2 `arm64` 023 approuvées.
+ *amazon-linux-2023/x86\$164/neuron*À utiliser pour les dernières instances AL2 023 [AWS Neuron](https://aws.amazon.com/machine-learning/neuron/).
+ ``Remplacez-le par une [AWS région prise en charge par Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) pour laquelle vous souhaitez obtenir l'ID AMI.
```
aws ssm get-parameter --name /aws/service/eks/optimized-ami///recommended/image_id \
--region --query "Parameter.Value" --output text
```
Voici un exemple de commande après remplacement des espaces réservés.
```
aws ssm get-parameter --name /aws/service/eks/optimized-ami/1.31/amazon-linux-2023/x86_64/standard/recommended/image_id \
--region us-west-2 --query "Parameter.Value" --output text
```
L'exemple qui suit illustre un résultat.
```
ami-1234567890abcdef0
```
# Créez une AMI Amazon Linux personnalisée optimisée pour EKS
**Avertissement**
Amazon EKS a cessé de publier Amazon Linux 2 (AL2) optimisé pour EKS AMIs le 26 novembre 2025. AL2Les versions 023 et Bottlerocket pour AMIs Amazon EKS sont disponibles pour toutes les versions de Kubernetes prises en charge, y compris les versions 1.33 et supérieures.
Amazon EKS fournit des scripts de génération open source dans le référentiel [Amazon EKS AMI Build Specification](https://github.com/awslabs/amazon-eks-ami) que vous pouvez utiliser pour consulter les configurations, le moteur d'exécution`kubelet`, l'authentificateur AWS IAM pour Kubernetes et créer votre propre AMI basée sur AL à partir de zéro.
Ce dépôt contient le [script bootstrap](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) spécialisé AL2 et l'[outil nodeadm pour AL2 023](https://awslabs.github.io/amazon-eks-ami/nodeadm/) qui s'exécute au démarrage. Ces scripts configurent les données de certificat de votre instance, le point de terminaison du plan de contrôle, le nom du cluster, et bien plus encore. Les scripts sont considérés comme la source de vérité pour les versions d'AMI optimisées pour Amazon EKS. Vous pouvez donc suivre le GitHub référentiel pour suivre les modifications apportées à notre. AMIs
Lors de la création personnalisée AMIs avec l'EKS Optimized AMIs comme base, il n'est pas recommandé ou pris en charge d'exécuter une mise à niveau du système d'exploitation (par ex. `dnf upgrade`) ou mettez à niveau l'un des packages Kubernetes ou GPU inclus dans l'EKS Optimized AMIs, car cela risque de compromettre la compatibilité des composants. Si vous mettez à niveau le système d'exploitation ou les packages inclus dans l'EKS Optimized AMIs, il est recommandé de procéder à des tests approfondis dans un environnement de développement ou de préparation avant le déploiement en production.
Lors de la création d'instances personnalisées AMIs pour le GPU, il est recommandé de créer une AMIs configuration personnalisée distincte pour chaque génération et famille d'instances que vous allez exécuter. L'accélérateur optimisé pour EKS installe de AMIs manière sélective les pilotes et les packages au moment de l'exécution en fonction de la génération et de la famille du type d'instance sous-jacent. Pour plus d'informations, consultez les scripts EKS AMI pour [l'installation et l'](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2023/provisioners/install-nvidia-driver.sh)[exécution](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2023/runtime/gpu/nvidia-kmod-load.sh).
## Conditions préalables
+ [Installation de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)
+ [Installez HashiCorp Packer v1.9.4\$1](https://developer.hashicorp.com/packer/downloads)
+ [Installez GNU Make](https://www.gnu.org/software/make/)
## Démarrage rapide
Ce guide de démarrage rapide vous montre les commandes permettant de créer une AMI personnalisée dans votre AWS compte. Pour en savoir plus sur les configurations disponibles pour personnaliser votre AMI, consultez les variables de modèle sur la page [Amazon Linux 2023](https://awslabs.github.io/amazon-eks-ami/usage/al2023/).
### Conditions préalables
Installez le [plug-in Amazon](https://developer.hashicorp.com/packer/integrations/hashicorp/amazon) requis. Par exemple :
```
packer plugins install github.com/hashicorp/amazon
```
### Étape 1. Configurez votre environnement
Clonez ou créez une fourche du référentiel AMI officiel d’Amazon EKS. Par exemple :
```
git clone https://github.com/awslabs/amazon-eks-ami.git
cd amazon-eks-ami
```
Vérifiez que Packer est installé :
```
packer --version
```
### Étape 2. Pour créer une AMI personnalisée
Vous trouverez ci-dessous des exemples de commandes pour différentes commandes personnalisées AMIs.
** AL2 AMI NVIDIA de base :**
```
make k8s=1.31 os_distro=al2 \
enable_accelerator=nvidia \
nvidia_driver_major_version=560 \
enable_efa=true
```
**AMI NVIDIA AL2 023 de base :**
```
make k8s=1.31 os_distro=al2023 \
enable_accelerator=nvidia \
nvidia_driver_major_version=560 \
enable_efa=true
```
**AMI Neuron AL2 023 conforme aux STIG :**
```
make k8s=1.31 os_distro=al2023 \
enable_accelerator=neuron \
enable_fips=true \
source_ami_id=ami-0abcd1234efgh5678 \
kms_key_id=alias/aws-stig
```
Après avoir exécuté ces commandes, Packer effectuera les opérations suivantes :\$1 Lancer une EC2 instance Amazon temporaire. \$1 Installez les composants, les pilotes et les configurations de Kubernetes. \$1 Créez l'AMI dans votre AWS compte.
Le résultat attendu devrait ressembler à ceci :
```
==> Wait completed after 8 minutes 42 seconds
==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:
us-west-2: ami-0e139a4b1a7a9a3e9
--> amazon-ebs: AMIs were created:
us-west-2: ami-0e139a4b1a7a9a3e9
--> amazon-ebs: AMIs were created:
us-west-2: ami-0e139a4b1a7a9a3e9
```
### Étape 3. Afficher les valeurs par défaut
Pour afficher les valeurs par défaut et les options supplémentaires, exécutez la commande suivante :
```
make help
```