Créez une solution autogérée Bottlerocket nœuds - Amazon EKS

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.

Vous souhaitez contribuer à ce guide de l'utilisateur ? Choisissez le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page. 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.

Créez une solution autogérée Bottlerocket nœuds

Note

Les groupes de nœuds gérés peuvent offrir certains avantages pour votre cas d'utilisation. Pour de plus amples informations, veuillez consulter Simplifiez le cycle de vie des nœuds avec des groupes de nœuds gérés.

Cette rubrique explique comment lancer des groupes Auto Scaling de nœuds Bottlerocket enregistrés auprès de votre cluster Amazon EKS. Bottlerocket est un Linuxsystème d'exploitation open source basé sur AWS lequel vous pouvez utiliser pour exécuter des conteneurs sur des machines virtuelles ou des hôtes bare metal. Une fois que les nœuds ont rejoint le cluster, vous pouvez déployer Kubernetes applications qui leur sont adressées. Pour plus d'informations sur Bottlerocket, voir Utilisation d'une AMI Bottlerocket avec Amazon EKS sur GitHub et prise en charge des AMI personnalisées dans la eksctl documentation.

Pour plus d'informations sur les mises à niveau sur place, consultez Bottlerocket Update Operator sur GitHub.

Important
  • Les nœuds Amazon EKS sont EC2 des instances Amazon standard, et ils vous sont facturés sur la base des prix habituels des EC2 instances Amazon. Pour plus d'informations, consultez les EC2 tarifs Amazon.

  • Vous pouvez lancer des nœuds Bottlerocket dans des clusters étendus Amazon EKS sur AWS Outposts, mais vous ne pouvez pas les lancer dans des clusters locaux sur Outposts. AWS Pour de plus amples informations, veuillez consulter Déployez Amazon EKS sur site avec Outposts AWS.

  • Vous pouvez effectuer un déploiement sur EC2 des instances Amazon avec x86 ou Arm processeurs. Toutefois, vous ne pouvez pas effectuer de déploiement sur des instances qui ont Inferentia chips.

  • Bottlerocket est compatible avec AWS CloudFormation. Cependant, aucun CloudFormation modèle officiel ne peut être copié pour être déployé Bottlerocket nœuds pour Amazon EKS.

  • Bottlerocket les images ne sont pas accompagnées d'un SSH un serveur ou un shell. Vous pouvez utiliser des méthodes out-of-band d'accès pour autoriser SSH activer le conteneur d'administration et passer certaines étapes de configuration d'amorçage avec les données utilisateur. Pour plus d'informations, consultez ces sections dans le fichier README.md de bottlerocket sur GitHub:

Cette procédure nécessite eksctl version 0.199.0 ou ultérieure. Vous pouvez vérifier votre version avec la commande suivante :

eksctl version

Pour obtenir des instructions sur l'installation ou la mise à niveaueksctl, consultez la section Installation de la eksctl documentation. Remarque : Cette procédure ne fonctionne que pour les clusters créés avec. eksctl

+. Copiez le contenu suivant sur votre appareil. Remplacez my-cluster par le nom de votre cluster. Un nom ne peut contenir que des caractères alphanumériques (sensibles à la casse) et des traits d'union. Il doit commencer par un caractère alphanumérique et ne doit pas dépasser 100 caractères. Le nom doit être unique dans la AWS région et le AWS compte dans lesquels vous créez le cluster. Remplacer ng-bottlerocket avec un nom pour votre groupe de nœuds. 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 effectuer un déploiement sur des instances Arm, remplacez m5.large par un type d'instance Arm. Remplacez-le my-ec2-keypair-name par le nom d'une paire de clés Amazon EC2 SSH que vous pourrez utiliser pour vous connecter via SSH à vos nœuds après leur lancement. Si vous ne possédez pas encore de paire de EC2 clés Amazon, vous pouvez en créer une dans le AWS Management Console. Pour plus d'informations, consultez les paires de EC2 clés Amazon dans le guide de EC2 l'utilisateur Amazon. Remplacez tous les example values restants par vos propres valeurs. Une fois que vous avez effectué les remplacements, exécutez la commande modifiée pour créer le bottlerocket.yaml fichier.

