Comprendre chaque phase des mises à jour des nœuds - Amazon EKS
Phase de configurationPhase d'augmentation d'échellePhase de mise à niveauPhase de réduction d'échelle

Aidez à améliorer cette page

Pour contribuer à ce guide de l’utilisateur, cliquez sur le lien Modifier cette page sur GitHub qui se trouve dans le volet droit de chaque page.

Comprendre chaque phase des mises à jour des nœuds

La stratégie de mise à jour des composants master d'Amazon EKS comporte quatre phases différentes décrites dans les sections suivantes.

Phase de configuration

La phase de configuration comporte les étapes suivantes :

  1. Une nouvelle version du modèle de lancement Amazon EC2 est créée pour le groupe Auto Scaling associé à votre groupe de nœuds. La nouvelle version du modèle de lancement utilise l'AMI cible ou une version personnalisée du modèle de lancement pour la mise à jour.

  2. Le groupe Auto Scaling est mis à jour pour utiliser la dernière version du modèle de lancement.

  3. La quantité maximale de nœuds à mettre à niveau en parallèle est déterminée à l'aide de la propriété updateConfig pour le groupe de nœuds. Le maximum indisponible a un quota de 100 nœuds. La valeur par défaut est de un nœud. Pour plus d’informations, consultez la propriété updateConfig dans la référence API Amazon EKS.

Phase d'augmentation d'échelle

Lors de la mise à niveau des nœuds d'un groupe de nœuds gérés, les nœuds mis à niveau sont lancés dans la même zone de disponibilité que ceux qui sont mis à niveau. Pour garantir ce placement, nous utilisons le rééquilibrage de la zone de disponibilité d’Amazon EC2. Pour plus d'informations, consultez Rééquilibrage de la zone de disponibilité dans le Guide de l'utilisateur Amazon EC2 Auto Scaling. Pour répondre à cette exigence, il est possible que nous lancions jusqu’à deux instances par zone de disponibilité dans votre groupe de nœuds gérés.

La phase d'augmentation d'échelle comporte les étapes suivantes :

  1. Il augmente la taille maximale et la taille souhaitée du groupe Auto Scaling en fonction de la plus grande des deux valeurs suivantes :

    • Jusqu’à deux fois le nombre de zones de disponibilité dans lesquelles le groupe Auto Scaling est déployé.

    • Le maximum indisponible de la mise à niveau.

      Par exemple, si votre groupe de nœuds a cinq zones de disponibilité et que maxUnavailable est égal à un, le processus de mise à niveau peut lancer un maximum de 10 nœuds. Cependant, lorsque maxUnavailable est égale à 20 (ou supérieure à 10), le processus lance 20 nouveaux nœuds.

  2. Après la mise à l'échelle du groupe Auto Scaling, elle vérifie si les nœuds utilisant la dernière configuration sont présents dans le groupe de nœuds. Cette étape ne réussit que si elle répond à ces critères :

    • Au moins un nouveau nœud est lancé dans chaque zone de disponibilité où le nœud existe.

    • Chaque nouveau nœud doit être dans l'état Ready.

    • Les nouveaux nœuds doivent avoir des étiquettes Amazon EKS appliquées.

      Il s'agit des étiquettes Amazon EKS appliquées sur les composants master d'un groupe de nœuds réguliers :

      • eks.amazonaws.com/nodegroup-image=$amiName

      • eks.amazonaws.com/nodegroup=$nodeGroupName

      Il s'agit des étiquettes appliquées par Amazon EKS sur les composants master dans un modèle de lancement personnalisé ou un groupe de composants AMI :

      • eks.amazonaws.com/nodegroup-image=$amiName

      • eks.amazonaws.com/nodegroup=$nodeGroupName

      • eks.amazonaws.com/sourceLaunchTemplateId=$launchTemplateId

      • eks.amazonaws.com/sourceLaunchTemplateVersion=$launchTemplateVersion

  3. Il marque les nœuds comme non planifiables afin d’éviter la planification de nouveaux pods. Il étiquette également les nœuds avec node.kubernetes.io/exclude-from-external-load-balancers=true afin de supprimer les anciens nœuds des équilibreurs de charge avant de les terminer.

Les raisons suivantes sont connues pour provoquer une erreur NodeCreationFailure dans cette phase :

Capacité insuffisante dans la zone de disponibilité

Il est possible que la zone de disponibilité n'ait pas la capacité des types d'instance demandés. Il est recommandé de configurer plusieurs types d’instances lors de la création d’un groupe de nœuds gérés.

Limites d’instance EC2 sur votre compte

Vous pouvez être amené à augmenter le nombre d'instances Amazon EC2 que votre compte peut exécuter simultanément en utilisant Service Quotas. Pour plus d'informations, consultez EC2 Service Quotas dans le Guide de l'utilisateur Amazon Elastic Compute Cloud pour les instances Linux.

Données utilisateur personnalisées

Les données utilisateur personnalisées peuvent parfois interrompre le processus d'amorçage. Ce scénario peut conduire à ce que le kubelet ne démarre pas sur le nœud ou que les nœuds n'obtiennent pas les étiquettes Amazon EKS attendues. Pour de plus amples informations, consultez Spécification d'une AMI.

