Groupes de nœuds gérés par EKS - Guide de l'utilisateur d'Eksctl
Création de groupes de nœuds gérésMise à niveau des groupes de nœuds gérésGestion des mises à niveau parallèles pour les nœudsMise à jour des groupes de nœuds gérésProblèmes de santé liés à NodegroupGestion des étiquettesDimensionnement des groupes de nœuds gérésPlus d'informations

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.

Groupes de nœuds gérés par EKS

Les groupes de nœuds gérés par Amazon EKS sont une fonctionnalité qui automatise le provisionnement et la gestion du cycle de vie des nœuds (instancesEC2 ) pour les clusters Amazon EKS Kubernetes. Les clients peuvent fournir des groupes de nœuds optimisés pour leurs clusters et EKS tiendra leurs nœuds à jour avec les dernières versions de Kubernetes et du système d'exploitation hôte.

Un groupe de nœuds géré par EKS est un groupe de mise à l'échelle automatique et les EC2 instances associées qui sont gérés par AWS pour un cluster Amazon EKS. Chaque groupe de nœuds utilise l'AMI Amazon Linux 2 optimisée pour Amazon EKS. Amazon EKS permet d'appliquer facilement des corrections de bogues et des correctifs de sécurité aux nœuds, ainsi que de les mettre à jour vers les dernières versions de Kubernetes. Chaque groupe de nœuds lance un groupe de mise à l'échelle automatique pour votre cluster, qui peut couvrir plusieurs zones de disponibilité et sous-réseaux AWS VPC pour garantir une haute disponibilité.

NOUVEAU support du modèle de lancement pour les groupes de nœuds gérés

Note

Le terme « groupes de nœuds non gérés » a été utilisé pour désigner les groupes de nœuds pris en charge par eksctl depuis le début (représentés par le champ). nodeGroups Le ClusterConfig fichier continue d'utiliser le nodeGroups champ pour définir les groupes de nœuds non gérés, et les groupes de nœuds gérés sont définis avec le champ. managedNodeGroups

Création de groupes de nœuds gérés

$ eksctl create nodegroup

Nouveaux clusters

Pour créer un nouveau cluster avec un groupe de nœuds géré, exécutez

eksctl create cluster

Pour créer plusieurs groupes de nœuds gérés et mieux contrôler la configuration, un fichier de configuration peut être utilisé.

Note

Les fonctionnalités des groupes de nœuds gérés ne sont pas totalement équivalentes à celles des groupes de nœuds non gérés.

# cluster.yaml
# A cluster with two managed nodegroups
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: managed-cluster
  region: us-west-2

managedNodeGroups:
  - name: managed-ng-1
    minSize: 2
    maxSize: 4
    desiredCapacity: 3
    volumeSize: 20
    ssh:
      allow: true
      publicKeyPath: ~/.ssh/ec2_id_rsa.pub
      # new feature for restricting SSH access to certain AWS security group IDs
      sourceSecurityGroupIds: ["sg-00241fbb12c607007"]
    labels: {role: worker}
    tags:
      nodegroup-role: worker
    iam:
      withAddonPolicies:
        externalDNS: true
        certManager: true

  - name: managed-ng-2
    instanceType: t2.large
    minSize: 2
    maxSize: 3

Vous trouverez un autre exemple de fichier de configuration pour créer un groupe de nœuds géré ici.

Il est possible d'avoir un cluster avec des groupes de nœuds gérés et non gérés. Les groupes de nœuds non gérés n'apparaissent pas dans la console AWS EKS mais eksctl get nodegroup répertorient les deux types de groupes de nœuds.

# cluster.yaml
# A cluster with an unmanaged nodegroup and two managed nodegroups.
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: managed-cluster
  region: us-west-2

nodeGroups:
  - name: ng-1
    minSize: 2

managedNodeGroups:
  - name: managed-ng-1
    minSize: 2
    maxSize: 4
    desiredCapacity: 3
    volumeSize: 20
    ssh:
      allow: true
      publicKeyPath: ~/.ssh/ec2_id_rsa.pub
      # new feature for restricting SSH access to certain AWS security group IDs
      sourceSecurityGroupIds: ["sg-00241fbb12c607007"]
    labels: {role: worker}
    tags:
      nodegroup-role: worker
    iam:
      withAddonPolicies:
        externalDNS: true
        certManager: true

  - name: managed-ng-2
    instanceType: t2.large
    privateNetworking: true
    minSize: 2
    maxSize: 3

