Personnalisez les nœuds gérés avec des modèles de lancement - Amazon EKS
Concepts de base de la configuration d'un modèle de lancementMarquage des instances Amazon EC2Utilisation des groupes de sécuritéDonnées EC2 utilisateur d'AmazonSpécifier un AMILimites et conditions lors de la spécification d'un AMI identifiant

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.

Personnalisez les 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 bootstrap lors du déploiement d'un nœud, tels que des arguments kubelet supplémentaires.

  • Attribuez des adresses IP à Pods à partir d'un CIDR bloc différent de l'adresse IP attribuée au nœud.

  • Déployez votre propre personnalisation sur AMI les nœuds.

  • Déployez votre propre personnalisation sur CNI 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. Lorsque vous ne fournissez pas de modèle de lancement, Amazon en EKS API crée un automatiquement avec des valeurs par défaut dans votre compte. Toutefois, nous vous déconseillons de modifier les modèles de lancement générés automatiquement. En outre, 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 la section Création d'un modèle de lancement pour un groupe Auto Scaling dans le guide de l'utilisateur d'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 de paramètre aux deux endroits. Si un paramètre existe là où il ne devrait pas exister, les 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 AWS CLI etSDK.

Modèle de lancement – Interdit Configuration EKS du groupe de nœuds Amazon

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

IAMprofil d'instance sous Détails avancés

IAMRôle du 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. Conserver la valeur par défaut Ne pas inclure dans le paramètre du 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 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 avoir des noms similaires dans le AWS CLI etSDK.

Configuration EKS du groupe de nœuds Amazon — Interdite Modèle de lancement

(Uniquement si vous avez spécifié une option personnalisée AMI dans un modèle de lancement) AMIsous Configuration de calcul du groupe de nœuds sur la page Définir la configuration du calcul et du dimensionnement — La console affiche Spécifié dans le modèle de lancement et l'AMIID spécifié.

Si les images de l'application et du système d'exploitation (Amazon Machine Image) n'ont pas été spécifiées dans le modèle de lancement, vous pouvez en sélectionner une AMI dans le 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 :

* À l'aide d'une personnalisationAMI. Si vous spécifiez un nœud AMI qui ne répond pas aux exigences répertoriées dans Spécifier un AMI Spécifier unAMI, le déploiement du groupe de nœuds échouera. * Vous souhaitez fournir des données utilisateur pour fournir des arguments au bootstrap.sh fichier inclus dans un fichier EKS optimisé pour AmazonAMI. Vous pouvez permettre à vos instances d'attribuer un nombre nettement plus élevé d'adresses IP à Pods, attribuez des adresses IP à Pods à partir d'un CIDR bloc différent de celui de l'instance, ou déployez un cluster privé sans accès Internet sortant. Pour plus d'informations, consultez les rubriques suivantes : + Attribuez davantage d'adresses IP aux EKS nœuds Amazon avec des préfixesAttribuer davantage d'adresses IP aux EKS nœuds Amazon à l'aide de préfixes Déploiement pods dans des sous-réseaux alternatifs avec mise en réseau personnalisée Déployer des pods dans des sous-réseaux alternatifs dotés d'un réseau personnalisé Déployez des clusters privés avec un accès Internet limitéDéployer des clusters privés avec un accès Internet limité Spécifier un Spécifier un AMI AMI

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.

SSHpaire de clés 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 affiche Non spécifiée 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 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é.
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 utilisant Amazon EKSAPI. 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 de type d'instance dans la console ou à l'aide d'autres outils utilisant Amazon EKSAPI. Si vous ne spécifiez aucun type d'instance dans un modèle de lancement, dans la console ou à l'aide d'autres outils utilisant Amazon EKSAPI, le type d't3.mediuminstance 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.

  • 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 la section Métadonnées de l'instance et données utilisateur dans le guide de EC2 l'utilisateur Amazon. 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.

Marquage des instances Amazon EC2