Toute modification qui rend un nœud défectueux ou pas prêt

La pression du disque sur le nœud, la pression de la mémoire et des conditions similaires peuvent empêcher un nœud de passer à l'état Ready.

Chaque nœud démarre le plus rapidement en 15 minutes

Si un nœud prend plus de 15 minutes pour démarrer et rejoindre le cluster, cela entraînera l’expiration de la mise à niveau. Il s’agit de la durée totale nécessaire au démarrage d’un nouveau nœud, mesurée à partir du moment où un nouveau nœud est requis jusqu’à son intégration au cluster. Lors de la mise à niveau d’un groupe de nœuds gérés, le compteur de temps démarre dès que la taille du groupe Auto Scaling augmente.

Phase de mise à niveau

La phase de mise à niveau se déroule de deux manières différentes, selon la stratégie de mise à jour. Il existe deux stratégies de mise à jour : par défaut et minimale.

Nous vous recommandons d’utiliser la stratégie par défaut. Il crée de nouveaux nœuds avant de mettre fin aux anciens, afin que la capacité disponible soit maintenue pendant la phase de mise à niveau. Cette stratégie minimale est utile lorsque les ressources ou les coûts sont limités, par exemple avec des accélérateurs matériels tels que des GPU. Il met fin aux anciens nœuds avant d’en créer de nouveaux, afin que la capacité totale ne dépasse jamais la quantité que vous avez configurée.

La stratégie de mise à jour par défaut comprend les étapes suivantes :

  1. Il augmente le nombre de nœuds (nombre souhaité) dans le groupe Auto Scaling, ce qui entraîne la création de nœuds supplémentaires par le groupe de nœuds.

  2. Un nœud est sélectionné aléatoirement pour mise à niveau, jusqu'au maximum indisponible configuré pour le groupe de nœuds.

  3. Il vide les pods du nœud. Si les pods ne quittent pas le nœud dans les 15 minutes et qu’il n’y a pas d’indicateur de force, la phase de mise à niveau échoue avec une erreur PodEvictionFailure. Pour ce scénario, vous pouvez appliquer l’indicateur de force avec la demande update-nodegroup-version de suppression des pods.

  4. Il isole le nœud après chaque expulsion de pod et attend 60 secondes. Cela permet au contrôleur de services de ne pas envoyer de nouvelles requêtes à ce nœud et de le supprimer de sa liste de nœuds actifs.

  5. Une demande d'arrêt est envoyée au groupe Auto Scaling pour le nœud isolé.

  6. Les étapes de mise à niveau précédentes sont répétées jusqu'à ce que le groupe de nœuds ne comporte plus aucun nœud déployé avec la version antérieure du modèle de lancement.

La stratégie de mise à jour minimale comprend les étapes suivantes :

  1. Il isole tous les nœuds du groupe de nœuds au début, afin que le contrôleur de service n’envoie aucune nouvelle requête à ces nœuds.

  2. Un nœud est sélectionné aléatoirement pour mise à niveau, jusqu'au maximum indisponible configuré pour le groupe de nœuds.

  3. Il vide les pods des nœuds sélectionnés. Si les pods ne quittent pas le nœud dans les 15 minutes et qu’il n’y a pas d’indicateur de force, la phase de mise à niveau échoue avec une erreur PodEvictionFailure. Pour ce scénario, vous pouvez appliquer l’indicateur de force avec la demande update-nodegroup-version de suppression des pods.

  4. Une fois que chaque pod a été évincé et a attendu 60 secondes, il envoie une demande de résiliation au groupe Auto Scaling pour les nœuds sélectionnés. Le groupe Auto Scaling crée de nouveaux nœuds (en nombre égal à celui des nœuds sélectionnés) pour remplacer la capacité manquante.

  5. Les étapes de mise à niveau précédentes sont répétées jusqu'à ce que le groupe de nœuds ne comporte plus aucun nœud déployé avec la version antérieure du modèle de lancement.

Erreurs PodEvictionFailure lors de la phase de mise à niveau

Les raisons suivantes sont connues pour provoquer une erreur PodEvictionFailure dans cette phase :

PDB agressif

Un PDB agressif est défini sur le pod ou plusieurs PDB pointent vers le même pod.

Déploiement tolérant tous les rejets

Une fois que tous les pods ont été évacués, le nœud devrait être vide, car il a été rejeté lors des étapes précédentes. Toutefois, si le déploiement tolère toutes les rejets, il est plus probable que le nœud ne soit pas vide, ce qui entraîne l’échec de l’éviction du pod.

Phase de réduction d'échelle

La phase de réduction d'échelle diminue la taille maximale et la taille souhaitée du groupe Auto Scaling d'une unité pour revenir aux valeurs avant le début de la mise à jour.

Si le flux de mise à jour détermine que le Cluster Autoscaler augmente le groupe de nœuds pendant la phase de réduction d'échelle du flux de travail, il se termine immédiatement sans ramener le groupe de nœuds à sa taille d'origine.