NOUVEAU Support pour les AMI personnalisées, les groupes de sécurité instancePrefixinstanceName,ebsOptimized,volumeType,volumeName,volumeEncrypted,volumeKmsKeyID,,volumeIOPS,maxPodsPerNode,preBootstrapCommands,overrideBootstrapCommand, et disableIMDSv1 

# cluster.yaml
# A cluster with a managed nodegroup with customization.
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: managed-cluster
  region: us-west-2

managedNodeGroups:
  - name: custom-ng
    ami: ami-0e124de4755b2734d
    securityGroups:
      attachIDs: ["sg-1234"]
    maxPodsPerNode: 80
    ssh:
      allow: true
    volumeSize: 100
    volumeName: /dev/xvda
    volumeEncrypted: true
    # defaults to true, which enforces the use of IMDSv2 tokens
    disableIMDSv1: false
    overrideBootstrapCommand: |
      #!/bin/bash
      /etc/eks/bootstrap.sh managed-cluster --kubelet-extra-args '--node-labels=eks.amazonaws.com/nodegroup=custom-ng,eks.amazonaws.com/nodegroup-image=ami-0e124de4755b2734d'

Si vous demandez un type d'instance uniquement disponible dans une zone (et que la configuration eksctl nécessite la spécification de deux), assurez-vous d'ajouter la zone de disponibilité à votre demande de groupe de nœuds :

# cluster.yaml
# A cluster with a managed nodegroup with "availabilityZones"
---

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: flux-cluster
  region: us-east-2
  version: "1.23"

availabilityZones: ["us-east-2b", "us-east-2c"]
managedNodeGroups:
  - name: workers
    instanceType: hpc6a.48xlarge
    minSize: 64
    maxSize: 64
    labels: { "fluxoperator": "true" }
    availabilityZones: ["us-east-2b"]
    efaEnabled: true
    placement:
      groupName: eks-efa-testing

Cela peut être vrai pour des types tels que la famille Hpc6 qui ne sont disponibles que dans une seule zone.

Clusters existants

eksctl create nodegroup --managed

Conseil : si vous utilisez un ClusterConfig fichier pour décrire l'ensemble de votre cluster, décrivez votre nouveau groupe de nœuds gérés managedNodeGroups sur le terrain et exécutez :

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

Mise à niveau des groupes de nœuds gérés

Vous pouvez mettre à jour un groupe de nœuds vers la dernière version d'AMI optimisée pour EKS pour le type d'AMI que vous utilisez à tout moment.

Si votre groupe de nœuds possède la même version de Kubernetes que le cluster, vous pouvez effectuer la mise à jour vers la dernière version de l'AMI correspondant à cette version de Kubernetes du type d'AMI que vous utilisez. Si votre groupe de nœuds est la version précédente de Kubernetes par rapport à la version Kubernetes du cluster, vous pouvez mettre à jour le groupe de nœuds vers la dernière version de l'AMI qui correspond à la version Kubernetes du groupe de nœuds, ou le mettre à jour vers la dernière version de l'AMI correspondant à la version Kubernetes du cluster. Vous ne pouvez pas restaurer un groupe de nœuds vers une version antérieure de Kubernetes.

Pour mettre à niveau un groupe de nœuds géré vers la dernière version de l'AMI :

eksctl upgrade nodegroup --name=managed-ng-1 --cluster=managed-cluster

Le groupe de nœuds peut être mis à niveau vers la dernière version de l'AMI pour une version spécifiée de Kubernetes en utilisant :

eksctl upgrade nodegroup --name=managed-ng-1 --cluster=managed-cluster --kubernetes-version=<kubernetes-version>

Pour effectuer une mise à niveau vers une version spécifique de l'AMI plutôt que vers la dernière version, passez --release-version :

eksctl upgrade nodegroup --name=managed-ng-1 --cluster=managed-cluster --release-version=1.19.6-20210310
Note