Vous pouvez utiliser le TagSpecification paramètre d'un modèle de lancement pour spécifier les balises à appliquer aux EC2 instances Amazon de votre groupe de nœuds. L'IAMentité qui appelle le CreateNodegroup ou UpdateNodegroupVersion APIs doit disposer des autorisations pour ec2:RunInstances etec2: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 les groupes EC2 de sécurité Amazon personnalisés à 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. Toutefois, vous ne pouvez pas créer un modèle de lancement qui spécifie à la fois le niveau de l'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é du Afficher les exigences relatives aux groupes EKS de sécurité Amazon pour les clusters cluster aux instances de votre groupe de nœuds afin de 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 les règles de votre groupe de sécurité sont incorrectes, les nœuds de travail ne peuvent pas rejoindre le cluster. Pour plus d'informations sur les règles de groupe de sécurité, consultez Afficher les exigences relatives aux groupes EKS de sécurité Amazon pour les clusters.

  • Si vous avez besoin SSH d'accéder aux instances de votre groupe de nœuds, incluez un groupe de sécurité qui autorise cet accès.

Données EC2 utilisateur d'Amazon

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 individuelleAMIs. Pour plus d'informations sur les paramètres disponibles pour Bottlerocket, voir Utilisation des données utilisateur sur GitHub.

Vous pouvez fournir des données EC2 utilisateur Amazon dans votre modèle de lancement cloud-init lorsque vous lancez vos instances. Pour plus d’informations, consultez la documentation cloud-init. Vos données utilisateur peuvent être utilisées pour effectuer des opérations de configuration courantes. Elles comprennent :

Les données EC2 utilisateur Amazon 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 MIME plusieurs parties pour Amazon Linux AMIs et TOML au format pour Bottlerocket AMIs. Cela est dû au fait que vos données utilisateur sont fusionnées avec les données EKS utilisateur Amazon requises pour que les nœuds rejoignent le cluster. Ne spécifiez aucune commande démarrant ou modifiant kubelet dans vos données utilisateur. Cela est effectué dans le cadre des données utilisateur fusionnées par AmazonEKS. Certains kubelet paramètres, tels que la définition d'étiquettes sur les nœuds, peuvent être configurés directement via les groupes de nœuds gérésAPI.

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écifier un AMI. Si un AMI identifiant 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 d'Amazon Linux 2

Vous pouvez combiner plusieurs blocs de données utilisateur dans un seul fichier en MIME plusieurs parties. Par exemple, vous pouvez combiner un boothook cloud qui configure Docker daemon avec un script shell de données utilisateur qui installe un package personnalisé. Un fichier en MIME plusieurs parties comprend les éléments suivants :

  • La déclaration de type de contenu et de limite de partie : Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="

  • La déclaration de MIME version — 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.

    • Le contenu des données utilisateur (par exemple, une liste de commandes shell ou de directives cloud-init).

    • La limite de fermeture, qui indique la fin du fichier en MIME plusieurs parties : --==MYBOUNDARY==--

Voici un exemple de fichier en MIME plusieurs parties 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 d'Amazon Linux 2023

Amazon Linux 2023 (AL2023) introduit un nouveau processus d'initialisation des nœuds nodeadm qui utilise un schéma de YAML configuration. Si vous utilisez des groupes de nœuds autogérés ou un modèle AMI 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

Vous définissez généralement cette configuration dans vos données utilisateur, telle quelle ou intégrée dans un document en MIME plusieurs parties :

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

EnAL2, les métadonnées de ces paramètres ont été découvertes lors de l'EKSDescribeClusterAPIappel Amazon. Avec AL2 023, ce comportement a changé car les API appels supplémentaires risquent de se limiter lors de la mise à l'échelle des 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 utilisez Karpenter. Pour plus d'informations sur le service certificateAuthority et les servicescidr, consultez `DescribeCluster` dans le manuel Amazon EKS API Reference.

Bottlerocket données utilisateur

