AMI Amazon Linux optimisées pour Amazon EKS - Amazon EKS

Aidez à améliorer cette page

Vous souhaitez contribuer à ce guide de l'utilisateur ? Faites défiler cette page vers le bas et sélectionnez Modifier cette page sur GitHub. Vos contributions aideront à améliorer notre guide de l'utilisateur pour tout le monde.

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.

AMI Amazon Linux optimisées pour Amazon EKS

L'AMI Amazon Linux optimisée pour Amazon EKS repose sur Amazon Linux 2 (AL2) et Amazon Linux 2023 (AL2023). Elle est configurée pour servir d'image de base pour les nœuds Amazon EKS. L'AMI est configurée pour fonctionner avec Amazon EKS et elle comprend les composants suivants :

  • kubelet

  • AWS Authentificateur IAM

  • Docker (Version Amazon EKS 1.23 et version antérieure)

  • containerd

Note
  • Vous pouvez suivre les événements liés à la sécurité ou à la confidentialité d'AL2 dans le centre de sécurité Amazon Linux ou vous abonner au flux RSS associé. 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 Arm, consultez les informations se trouvant dans AMI Amazon Linux accélérée optimisée pour Amazon EKS et AMI Amazon Linux Arm optimisées pour Amazon EKS.

  • Pour Kubernetes la version1.23, vous pouvez utiliser un indicateur bootstrap facultatif pour tester la migration de Docker verscontainerd. Pour plus d’informations, consultez Testez la migration Docker de containerd.

  • À partir de Kubernetes version 1.25, vous ne pourrez plus utiliser les instances P2 Amazon EC2 avec les instances AMI Amazon Linux accélérées et optimisées pour Amazon EKS prêtes à l’emploi. Ces AMI pour Kubernetes 1.25 ou les versions ultérieures prendront en charge les pilotes de la série NVIDIA 525 ou ultérieurs, qui sont incompatibles avec les instances P2. Toutefois, les pilotes de la série NVIDIA 525 ou ultérieurs sont compatibles avec les instances P3, P4 et P5, ce qui vous permet d’utiliser ces instances avec les AMI pour Kubernetes 1.25 ou une version ultérieure. Avant de mettre à niveau vos clusters Amazon EKS vers la version 1.25, migrez toutes les instances P2 vers les instances P3, P4 et P5. Vous devez également mettre à jour vos applications de manière proactive pour qu'elles fonctionnent avec les pilotes de la série NVIDIA 525 ou d'une série ultérieure. Nous prévoyons de rétroporter les nouvelles NVIDIA 525 séries ou les pilotes ultérieurs vers des Kubernetes versions ultérieures 1.23 et 1.24 ce, fin janvier 2024.

  • À partir de la version Amazon EKS 1.30 ou d'une version plus récente, tous les groupes de nœuds gérés nouvellement créés utiliseront automatiquement par défaut AL2023 comme système d'exploitation des nœuds. Auparavant, les nouveaux groupes de nœuds étaient définis par défaut sur AL2. Vous pouvez continuer à utiliser AL2 en le choisissant comme type d'AMI lors de la création d'un nouveau groupe de nœuds.

  • Support pour AL2 expirera le 30 juin 2025. Pour plus d'informations, consultez FAQ sur Amazon Linux 2.

Mise à niveau de AL2 à AL2023

L'AMI optimisée pour Amazon EKS est disponible en deux familles basées sur AL2 et AL2023. AL2023 est un nouveau 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 d'Amazon Web Services. Elle est disponible dans toutes les versions prises en charge d'Amazon EKS, y compris les versions 1.23 et 1.24 dans le cadre d'un support étendu. Les AMI accélérées Amazon EKS basées sur AL2023 seront disponibles ultérieurement. Si vous avez des charges de travail accélérées, vous devez continuer à utiliser l'AMI accélérée AL2 ou Bottlerocket.