Si les nœuds gérés sont déployés de manière personnalisée AMIs, le flux de travail suivant doit être suivi afin de déployer une nouvelle version de l'AMI personnalisée.

  • le déploiement initial du groupe de nœuds doit être effectué à l'aide d'un modèle de lancement. par exemple

    managedNodeGroups:
  - name: launch-template-ng
    launchTemplate:
      id: lt-1234
      version: "2" #optional (uses the default version of the launch template if unspecified)

  • créer une nouvelle version de l'AMI personnalisée (à l'aide de la console AWS EKS).

  • créer une nouvelle version du modèle de lancement avec le nouvel ID AMI (à l'aide de la console AWS EKS).

  • mettez à niveau les nœuds vers la nouvelle version du modèle de lancement. par exemple

    eksctl upgrade nodegroup --name nodegroup-name --cluster cluster-name --launch-template-version new-template-version

Gestion des mises à niveau parallèles pour les nœuds

Plusieurs nœuds gérés peuvent être mis à niveau simultanément. Pour configurer les mises à niveau parallèles, définissez le nom updateConfig d'un groupe de nœuds lors de la création du groupe de nœuds. Un exemple updateConfig peut être trouvé ici.

Pour éviter toute interruption de vos charges de travail due à la mise à niveau simultanée de plusieurs nœuds, vous pouvez limiter le nombre de nœuds susceptibles de devenir indisponibles lors d'une mise à niveau en le spécifiant dans le maxUnavailable champ d'unupdateConfig. Vous pouvez également utilisermaxUnavailablePercentage, qui définit le nombre maximum de nœuds indisponibles en pourcentage du nombre total de nœuds.

Notez qu'il maxUnavailable ne peut pas être supérieur àmaxSize. De plus, maxUnavailable et maxUnavailablePercentage ne peut pas être utilisé simultanément.

Cette fonctionnalité n'est disponible que pour les nœuds gérés.

Mise à jour des groupes de nœuds gérés

eksctlpermet de mettre à jour la UpdateConfigsection d'un groupe de nœuds géré. Cette section définit deux champs. MaxUnavailableetMaxUnavailablePercentage. Vos groupes de nœuds ne sont pas affectés lors de la mise à jour, il ne faut donc pas s'attendre à une interruption de service.

La commande update nodegroup doit être utilisée avec un fichier de configuration utilisant le --config-file drapeau. Le groupe de nœuds doit contenir une nodeGroup.updateConfig section. Vous trouverez plus d'informations ici.

Problèmes de santé liés à Nodegroup

EKS Managed Nodegroups vérifie automatiquement la configuration de votre groupe de nœuds et de vos nœuds pour détecter tout problème de santé et les signale via l'API et la console EKS. Pour consulter les problèmes de santé d'un groupe de nœuds :

eksctl utils nodegroup-health --name=managed-ng-1 --cluster=managed-cluster

Gestion des étiquettes

EKS Managed Nodegroups permet de joindre des étiquettes qui sont appliquées aux nœuds Kubernetes du groupe de nœuds. Ceci est spécifié via le labels champ dans eksctl lors de la création du cluster ou du groupe de nœuds.

Pour définir de nouvelles étiquettes ou mettre à jour des étiquettes existantes sur un groupe de nœuds :

eksctl set labels --cluster managed-cluster --nodegroup managed-ng-1 --labels kubernetes.io/managed-by=eks,kubernetes.io/role=worker

Pour annuler ou supprimer les libellés d'un groupe de nœuds :

eksctl unset labels --cluster managed-cluster --nodegroup managed-ng-1 --labels kubernetes.io/managed-by,kubernetes.io/role

Pour afficher toutes les étiquettes définies sur un groupe de nœuds :

eksctl get labels --cluster managed-cluster --nodegroup managed-ng-1

Dimensionnement des groupes de nœuds gérés

eksctl scale nodegroupprend également en charge les groupes de nœuds gérés. La syntaxe pour le dimensionnement d'un groupe de nœuds géré ou non géré est la même.

eksctl scale nodegroup --name=managed-ng-1 --cluster=managed-cluster --nodes=4 --nodes-min=3 --nodes-max=5

Plus d'informations