Bottlerocket structure les données utilisateur dans le TOML format. Vous pouvez fournir des données utilisateur à fusionner avec les données utilisateur fournies par AmazonEKS. 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. Vous pouvez configurer les étiquettes et les Prévenir Pods d'être planifié sur des nœuds spécifiques altérations des nœuds 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, le formatage n'est pas préservé, mais le contenu reste le même. La configuration que vous indiquez dans vos données utilisateur remplace tous les paramètres configurés par AmazonEKS. Ainsi, si vous définissez settings.kubernetes.max-pods ousettings.kubernetes.cluster-dns-ip, ces valeurs de vos données utilisateur sont appliquées aux nœuds.

Amazon EKS ne prend pas en charge toutes les versions validesTOML. 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", { name = "Baz", email = "baz@example.com" }]

  • En-têtes entre parenthèses avec clés entre guillemets : [foo."bar.baz"]

Windows données utilisateur

Utilisations des données utilisateur Windows PowerShell commandes. Lorsque vous créez un groupe de nœuds gérés, vos données utilisateur personnalisées sont combinées aux données utilisateur EKS gérées par Amazon. Votre PowerShell les commandes viennent en premier, suivies des commandes de données utilisateur gérées, le tout dans une seule <powershell></powershell> balise.

Note

Lorsqu'aucun AMI identifiant 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 AmazonEKS.

Voici un exemple de données utilisateur.

<powershell>
Write-Host "Running custom user data script"
</powershell>

Spécifier un AMI

Si vous avez l'une des exigences suivantes, spécifiez un AMI ID dans le ImageId champ 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, le bootstrapping permet d'utiliser des arguments 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 le contenu suivant. Remplacez tous example value avec 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. Cela est utile dans les configurations de clusters privés ou dans les clusters où vous augmentez fréquemment le nombre de nœuds entrants et sortants. Pour plus d'informations sur le bootstrap.sh script, consultez le fichier bootstrap.sh sur GitHub.

  • Le seul argument obligatoire est le nom du cluster (my-cluster).

  • Pour récupérer un AMI identifiant optimisé pour ami-1234567890abcdef0, you can use the tables in the following sections:

  • Pour récupérer le certificate-authority pour 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 pour votre cluster, exécutez la commande suivante.

    aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code

  • La valeur pour --dns-cluster-ip est votre service CIDR avec .10 à la fin. Pour récupérer le service-cidr pour votre cluster, exécutez la commande suivante. Par exemple, si la valeur renvoyée pour estipv4 10.100.0.0/16, alors 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 kubelet argument permettant de définir une max-pods valeur personnalisée à l'aide du bootstrap.sh script inclus dans Amazon EKS OptimizedAMI. Le nom du groupe de nœuds ne peut pas comporter plus de 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 lors de la sélection my-max-pods-value, voir Maximum EKS recommandé par Amazon Pods pour chaque type d'EC2instance Amazon.

    ---
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 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 tous example value avec 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. Cela est utile dans les configurations de clusters privés ou dans les clusters où vous augmentez fréquemment le nombre de nœuds entrants et sortants. Pour plus d'informations sur le bootstrap.sh script, consultez le fichier bootstrap.sh sur GitHub.

  • Le seul argument obligatoire est le nom du cluster (my-cluster).

  • Pour récupérer le certificate-authority pour 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 pour votre cluster, exécutez la commande suivante.

    aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code

  • La valeur pour --dns-cluster-ip est votre service CIDR avec .10 à la fin. Pour récupérer le service-cidr pour votre cluster, exécutez la commande suivante. Par exemple, si la valeur renvoyée pour estipv4 10.100.0.0/16, alors 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 kubelet argument permettant de définir une max-pods valeur personnalisée à l'aide du bootstrap.sh script inclus dans Amazon EKS OptimizedAMI. Pour obtenir de l'aide lors de la sélection my-max-pods-value, voir Maximum EKS recommandé par Amazon Pods pour chaque type d'EC2instance Amazon.

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

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 définir une option personnalisée Windows AMIID, 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 le produit que vous souhaitez Windows ID, vous pouvez utiliser le tableau dans Créez des nœuds avec des outils optimisés Windows AMIs Créer des nœuds avec Windows optimiséAMIs.

  • Il existe plusieurs limites et conditions. Par exemple, vous devez ajouter des éléments eks:kube-proxy-windows à la carte de configuration de votre AWS IAM authentificateur. Pour de plus amples informations, veuillez consulter Limites et conditions lors de la spécification d'un AMI identifiant.