AL2023 offre plusieurs améliorations par rapport à AL2. Pour une comparaison complète, consultez la section Comparaison entre AL2 et Amazon Linux 2023 dans le guide de l'utilisateur Amazon Linux 2023. Plusieurs packages ont été ajoutés, mis à niveau et supprimés d'AL2. Il est fortement recommandé de tester vos applications avec AL2023 avant de procéder à la mise à niveau. Pour obtenir la liste de toutes les modifications apportées aux packages dans AL2023, consultez la section Modifications apportées aux packages dans Amazon Linux 2023 dans les notes de mise à jour d'Amazon Linux 2023.

Outre ces modifications, vous devez être conscient de ce qui suit :

  • 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 des métadonnées de cluster supplémentaires de manière explicite lors de la création d'un nouveau groupe de nœuds. Voici un exemple des paramètres minimaux requis, où apiServerEndpointcertificateAuthority, et le service cidr sont désormais requis :

    --- 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'DescribeClusterAPI 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 concerne pas si vous utilisez des groupes de nœuds gérés sans modèle de lancement ou si vous utilisezKarpenter. Pour plus d'informations sur les services certificateAuthority et les servicescidr, consultez DescribeCluster le manuel Amazon EKS API Reference.

  • Dockern'est pas pris en charge dans AL2023 pour toutes les versions d'Amazon EKS prises en charge. Support pour Docker a pris fin et a été supprimé avec la version Amazon EKS 1.24 ou supérieure dans AL2. Pour plus d'informations sur la dépréciation, consultez Amazon EKS a mis fin au support de. Dockershim

  • La version CNI d'Amazon VPC 1.16.2 ou supérieure est requise pour AL2023.

  • AL2023 nécessite IMDSv2 par défaut. IMDSv2pré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. Le jeton d'une session peut être valide 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 et Profitez de tous les avantages d'IMDSv2 et désactivez IMDSv1 dans votre infrastructure. AWS Si vous souhaitez l'utiliserIMDSv1, vous pouvez toujours le faire en remplaçant manuellement les paramètres à l'aide des propriétés de lancement de l'option de métadonnées de l'instance.

    Note

    En effetIMDSv2, le nombre de sauts par défaut pour les groupes de nœuds gérés est défini 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 les remplaçant manuellement HttpPutResponseHopLimit dans un modèle de lancement Amazon EC2 personnalisé, en le portant à 2. Vous pouvez également utiliser Amazon EKS Pod Identity pour fournir des informations d'identification au lieu deIMDSv2.

  • L'AL2023 propose la prochaine génération de hiérarchie unifiée des groupes de contrôle (cgroupv2). cgroupv2est utilisé pour implémenter un environnement d'exécution de conteneur, et parsystemd. Bien que l'AL2023 inclue toujours du code permettant au système de fonctionner en utilisantcgroupv1, cette configuration n'est ni recommandée ni prise en charge. Cette configuration sera complètement supprimée dans une future version majeure d'Amazon Linux.

  • eksctlune version 0.176.0 ou supérieure est requise pour eksctl prendre en charge AL2023.

Pour les groupes de nœuds gérés existants, vous pouvez effectuer une mise à niveau sur place ou une mise à niveau bleu/vert selon 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 échangeant l'ID de l'AMI dans le modèle de lancement. Vous devez d'abord vous assurer que vos applications et toutes les données utilisateur sont transférées vers AL2023 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 la mise à niveau en utilisant une stratégie bleu/vert. Une mise à niveau bleu/vert 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 comme 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 nœuds AL2 sont compatibles avec le nouveau système d'exploitation. Une fois que le nouveau groupe de nœuds a été testé et validé avec vos applications, il Pods peut être migré de l'ancien groupe de nœuds vers le nouveau groupe de nœuds. Une fois la migration terminée, vous pouvez supprimer l'ancien groupe de nœuds.

Si vous utilisez Karpenter et souhaitez utiliser AL2023, vous devez modifier le EC2NodeClass amiFamily champ avec AL2023. Par défaut, Drift est activé dansKarpenter. Cela signifie qu'une fois le amiFamily champ modifié, vos nœuds de travail Karpenter seront automatiquement mis à jour avec la dernière AMI lorsqu'elle sera disponible.

AMI Amazon Linux accélérée optimisée pour Amazon EKS

Note

