Comportement de mise à jour des nœuds gérés - Amazon EKS
Phase de configurationPhase d'augmentation d'échellePhase de mise à niveauPhase de réduction d'échelle

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.

Comportement de mise à jour des nœuds gérés

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 d'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. La taille maximale et la taille souhaitée du groupe Auto Scaling sont augmentées 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, lorsqu'il maxUnavailable est égal à 20 (ou à une valeur supérieure à 10), le processus lancera 20 nouveaux nœuds.

  2. Après la mise à l'échelle du groupe Auto Scaling, le processus 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. Les nœuds sont marqués non planifiables pour éviter la planification de nouveaux Pods. Les nœuds node.kubernetes.io/exclude-from-external-load-balancers=true sont également étiquetés pour être supprimés des équilibreurs de charge avant d'être arrêtés.

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 plus d’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.

Phase de mise à niveau

La phase de mise à niveau comporte les étapes suivantes :

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

  2. Les Pods du nœud sont vidé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.

  3. Le nœud est isolé après l'expulsion de chaque Pod et un délai de 60 secondes est observé. 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.

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

  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.

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 il y a plusieurs PDB qui pointent vers le même Pod.

Déploiement tolérant tous les rejets

Une fois que chaque Pod est expulsé, on s'attend à ce que le nœud soit vide, car il a été rejeté lors des étapes précédentes. Toutefois, si le déploiement tolère tous les rejets, il est plus probable que le nœud ne soit pas vide, ce qui entraîne l'échec de l'expulsion 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.