+ Si vous spécifiez un type d' EC2 instance Arm Amazon, consultez les points à prendre en compte dans Arm Amazon Linux optimisé pour Amazon EKS AMIs avant le déploiement. Pour obtenir des instructions sur le déploiement à l'aide d'une AMI personnalisée, voir Création de Bottlerocket sur GitHub et prise en charge des AMI personnalisées dans la eksctl documentation. Pour déployer un groupe de nœuds gérés, déployez une AMI personnalisée à l'aide d'un modèle de lancement. Pour de plus amples informations, veuillez consulter Personnalisez les nœuds gérés avec des modèles de lancement.

+ IMPORTANT : Pour déployer un groupe de nœuds sur des sous-réseaux AWS Outposts, AWS Wavelength ou AWS Local Zone, ne transmettez pas les sous-réseaux Outposts AWS , AWS Wavelength ou AWS Local Zone lorsque vous créez le cluster. Vous devez spécifier les sous-réseaux dans l'exemple suivant. Pour plus d'informations, consultez Créer un nodegroup à partir d'un fichier de configuration et Schéma du fichier de configuration dans la documentation eksctl. Remplacez region-code par la AWS région dans laquelle se trouve votre cluster.

+

cat >bottlerocket.yaml <<EOF --- apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: my-cluster region: region-code version: '1.31' iam: withOIDC: true nodeGroups: - name: ng-bottlerocket instanceType: m5.large desiredCapacity: 3 amiFamily: Bottlerocket ami: auto-ssm iam: attachPolicyARNs: - arn:aws: iam::aws:policy/AmazonEKSWorkerNodePolicy - arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryReadOnly - arn:aws: iam::aws:policy/AmazonSSMManagedInstanceCore - arn:aws: iam::aws:policy/AmazonEKS_CNI_Policy ssh: allow: true publicKeyName: my-ec2-keypair-name EOF
  1. Deployez vos nœuds avec la commande suivante :

    eksctl create nodegroup --config-file=bottlerocket.yaml

    L'exemple qui suit illustre un résultat.

    Plusieurs lignes sont affichées pendant la création des nœuds. L'une des dernières lignes de sortie est similaire à la ligne d'exemple suivante.

    [✔] created 1 nodegroup(s) in cluster "my-cluster"
  2. (Facultatif) Créez un Kubernetes volume persistant sur un Bottlerocket nœud utilisant le plug-in Amazon EBS CSI. Le pilote Amazon EBS par défaut repose sur des outils de système de fichiers qui ne sont pas inclus dans Bottlerocket. Pour plus d'informations sur la création d'une classe de stockage à l'aide du pilote, consultezStockage Kubernetes volumes avec Amazon EBS.

  3. (Facultatif) Par défaut, kube-proxy définit le paramètre nf_conntrack_max du noyau sur une valeur par défaut qui peut être différente de Bottlerocket se fixe à l'origine au démarrage. À conserver Bottlerocket’s réglage par défaut, edit the `kube-proxy configuration à l'aide de la commande suivante.

    kubectl edit -n kube-system daemonset kube-proxy

    Ajoutez --conntrack-max-per-core et --conntrack-min aux arguments kube-proxy présentés dans l'exemple suivant. Un paramètre de 0 signifie aucun changement.

    containers: - command: - kube-proxy - --v=2 - --config=/var/lib/kube-proxy-config/config - --conntrack-max-per-core=0 - --conntrack-min=0
  4. (Facultatif) Déployez un exemple d'application pour tester votre Bottlerocket nœuds.

  5. Nous vous recommandons de bloquer Pod accès à l'IMDS si les conditions suivantes sont réunies :

    • Vous prévoyez d'attribuer des rôles IAM à tous vos Kubernetes comptes de service afin que Pods disposent uniquement des autorisations minimales dont ils ont besoin.

    • Non Pods dans le cluster, nécessitent l'accès au service de métadonnées d' EC2 instance Amazon (IMDS) pour d'autres raisons, telles que la récupération de la région actuelle AWS .

    Pour plus d'informations, consultez Restreindre l'accès au profil d'instance affecté au composant master.