Les AMI accélérées Amazon EKS basées sur AL2023 seront disponibles ultérieurement. Si vous avez des charges de travail accélérées, vous devez continuer à utiliser l'AMI accélérée AL2 ou. Bottlerocket

L'AMI Amazon Linux accéléré optimisé pour Amazon EKS est construit sur l'AMI Amazon Linux standard optimisé pour Amazon EKS. Elle est configurée pour servir d'image facultative aux nœuds Amazon EKS afin de prendre en charge les charges de travail basées sur le GPU, Inferentia et Trainium.

Outre la configuration de l'AMI standard optimisée pour Amazon EKS, l'AMI accélérée inclut les éléments suivants :

  • Pilotes NVIDIA

  • L'environnement d'exécution nvidia-container-runtime (par défaut)

  • AWS Neurontemps d'exécution du conteneur

Pour obtenir la liste des derniers composants inclus dans l'AMI accélérée, consultez les amazon-eks-ami versions duGitHub.

Note
  • L'AMI accélérée optimisée pour Amazon EKS ne prend en charge que les types d'instance basés sur GPU et Inferentia. Assurez-vous de spécifier ces types d'instances dans votre AWS CloudFormation modèle de nœud. En utilisant l'AMI accélérée optimisée pour Amazon EKS vous acceptez le Contrat de licence de l'utilisateur final NVIDIA (CLUF).

  • L'AMI accélérée optimisée pour Amazon EKS était auparavant appelée AMI optimisée pour Amazon EKS avec prise en charge du GPU.

  • Les versions précédentes de l'AMI accélérée optimisée pour Amazon EKS ont installé le référentiel nvidia-docker. Le référentiel n'est plus inclus dans l'AMI Amazon EKS version v20200529 et ultérieure.

Pour activer des applications basées sur GPU

La procédure suivante décrit comment exécuter une application sur une instance GPU avec l'AMI accélérée optimisée pour Amazon EKS. Pour les autres options, consultez les références suivantes :

  1. Une fois vos nœuds GPU ajoutés à votre cluster, vous devez mettre en œuvre le plugin de périphérique NVIDIA pour Kubernetes en tant que DaemonSet sur votre cluster. vX.X.XRemplacez-le par la s-device-plugin version Nvidia/K8 de votre choix avant d'exécuter la commande suivante.

    kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/nvidia-device-plugin.yml
  2. Vous pouvez vérifier que vos nœuds ont des GPU répartis avec la commande suivante.

    kubectl get nodes "-o=custom-columns=NAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu"
Pour déployer un Pod pour tester que vos nœuds GPU sont configurés correctement
  1. Créez un fichier nommé nvidia-smi.yaml avec les contenus suivants. Remplacez tag par la balise souhaitée pour nvidia/cuda. Ce manifeste lance un conteneur NVIDIA CUDA qui exécute nvidia-smi sur un nœud.

    apiVersion: v1 kind: Pod metadata: name: nvidia-smi spec: restartPolicy: OnFailure containers: - name: nvidia-smi image: nvidia/cuda:tag args: - "nvidia-smi" resources: limits: nvidia.com/gpu: 1
  2. Appliquez le manifeste ci-dessus avec la commande suivante.

    kubectl apply -f nvidia-smi.yaml
  3. Une fois que le Pod n'est plus en cours d'exécution, affichez ses journaux à l'aide de la commande suivante.

    kubectl logs nvidia-smi

    L'exemple qui suit illustre un résultat.

    Mon Aug  6 20:23:31 20XX
    +-----------------------------------------------------------------------------+
    | NVIDIA-SMI XXX.XX                 Driver Version: XXX.XX                    |
    |-------------------------------+----------------------+----------------------+
    | GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
    | Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
    |===============================+======================+======================|
    |   0  Tesla V100-SXM2...  On   | 00000000:00:1C.0 Off |                    0 |
    | N/A   46C    P0    47W / 300W |      0MiB / 16160MiB |      0%      Default |
    +-------------------------------+----------------------+----------------------+
    
    +-----------------------------------------------------------------------------+
    | Processes:                                                       GPU Memory |
    |  GPU       PID   Type   Process name                             Usage      |
    |=============================================================================|
    |  No running processes found                                                 |
    +-----------------------------------------------------------------------------+