Spécifiez les informations suivantes dans la section des données utilisateur de votre modèle de lancement. Remplacez tous example value avec 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 obligatoire est le nom du cluster (my-cluster).

  • Pour récupérer le certificate-authority pour 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 pour votre cluster, exécutez la commande suivante.

    aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code

  • La valeur pour --dns-cluster-ip est votre service CIDR avec .10 à la fin. Pour récupérer le service-cidr pour votre cluster, exécutez la commande suivante. Par exemple, si la valeur renvoyée pour estipv4 10.100.0.0/16, alors 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.

    Note

    Si vous utilisez un service personnaliséCIDR, vous devez le spécifier à l'aide du -ServiceCIDR paramètre. Dans le cas contraire, la DNS résolution pour Pods dans le cluster échouera.

<powershell>
[string]$EKSBootstrapScriptFile = "$env:ProgramFiles\Amazon\EKS\Start-EKSBootstrap.ps1"
& $EKSBootstrapScriptFile -EKSClusterName my-cluster `
	 -Base64ClusterCA certificate-authority `
	 -APIServerEndpoint api-server-endpoint `
	 -DNSClusterIP service-cidr.10
</powershell>

Pour plus d'informations, consultez Amazon Machine Images (AMI) dans le guide de EC2 l'utilisateur Amazon. La spécification de EKS AMI construction Amazon contient des ressources et des scripts de configuration pour créer un Amazon personnalisé EKS AMI basé sur Amazon Linux. Pour plus d'informations, consultez Amazon EKS AMI Build Specification sur GitHub. Pour créer une AMIs installation personnalisée avec d'autres systèmes d'exploitation, consultez Amazon EKS Sample Custom AMIs sur GitHub.

Important

Lorsque vous spécifiez unAMI, Amazon EKS ne fusionne aucune donnée utilisateur. Vous êtes plutôt chargé de fournir les bootstrap commandes requises pour que les nœuds rejoignent le cluster. Si vos nœuds ne parviennent pas à rejoindre le cluster, Amazon EKS CreateNodegroup et UpdateNodegroupVersion les actions échouent également.

Limites et conditions lors de la spécification d'un AMI identifiant

Les limites et conditions associées à la spécification d'un AMI identifiant avec des groupes de nœuds gérés sont les suivantes :

  • Vous devez créer un nouveau groupe de nœuds pour passer de la spécification d'un AMI identifiant dans un modèle de lancement à l'absence d'AMIidentifiant.

  • Vous n'êtes pas averti dans la console lorsqu'une nouvelle AMI version est disponible. Pour mettre à jour votre groupe de nœuds vers une AMI version plus récente, vous devez créer une nouvelle version de votre modèle de lancement avec un AMI identifiant 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 le API si vous spécifiez un AMI ID :

    • amiType

    • releaseVersion

    • version

  • Tous les taints ensembles du API sont appliqués de manière asynchrone si vous spécifiez un AMI ID. 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 dans le Kubernetes .

  • Lorsque vous spécifiez un AMI identifiant personnalisé pour Windows groupes de nœuds gérés, ajoutez-les eks:kube-proxy-windows à votre carte de configuration de l' AWS IAMauthentificateur. Cela est nécessaire DNS pour fonctionner correctement.

    1. Ouvrez la carte de configuration de l' AWS IAMauthentificateur pour la modifier.

      kubectl edit -n kube-system cm aws-auth

    2. Ajoutez cette entrée à la groups liste sous chaque entrée rolearn associée à Windows nœuds. Votre carte de configuration doit ressembler à aws-auth-cm-windows.yaml.

      - eks:kube-proxy-windows

    3. Enregistrez le fichier et quittez votre éditeur de texte.