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.
Personnalisation des nœuds gérés avec des modèles de lancement
Pour le plus haut niveau de personnalisation, vous pouvez déployer des nœuds gérés en utilisant votre propre modèle de lancement. L'utilisation d'un modèle de lancement permet d'accéder à des fonctionnalités telles que les suivantes :
-
Fournissez des arguments d'amorçage lors du déploiement d'un nœud, tels que des arguments
kubelet
supplémentaires. -
Affectez des adresses IP à des Pods à partir d'un bloc d'adresse CIDR différent de l'adresse IP affectée au nœud.
-
Déployez votre propre AMI personnalisée sur les nœuds.
-
Déployez votre propre CNI personnalisée 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 un automatiquement avec des valeurs par défaut dans votre compte. Cependant, nous ne vous recommandons pas 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 avec le AWS Management Console AWS CLI, ou un AWS SDK. Pour plus d'informations, consultez Création d'un modèle de lancement pour un groupe Auto Scaling 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. Ne spécifiez pas un paramètre aux deux endroits. Si un paramètre existe là où il ne devrait pas, des opérations telles que la création ou la mise à jour d'un groupe de nœuds échouent.
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 le SDK AWS CLI et.
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. Rétention par défaut Ne pas inclure dans le paramètre de 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 le SDK AWS CLI et.
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 aucune Image d'application et de système d'exploitation (Amazon Machine Image) n'a été spécifiée 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 :
|
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 les groupes de sécurité source qui sont autorisés à accéder à distance lors de l'utilisation d'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 plus d’informations, consultez Utilisation des groupes de sécurité. |
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 de lancement pour déployer votre groupe de nœuds, vous ne pouvez pas spécifier d'autres types d'instances 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 qui utilisent 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 plus d’informations, consultez Types de capacité des groupes de nœuds gérés. -
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 dans le Guide de l'utilisateur Amazon EC2. Si vous déployez un groupe de nœuds géré sans utiliser de modèle de lancement personnalisé, cette valeur est automatiquement définie pour le groupe de nœuds dans le modèle de lancement par défaut.
É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 appelant l'API CreateNodegroup
ou UpdateNodegroupVersion
doit avoir des autorisations pour ec2:RunInstances
et ec2:CreateTags
, et les identifications 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é 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 les groupes de sécurité au niveau de l'instance et 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 :
-
Amazon EKS n'autorise que les modèles de lancement avec une seule spécification d'interface réseau.
-
Par défaut, Amazon EKS applique le groupe de sécurité 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 en utilisant 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 Considérations et exigences relatives aux groupes de sécurité Amazon EKS.
-
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 spécifier les paramètres de configuration de votre groupe de nœuds dans cette section sans créer manuellement des AMI personnalisés individuels. Pour plus d'informations sur les paramètres disponibles pour Bottlerocket, consultez Utilisation des données utilisateur
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
Les données utilisateur Amazon EC2 dans les modèles de lancement qui sont utilisés avec les groupes de nœuds gérés doivent être au format MIME Multi-Part Archivekubelet
. 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. 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.
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.
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, l'amorçage permet d'utiliser des arguments kubelet
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.
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 souhaitez spécifiez un ID d'AMI Windows personnalisée, gardez à l'esprit les 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 dans AMI Windows optimisées pour Amazon EKS.
-
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 plus d’informations, consultez Limites et conditions lors de la spécification d'un ID d'AMI.
Spécifiez les informations suivantes dans la section des données utilisateur de votre modèle de lancement. Remplacez chaque
par vos propres valeurs. Les arguments example value
-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
de votre cluster, exécutez la commande suivante.certificate-authority
aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name
my-cluster
--regionregion-code
-
Pour récupérer le
de votre cluster, exécutez la commande suivante.api-server-endpoint
aws eks describe-cluster --query "cluster.endpoint" --output text --name
my-cluster
--regionregion-code
-
La valeur de
--dns-cluster-ip
est votre CIDR de service avec.10
à la fin. Pour récupérer le
de votre cluster, exécutez la commande suivante. Par exemple, si la valeur renvoyée estservice-cidr
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
--regionregion-code
-
Pour des arguments supplémentaires, consultez Paramètres de configuration du script d'amorçage.
Note
Si vous utilisez un CIDR de service personnalisé, vous devez le spécifier à l'aide du paramètre
-ServiceCIDR
. Dans le cas contraire, la résolution DNS pour les Pods dans le cluster échouera.
<powershell> [string]$EKSBootstrapScriptFile = "$env:ProgramFiles\Amazon\EKS\Start-EKSBootstrap.ps1" & $EKSBootstrapScriptFile -EKSClusterName
my-cluster
` -Base64ClusterCAcertificate-authority
` -APIServerEndpointapi-server-endpoint
` -DNSClusterIPservice-cidr.10
</powershell>
Pour plus d’informations, veuillez consulter la rubrique Amazon Machine Images (AMI) dans le Guide de l’utilisateur Amazon EC2. La spécification de génération de l'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
Important
Lorsque vous spécifiez une AMI, Amazon EKS ne fusionne aucune donnée utilisateur. Vous devez 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 averti 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 la sectionkubelet
dans la documentation Kubernetes. -
Lorsque vous spécifiez un ID AMI personnalisé pour les groupes de nœuds Windows gérés, ajoutez-le
eks:kube-proxy-windows
à votre carte de configuration AWS IAM Authenticator. Cela est nécessaire pour le bon fonctionnement du DNS.-
Ouvrez la carte de configuration de l'authentificateur AWS IAM pour la modifier.
kubectl edit -n kube-system cm aws-auth
-
Ajoutez cette entrée à la liste des
groups
sous chaquerolearn
associé aux nœuds Windows. Votre mappage de configuration doit ressembler àaws-auth-cm-windows.yaml
. - eks:kube-proxy-windows
-
Enregistrez le fichier et quittez votre éditeur de texte.
-