AMI Amazon Linux Arm optimisées pour Amazon EKS

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.

Considérations
  • 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 Mise à jour de la version Kubernetes de votre cluster Amazon EKS. Si vous avez déployé votre cluster le 17 août 2020 ou après cette date, vos modules complémentaires CoreDNS, kube-proxy, et Amazon VPC CNI plugin for 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 avez déployé des DaemonSets dans un cluster existant, ou si vous souhaitez les déployer dans un nouveau cluster dans lequel vous souhaitez également déployer des nœuds Arm, vérifiez que votre DaemonSet peut s'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 référentiel 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 dans le Guide de l'utilisateur Amazon ECR et l'article de blog Présentation d'images de conteneurs multi-architectures pour Amazon ECR.

Testez la migration Docker de containerd

Amazon EKS a mis fin à la prise en charge de Docker à partir du lancement de la version 1.24 de Kubernetes. Pour plus d’informations, consultez Amazon EKS a mis fin à la prise en charge de Dockershim.

Pour ce qui est de la Kubernetes version1.23, vous pouvez utiliser un indicateur bootstrap facultatif pour activer l'containerdexécution des AMI AL2 optimisées pour Amazon EKS. Cette fonctionnalité vous offre une voie claire pour migrer vers containerd lors de la mise à jour vers la version 1.24 ou ultérieure. Amazon EKS a mis fin à la prise en charge de Docker à partir du lancement de la version 1.24 de Kubernetes. L'environnement d'exécution containerd est largement adopté par la communauté Kubernetes et est un projet gradué de la CNCF. Vous pouvez le tester en ajoutant un groupe de nœuds à un cluster nouveau ou existant.

Vous pouvez activer l'indicateur d'amorçage en créant l'un des types de groupes de nœuds suivants.

Autogéré

Créez le groupe de nœuds à l'aide des instructions contenues dans Lancement de nœuds Amazon Linux autogérés. Spécifiez une AMI optimisée pour Amazon EKS et le texte suivant pour le paramètre BootstrapArguments.

--container-runtime containerd
Gérées

Si vous utilisez eksctl, créez un fichier nommé my-nodegroup.yaml avec le contenu suivant. Remplacez chaque example value par vos propres valeurs. Le nom du groupe de nœuds ne peut pas dépasser 63 caractères. Il doit commencer par une lettre ou un chiffre, mais peut également inclure des tirets et des traits de soulignement pour les autres caractères. Pour récupérer un ID d'AMI optimisée pour ami-1234567890abcdef0, veuillez consulter la rubrique Récupération des ID d'AMI Amazon Linux optimisées pour Amazon EKS.

apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: my-cluster region: region-code version: 1.23 managedNodeGroups: - name: my-nodegroup ami: ami-1234567890abcdef0 overrideBootstrapCommand: | #!/bin/bash /etc/eks/bootstrap.sh my-cluster --container-runtime containerd
Note

Si vous lancez de nombreux nœuds simultanément, vous pouvez également spécifier des valeurs pour le --apiserver-endpoint, --b64-cluster-ca, et les arguments bootstrap d'amorçage --dns-cluster-ip pour éviter les erreurs. Pour plus d’informations, consultez Spécification d'une AMI.

Exécutez les commandes suivantes pour créer le groupe de nœuds.

eksctl create nodegroup -f my-nodegroup.yaml

Si vous préférez utiliser un autre outil pour créer votre groupe de nœuds gérés, vous devez déployer le groupe de nœuds à l'aide d'un modèle de lancement. Dans votre modèle de lancement, spécifiez un ID d'AMI optimisée pour Amazon EKS, puis déployez le groupe de nœuds avec un modèle de lancement et fournissez les données utilisateur suivantes. Ces données utilisateur transmettent des arguments dans le fichier bootstrap.sh. Pour plus d'informations sur le fichier d'amorçage, consultez bootstrap.sh sur GitHub.

/etc/eks/bootstrap.sh my-cluster --container-runtime containerd

En savoir plus

Pour plus d'informations sur l'utilisation d'AMI Amazon Linux optimisées pour Amazon EKS, veuillez consulter les sections suivantes :