**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. # Personnaliser les nœuds gérés à l’aide de modèles de lancement Pour un niveau de personnalisation maximal, vous pouvez déployer des nœuds gérés avec votre propre modèle de lancement en suivant les étapes décrites sur cette page. L'utilisation d'un modèle de lancement permet des fonctionnalités telles que la fourniture d'arguments d'amorçage lors du déploiement d'un nœud (par exemple, des arguments [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) supplémentaires), l'attribution d'adresses IP aux pods à partir d'un bloc CIDR différent de l'adresse IP attribuée au nœud, le déploiement de votre propre AMI personnalisée sur les nœuds ou le déploiement de votre propre CNI personnalisé sur les nœuds. Si vous fournissez votre propre modèle de lancement lors de la création en premier lieu d'un groupe de nœuds gérés, vous bénéficierez également d'une plus grande flexibilité par la suite. Pourvu que vous déployiez un groupe de nœuds gérés avec votre propre modèle de lancement, vous pouvez le mettre à jour de façon itérative avec une version différente du même modèle de lancement. Lorsque vous mettez à jour votre groupe de nœuds vers une version différente de votre modèle de lancement, tous les nœuds du groupe sont recyclés pour correspondre à la nouvelle configuration de la version spécifiée du modèle de lancement. Les groupes de nœuds gérés sont toujours déployés avec un modèle de lancement à utiliser avec le groupe Amazon EC2 Auto Scaling. Si vous ne fournissez pas de modèle de lancement, l’API Amazon EKS en crée automatiquement un avec les valeurs par défaut de votre compte. Cependant, il est déconseillé de modifier les modèles de lancement générés automatiquement. De plus, les groupes de nœuds existants qui n’utilisent pas de modèle de lancement personnalisé ne peuvent pas être mis à jour directement. Vous devez plutôt créer un nouveau groupe de nœuds avec un modèle de lancement personnalisé à cet effet. ## Concepts de base de la configuration d'un modèle de lancement Vous pouvez créer un modèle de lancement Amazon EC2 Auto Scaling à l'aide de AWS Management Console la AWS CLI ou d' AWS un SDK. Pour plus d'informations, consultez [Création d'un modèle de lancement pour un groupe Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html) dans le *Guide de l'utilisateur Amazon EC2 Auto Scaling*. Certains des paramètres d'un modèle de lancement sont similaires aux paramètres utilisés pour la configuration des nœuds gérés. Lors du déploiement ou de la mise à jour d'un groupe de nœuds avec un modèle de lancement, certains paramètres doivent être spécifiés soit dans la configuration du groupe de nœuds, soit dans le modèle de lancement. Veuillez ne pas spécifier un paramètre aux deux endroits. Si un paramètre existe là où il ne devrait pas, les opérations telles que la création ou la mise à jour d’un groupe de nœuds échoueront. Le tableau suivant répertorie les paramètres interdits dans un modèle de lancement. Il répertorie également les paramètres similaires, s'il en existe, qui sont requis dans la configuration du groupe de nœuds géré. Les paramètres répertoriés sont les paramètres qui apparaissent dans la console. Ils peuvent avoir des noms similaires mais différents dans la AWS CLI et le SDK. | Modèle de lancement – Interdit | Configuration d'un groupe de nœuds Amazon EKS | | --- | --- | | **Sous-réseau** sous **Interfaces réseau** (**Ajouter une interface réseau**) | **Sous-réseaux** sous **Configuration réseau du groupe de nœuds** sur la page **Spécifier le réseau** | | **Profil d'instance IAM** sous **Détails avancés** | **Rôle IAM de nœud** sous **Configuration du groupe de nœuds** sur la page **Configurer le groupe de nœuds** | | **Comportement d'arrêt** et **Arrêt – Comportement de mise en veille prolongée** sous **Détails avancés**. Conservez le paramètre par défaut **Ne pas inclure dans le modèle de lancement** dans le modèle de lancement pour les deux paramètres. | Pas d'équivalent. Amazon EKS doit contrôler le cycle de vie de l'instance et non pas le groupe Auto Scaling. | Le tableau suivant répertorie les paramètres interdits dans une configuration de groupe de nœuds gérée. Il répertorie également les paramètres similaires, s'il en existe, qui sont requis dans un modèle de lancement. Les paramètres répertoriés sont les paramètres qui apparaissent dans la console. Ils peuvent porter des noms similaires dans la AWS CLI et le SDK. | Configuration du groupe de nœuds Amazon EKS : Interdite | Modèle de lancement | | --- | --- | | (Seulement si vous avez spécifié une AMI personnalisée dans un modèle de lancement) **AMI type** (Type d'AMI) sous **Node Group compute configuration** (Configuration du calcul du groupe de nœuds) sur la page **Set compute and scaling configuration** (Définir la configuration de calcul et de mise à l'échelle) : la console affiche **Specified in launch template** (Spécifié dans le modèle de lancement) et l'ID d'AMI spécifié. Si **Images d’application et de système d’exploitation (Amazon Machine Image)** n’a pas été spécifié dans le modèle de lancement, vous pouvez sélectionner une AMI dans la configuration du groupe de nœuds. | **Images d'applications et de systèmes d'exploitation (Amazon Machine Image)** sous **Contenu du modèle de lancement** : vous devez spécifier un ID dans l'un des cas suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/launch-templates.html) | | **Taille du disque** sous **Configuration de calcul du groupe de nœuds** sur la page **Définir la configuration de calcul et de mise à l'échelle** : la console affiche **Spécifié dans le modèle de lancement**. | **Taille** sous **Stockage (volumes)** (**Ajouter un nouveau volume**). Vous devez le spécifier dans le modèle de lancement. | | **Paire de clés SSH** sous **Configuration du groupe de nœuds** sur la page **Spécifier le réseau** : la console affiche la clé spécifiée dans le modèle de lancement ou **Non spécifié dans le modèle de lancement**. | **Nom de la paire de clés** sous **Paire de clés (connexion)**. | | Vous ne pouvez pas spécifier de groupes de sécurité source autorisés à accéder à distance lorsque vous utilisez un modèle de lancement. | **Groupes de sécurité** sous **Paramètres réseau** pour l'instance ou **Groupes de sécurité** sous **Interfaces réseau** (**Ajouter une interface réseau**), mais pas les deux. Pour de plus amples informations, veuillez consulter [Utilisation des groupes de sécurité](#launch-template-security-groups). | **Note** Si vous déployez un groupe de nœuds à l'aide d'un modèle de lancement, spécifiez zéro ou un **type d'instance** sous **Contenu du modèle de lancement** dans un modèle de lancement. Vous pouvez également spécifier de 0 à 20 types d'instance sous **types d'instance** sur la page **Définir la configuration de calcul et de mise à l'échelle** dans la console. Vous pouvez également le faire à l'aide d'autres outils qui utilisent l'API Amazon EKS. Si vous spécifiez un type d’instance dans un modèle de lancement et que vous utilisez ce modèle pour déployer votre groupe de nœuds, vous ne pouvez spécifier aucun type d’instance dans la console ou à l’aide d’autres outils qui utilisent l’API Amazon EKS. Si vous ne spécifiez pas de type d’instance dans un modèle de lancement, dans la console ou à l’aide d’autres outils utilisant l’API Amazon EKS, le type d’instance `t3.medium` est utilisé. Si votre groupe de nœuds utilise le type de capacité Spot, nous vous recommandons de spécifier plusieurs types d'instance à l'aide de la console. Pour de plus amples informations, veuillez consulter [Types de capacité des groupes de nœuds gérés](managed-node-groups.md#managed-node-group-capacity-types). Si les conteneurs que vous déployez dans le groupe de nœuds utilisent le service de métadonnées d'instance version 2, veillez à définir `2` comme **limite de saut de réponse des métadonnées** dans votre modèle de lancement. Pour plus d'informations, consultez [Métadonnées d'instance et données utilisateur](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) dans le *Guide de l'utilisateur Amazon EC2*. Les modèles de lancement ne prennent pas en charge la fonctionnalité `InstanceRequirements` qui permet une sélection flexible du type d’instance. ## Étiquetage des instances Amazon EC2 Vous pouvez utiliser le paramètre `TagSpecification` d'un modèle de lancement pour spécifier les identifications à appliquer aux instances Amazon EC2 dans votre groupe de nœuds. L'entité IAM qui appelle le `CreateNodegroup` ou `UpdateNodegroupVersion` APIs doit disposer des autorisations pour `ec2:RunInstances` et`ec2:CreateTags`, et les balises doivent être ajoutées au modèle de lancement. ## Utilisation des groupes de sécurité Vous pouvez utiliser un modèle de lancement pour spécifier des [groupes de sécurité](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) Amazon EC2 à appliquer aux instances de votre groupe de nœuds. Vous pouvez le faire soit dans le paramètre des groupes de sécurité au niveau de l'instance, soit dans le cadre des paramètres de configuration de l'interface réseau. Cependant, vous ne pouvez pas créer un modèle de lancement qui spécifie à la fois le niveau d’instance et les groupes de sécurité de l’interface réseau. Prenez en compte les conditions suivantes qui s'appliquent à l'utilisation de groupes de sécurité personnalisés avec des groupes de nœuds gérés : + Lorsque vous utilisez le AWS Management Console, Amazon EKS n'autorise que les modèles de lancement dotés d'une seule spécification d'interface réseau. + Par défaut, Amazon EKS applique le [groupe de sécurité](sec-group-reqs.md) du cluster aux instances de votre groupe de nœuds pour faciliter la communication entre les nœuds et le plan de contrôle. Si vous spécifiez des groupes de sécurité personnalisés dans le modèle de lancement à l’aide de l’une des options mentionnées précédemment, Amazon EKS n’ajoute pas le groupe de sécurité du cluster. Vous devez donc vous assurer que les règles d'entrée et de sortie de vos groupes de sécurité permettent la communication avec le point de terminaison de votre cluster. Si vos règles de groupe de sécurité sont incorrectes, les composants master ne peuvent pas rejoindre le cluster. Pour plus d'informations sur les règles de groupe de sécurité, consultez [Voir les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters](sec-group-reqs.md). + Si vous avez besoin d'un accès SSH aux instances de votre groupe de nœuds, incluez un groupe de sécurité qui autorise cet accès. ## Données utilisateur Amazon EC2 Le modèle de lancement comprend une section pour les données utilisateur personnalisées. Vous pouvez définir les paramètres de configuration de votre groupe de nœuds dans cette section sans créer manuellement une personnalisation individuelle AMIs. Pour plus d'informations sur les paramètres disponibles pour Bottlerocket, consultez la section [Utilisation des données utilisateur](https://github.com/bottlerocket-os/bottlerocket#using-user-data) sur. GitHub Vous pouvez fournir des données d'utilisateur Amazon EC2 dans votre modèle de lancement en utilisant `cloud-init` lors du lancement de vos instances. Pour plus d’informations, consultez la [documentation cloud-init](https://cloudinit.readthedocs.io/en/latest/index.html). Vos données utilisateur peuvent être utilisées pour effectuer des opérations de configuration courantes. Elles comprennent : + [Inclusion d'utilisateurs ou de groupes](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups) + [Installations de packages](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#install-arbitrary-packages) Les données utilisateur Amazon EC2 figurant dans les modèles de lancement utilisés avec des groupes de nœuds gérés doivent être au format d'archive en [plusieurs parties MIME pour Amazon Linux AMIs et au format](https://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive) TOML pour Bottlerocket. AMIs En effet, vos données utilisateur sont fusionnées avec les données utilisateur d'Amazon EKS requises pour que les nœuds puissent rejoindre le cluster. Ne spécifiez aucune commande dans vos données utilisateur qui démarre ou modifie `kubelet`. Ceci est effectué dans le cadre des données utilisateur fusionnées par Amazon EKS. Certains paramètres `kubelet`, tels que la définition des étiquettes sur les nœuds, peuvent être configurés directement via l'API des groupes de nœuds gérés. **Note** Pour plus d'informations sur la personnalisation avancée de `kubelet`, y compris son démarrage manuel ou le passage de paramètres de configuration personnalisés, consultez [Spécification d'une AMI](#launch-template-custom-ami). Si un ID d’AMI personnalisé est spécifié dans un modèle de lancement, Amazon EKS ne fusionne pas les données utilisateur. Les détails suivants fournissent plus d'informations sur la section des données utilisateur. **Données utilisateur Amazon Linux 2** Vous pouvez combiner plusieurs blocs de données utilisateur dans un seul fichier MIME multi-part. Par exemple, vous pouvez combiner un boothook cloud qui configure le démon Docker avec un script shell de données utilisateur qui installe un package personnalisé. Un fichier MIME multi-part est constitué des composants suivants : + La déclaration de type de contenu et de limite de partie : `Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="` + La déclaration de version MIME : `MIME-Version: 1.0` + Un ou plusieurs blocs de données qui contiennent les composants suivants : + La limite de début qui signale le début d'un bloc de données utilisateur : `--==MYBOUNDARY==` + La déclaration de type de contenu du bloc : `Content-Type: text/cloud-config; charset="us-ascii"`. Pour plus d'informations sur les types de contenus, consultez la [documentation sur Cloud-Init](https://cloudinit.readthedocs.io/en/latest/topics/format.html). + Le contenu des données utilisateur (par exemple, une liste de commandes shell ou de directives `cloud-init`). + La limite de fin qui signale la fin du fichier MIME multi-part : `--==MYBOUNDARY==--` Voici un exemple de fichier MIME multi-part que vous pouvez utiliser pour créer le vôtre. ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==MYBOUNDARY==" --==MYBOUNDARY== Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash echo "Running custom user data script" --==MYBOUNDARY==-- ``` **Données utilisateur Amazon Linux 2023** Amazon Linux 2023 (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 ``` Vous définirez généralement cette configuration dans vos données utilisateur, soit telle quelle, soit intégrée dans un document MIME multipart : ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOUNDARY" --BOUNDARY Content-Type: application/node.eks.aws --- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: [...] --BOUNDARY-- ``` 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*. Voici un exemple complet de données AL2023 utilisateur qui combine un script shell pour personnaliser le nœud (comme l'installation de packages ou la pré-mise en cache des images de conteneur) avec la configuration requise. `nodeadm` Cet exemple présente des personnalisations courantes, notamment : \$1 L’installation de paquets système supplémentaires \$1 La mise en cache préalable des images de conteneur pour améliorer le temps de démarrage des pods \$1 La configuration du proxy HTTP \$1 La configuration des métriques `kubelet` pour l’étiquetage des nœuds ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOUNDARY" --BOUNDARY Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash set -o errexit set -o pipefail set -o nounset # Install additional packages yum install -y htop jq iptables-services # Pre-cache commonly used container images nohup docker pull public.ecr.aws/eks-distro/kubernetes/pause:3.2 & # Configure HTTP proxy if needed cat > /etc/profile.d/http-proxy.sh << 'EOF' export HTTP_PROXY="http://proxy.example.com:3128" export HTTPS_PROXY="http://proxy.example.com:3128" export NO_PROXY="localhost,127.0.0.1,169.254.169.254,.internal" EOF --BOUNDARY Content-Type: application/node.eks.aws apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: my-cluster apiServerEndpoint: https://example.com certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk= cidr: 10.100.0.0/16 kubelet: config: clusterDNS: - 10.100.0.10 flags: - --node-labels=app=my-app,environment=production --BOUNDARY-- ``` **Données utilisateur Bottlerocket** Bottlerocket structure les données utilisateur au format TOML. Vous pouvez fournir des données utilisateur qui seront fusionnées avec les données utilisateur fournies par Amazon EKS. Par exemple, vous pouvez fournir des paramètres `kubelet` supplémentaires. ``` [settings.kubernetes.system-reserved] cpu = "10m" memory = "100Mi" ephemeral-storage= "1Gi" ``` Pour plus d'informations sur les paramètres pris en charge, consultez la [documentation Bottlerocket](https://github.com/bottlerocket-os/bottlerocket). Vous pouvez configurer des étiquettes de nœuds et des [rejets](node-taints-managed-node-groups.md) dans vos données utilisateur. Cependant, nous vous recommandons de les configurer plutôt dans votre groupe de nœuds. Amazon EKS applique ces configurations lorsque vous le faites. Lorsque les données utilisateur sont fusionnées, la mise en forme n’est pas conservée, mais le contenu reste le même. La configuration que vous fournissez dans vos données utilisateur remplace tous les paramètres qui sont configurés par Amazon EKS. Ainsi, si vous définissez `settings.kubernetes.max-pods` ou `settings.kubernetes.cluster-dns-ip`, ces valeurs dans vos données utilisateur sont appliquées aux nœuds. Amazon EKS ne prend pas en charge tous les TOML valides. Voici une liste des formats connus non pris en charge : + Guillemets dans les clés entre guillemets : `'quoted "value"' = "value"` + Guillemets échappés dans les valeurs : `str = "I’m a string. \"You can quote me\""` + Flottants et entiers mélangés : `numbers = [ 0.1, 0.2, 0.5, 1, 2, 5 ]` + Types mixtes dans les tableaux : `contributors = ["[foo@example.com](mailto:foo@example.com)", { name = "Baz", email = "[baz@example.com](mailto:baz@example.com)" }]` + En-têtes entre parenthèses avec clés entre guillemets : `[foo."bar.baz"]` **Données utilisateur Windows** Les données utilisateur Windows utilisent des PowerShell commandes. Lorsque vous créez un groupe de nœuds gérés, vos données utilisateur personnalisées sont combinées avec les données utilisateur gérées par Amazon EKS. Vos PowerShell commandes viennent en premier, suivies des commandes de gestion des données utilisateur, le tout dans une seule `` balise. Lors de la création de groupes de nœuds Windows, Amazon EKS met à jour le `aws-auth` `ConfigMap` pour permettre aux nœuds Linux de rejoindre le cluster. Le service ne configure pas automatiquement les autorisations pour Windows AMIs. Si vous utilisez des nœuds Windows, vous devrez gérer l’accès via l’API d’entrée d’accès ou en mettant à jour directement le `aws-auth` `ConfigMap`. Pour de plus amples informations, veuillez consulter [Déployer des nœuds Windows sur des clusters EKS](windows-support.md). Lorsque aucun ID d’AMI n’est spécifié dans le modèle de lancement, n’utilisez pas le script Windows Amazon EKS Bootstrap dans les données utilisateur pour configurer Amazon EKS. Voici un exemple de données utilisateur. ``` Write-Host "Running custom user data script" ``` ## Spécification d'une AMI Si vous avez l'une des conditions suivantes, spécifiez un ID d'AMI dans le champ `ImageId` de votre modèle de lancement. Sélectionnez votre besoin d'informations supplémentaires. ### Fournissez des données utilisateur pour transmettre des arguments au `bootstrap.sh` fichier inclus dans une Linux/Bottlerocket AMI optimisée pour Amazon EKS L'amorçage est un terme utilisé pour décrire l'ajout de commandes pouvant être exécutées au démarrage d'une instance. Par exemple, la mise en place initiale permet d’utiliser des arguments [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) supplémentaires. Vous pouvez transmettre les arguments au script `bootstrap.sh` en utilisant `eksctl` sans spécifier de modèle de lancement. Vous pouvez également le faire en spécifiant les informations dans la section des données utilisateur d'un modèle de lancement. **eksctl sans spécifier de modèle de lancement** Créez un fichier nommé *my-nodegroup.yaml* avec les contenus suivants. Remplacez chaque *example value* par vos propres valeurs. Les arguments `--apiserver-endpoint`, `--b64-cluster-ca` et `--dns-cluster-ip` sont facultatifs. Cependant, leur définition permet au script `bootstrap.sh` d'éviter de passer un appel `describeCluster`. Ceci est utile dans les configurations de clusters privés ou les clusters où vous effectuez fréquemment des opérations de mise à l’échelle et de réduction des nœuds. Pour plus d'informations sur le `bootstrap.sh` script, consultez le fichier [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) sur GitHub. + Le seul argument requis est le nom du cluster (*my-cluster*). + Pour récupérer un ID d’AMI optimisé pour `ami-1234567890abcdef0 `, consultez les sections suivantes : + [Récupérez l'AMI Amazon Linux recommandée IDs](retrieve-ami-id.md) + [Récupérez l'AMI Bottlerocket recommandée IDs](retrieve-ami-id-bottlerocket.md) + [Récupérez l'AMI Microsoft Windows recommandée IDs](retrieve-windows-ami-id.md) + Pour récupérer le *certificate-authority* de votre cluster, exécutez la commande suivante. ``` aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code ``` + Pour récupérer le *api-server-endpoint* de votre cluster, exécutez la commande suivante. ``` aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code ``` + La valeur de `--dns-cluster-ip` est votre CIDR de service avec `.10` à la fin. Pour récupérer le *service-cidr* de votre cluster, exécutez la commande suivante. Par exemple, si la valeur renvoyée est `ipv4 10.100.0.0/16`, votre valeur est *10.100.0.10*. ``` aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code ``` + Cet exemple fournit un argument `kubelet` supplémentaire pour définir une valeur `max-pods` personnalisée à l'aide du script `bootstrap.sh` inclus dans l'AMI optimisée pour Amazon EKS. 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 obtenir de l'aide sur la sélection de *my-max-pods-value*, consultez . Pour plus d'informations sur le mode `maxPods` de détermination lors de l'utilisation de groupes de nœuds gérés, consultez[Comment est déterminé MaxPods](choosing-instance-type.md#max-pods-precedence). ``` --- apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: my-cluster region: region-code managedNodeGroups: - name: my-nodegroup ami: ami-1234567890abcdef0 instanceType: m5.large privateNetworking: true disableIMDSv1: true labels: { x86-al2-specified-mng } overrideBootstrapCommand: | #!/bin/bash /etc/eks/bootstrap.sh my-cluster \ --b64-cluster-ca certificate-authority \ --apiserver-endpoint api-server-endpoint \ --dns-cluster-ip service-cidr.10 \ --kubelet-extra-args '--max-pods=my-max-pods-value' \ --use-max-pods false ``` Pour chaque option de fichier `eksctl` `config` disponible, consultez [Schéma de fichier de configuration](https://eksctl.io/usage/schema/) dans la documentation `eksctl`. L'utilitaire `eksctl` crée toujours un modèle de lancement pour vous et remplit ses données utilisateur avec les données que vous fournissez dans le fichier `config`. Créez un groupe de nœuds avec la commande suivante. ``` eksctl create nodegroup --config-file=my-nodegroup.yaml ``` **Données utilisateur dans un modèle de lancement** Spécifiez les informations suivantes dans la section des données utilisateur de votre modèle de lancement. Remplacez chaque *example value* par vos propres valeurs. Les arguments `--apiserver-endpoint`, `--b64-cluster-ca` et `--dns-cluster-ip` sont facultatifs. Cependant, leur définition permet au script `bootstrap.sh` d'éviter de passer un appel `describeCluster`. Ceci est utile dans les configurations de clusters privés ou les clusters où vous effectuez fréquemment des opérations de mise à l’échelle et de réduction des nœuds. Pour plus d'informations sur le `bootstrap.sh` script, consultez le fichier [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) sur GitHub. + Le seul argument requis est le nom du cluster (*my-cluster*). + Pour récupérer le *certificate-authority* de votre cluster, exécutez la commande suivante. ``` aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code ``` + Pour récupérer le *api-server-endpoint* de votre cluster, exécutez la commande suivante. ``` aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code ``` + La valeur de `--dns-cluster-ip` est votre CIDR de service avec `.10` à la fin. Pour récupérer le *service-cidr* de votre cluster, exécutez la commande suivante. Par exemple, si la valeur renvoyée est `ipv4 10.100.0.0/16`, votre valeur est *10.100.0.10*. ``` aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code ``` + Cet exemple fournit un argument `kubelet` supplémentaire pour définir une valeur `max-pods` personnalisée à l'aide du script `bootstrap.sh` inclus dans l'AMI optimisée pour Amazon EKS. Pour obtenir de l'aide sur la sélection de *my-max-pods-value*, consultez . Pour plus d'informations sur le mode `maxPods` de détermination lors de l'utilisation de groupes de nœuds gérés, consultez[Comment est déterminé MaxPods](choosing-instance-type.md#max-pods-precedence). ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==MYBOUNDARY==" --==MYBOUNDARY== Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash set -ex /etc/eks/bootstrap.sh my-cluster \ --b64-cluster-ca certificate-authority \ --apiserver-endpoint api-server-endpoint \ --dns-cluster-ip service-cidr.10 \ --kubelet-extra-args '--max-pods=my-max-pods-value' \ --use-max-pods false --==MYBOUNDARY==-- ``` ### Fournissez des données utilisateur pour transmettre des arguments au fichier `Start-EKSBootstrap.ps1` inclus dans une AMI Windows optimisée pour Amazon EKS L'amorçage est un terme utilisé pour décrire l'ajout de commandes pouvant être exécutées au démarrage d'une instance. Vous pouvez transmettre les arguments au script `Start-EKSBootstrap.ps1` en utilisant `eksctl` sans spécifier de modèle de lancement. Vous pouvez également le faire en spécifiant les informations dans la section des données utilisateur d'un modèle de lancement. Si vous voulez spécifier un ID d’AMI Windows personnalisé, tenez compte des considérations suivantes : + Vous devez utiliser un modèle de lancement et fournir les commandes d'amorçage requises dans la section des données utilisateur. Pour récupérer l'ID Windows souhaité, vous pouvez utiliser le tableau de la section [Créer des nœuds avec Windows optimisé AMIs](eks-optimized-windows-ami.md). + Il existe plusieurs limites et conditions. Par exemple, vous devez ajouter des éléments `eks:kube-proxy-windows` à votre carte de configuration AWS IAM Authenticator. Pour de plus amples informations, veuillez consulter [Limites et conditions lors de la spécification d'un ID d'AMI](#mng-ami-id-conditions). Spécifiez les informations suivantes dans la section des données utilisateur de votre modèle de lancement. Remplacez chaque *example value* par vos propres valeurs. Les arguments `-APIServerEndpoint`, `-Base64ClusterCA` et `-DNSClusterIP` sont facultatifs. Cependant, leur définition permet au script `Start-EKSBootstrap.ps1` d'éviter de passer un appel `describeCluster`. + Le seul argument requis est le nom du cluster (*my-cluster*). + Pour récupérer le *certificate-authority* de votre cluster, exécutez la commande suivante. ``` aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code ``` + Pour récupérer le *api-server-endpoint* de votre cluster, exécutez la commande suivante. ``` aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code ``` + La valeur de `--dns-cluster-ip` est votre CIDR de service avec `.10` à la fin. Pour récupérer le *service-cidr* de votre cluster, exécutez la commande suivante. Par exemple, si la valeur renvoyée est `ipv4 10.100.0.0/16`, votre valeur est *10.100.0.10*. ``` aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code ``` + Pour des arguments supplémentaires, consultez [Paramètres de configuration du script d'amorçage](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters). **Note** Si vous utilisez un CIDR de service personnalisé, vous devez le spécifier à l’aide du paramètre `-ServiceCIDR`. Sinon, la résolution DNS pour les pods dans le cluster échouera. ``` [string]$EKSBootstrapScriptFile = "$env:ProgramFiles\Amazon\EKS\Start-EKSBootstrap.ps1" & $EKSBootstrapScriptFile -EKSClusterName my-cluster ` -Base64ClusterCA certificate-authority ` -APIServerEndpoint api-server-endpoint ` -DNSClusterIP service-cidr.10 ``` ### Exécution d'une AMI personnalisée en raison d'exigences spécifiques en matière de sécurité, de conformité ou de politique interne. Pour plus d’informations, consultez [Amazon Machine Images (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) dans le *Guide de l’utilisateur Amazon EC2*. La spécification de création d’AMI Amazon EKS contient des ressources et des scripts de configuration pour créer une AMI Amazon EKS personnalisée basée sur Amazon Linux. Pour plus d'informations, consultez [Spécifications de création d'AMI Amazon EKS](https://github.com/awslabs/amazon-eks-ami/) sur GitHub. Pour créer une AMIs installation personnalisée avec d'autres systèmes d'exploitation, consultez [Amazon EKS Sample Custom AMIs](https://github.com/aws-samples/amazon-eks-custom-amis) on GitHub. Vous ne pouvez pas utiliser de références de paramètres dynamiques pour les AMI IDs dans les modèles de lancement utilisés avec les groupes de nœuds gérés. **Important** Lorsque vous spécifiez une AMI, Amazon EKS ne valide pas la version de Kubernetes intégrée à votre AMI par rapport à la version du plan de contrôle de votre cluster. Il vous incombe de vous assurer que la version Kubernetes de votre AMI personnalisée est conforme à la politique de distorsion des versions de [Kubernetes](https://kubernetes.io/releases/version-skew-policy) : La `kubelet` version de vos nœuds ne doit pas être plus récente que la version de votre cluster La `kubelet` version sur vos nœuds doit être égale ou supérieure à 3 versions mineures par rapport à la version de votre cluster (pour la version de Kubernetes `1.28` ou supérieure), ou jusqu'à 2 versions mineures par rapport à la version de votre cluster (pour la version de Kubernetes ou inférieure) `1.27` La création de groupes de nœuds gérés présentant des violations de distorsion de version peut entraîner : Les nœuds ne parviennent pas à rejoindre le cluster Comportement non défini ou incompatibilités d'API Instabilité du cluster ou défaillances de charge de travail Lorsque vous spécifiez une AMI, Amazon EKS ne fusionne aucune donnée utilisateur. C’est à vous qu’il incombe de fournir les commandes `bootstrap` requises pour que les nœuds rejoignent le cluster. Si vos nœuds ne parviennent pas à joindre le cluster, les actions `CreateNodegroup` et `UpdateNodegroupVersion` Amazon EKS échouent également. ## Limites et conditions lors de la spécification d'un ID d'AMI Voici les limites et les conditions impliquées dans la spécification d'un ID d'AMI avec des groupes de nœuds gérés : + Vous devez créer un groupe de nœuds pour passer de la spécification d'un ID d'AMI dans un modèle de lancement à la non-spécification d'un ID d'AMI. + Vous n’êtes pas notifié dans la console lorsqu’une version plus récente de l’AMI est disponible. Pour mettre à jour votre groupe de nœuds vers une version d'AMI plus récente, vous devez créer une nouvelle version de votre modèle de lancement avec un ID d'AMI mis à jour. Vous devez ensuite mettre à jour le groupe de nœuds avec la nouvelle version du modèle de lancement. + Les champs suivants ne peuvent pas être définis dans l’API si vous spécifiez un ID d’AMI : + `amiType` + `releaseVersion` + `version` + Tous les `taints` définis dans l'API sont appliqués de manière asynchrone si vous spécifiez un identifiant d'AMI. Pour appliquer des rejets avant l'ajout d'un nœud au cluster, vous devez les transférer à `kubelet` dans vos données utilisateur à l'aide de l'indicateur de ligne de commande `--register-with-taints`. Pour plus d'informations, consultez [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) dans la documentation Kubernetes. + Lorsque vous spécifiez un ID AMI personnalisé pour les groupes de nœuds gérés par Windows, ajoutez-le `eks:kube-proxy-windows` à votre carte de configuration AWS IAM Authenticator. Cela est nécessaire pour le bon fonctionnement du DNS. 1. Ouvrez la carte de configuration de l'authentificateur AWS IAM pour la modifier. ``` kubectl edit -n kube-system cm aws-auth ``` 1. Ajoutez cette entrée à la liste `groups` sous chaque `rolearn` associé aux nœuds Windows. Votre carte de configuration doit ressembler à [aws-auth-cm-windows.yaml.](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml) ``` - eks:kube-proxy-windows ``` 1. Enregistrez le fichier et quittez votre éditeur de texte. + Pour toute AMI utilisant un modèle de lancement personnalisé, la valeur par défaut `HttpPutResponseHopLimit` pour les groupes de nœuds gérés est définie sur `2`.