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 :
-
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.
-
Le groupe Auto Scaling est mis à jour pour utiliser la dernière version du modèle de lancement.
-
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 :
-
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'ilmaxUnavailable
est égal à 20 (ou à une valeur supérieure à 10), le processus lancera 20 nouveaux nœuds.
-
-
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
-
-
-
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 :
-
Un nœud est sélectionné aléatoirement pour mise à niveau, jusqu'au maximum indisponible configuré pour le groupe de nœuds.
-
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 demandeupdate-nodegroup-version
de suppression des Pods. -
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.
-
Une demande d'arrêt est envoyée au groupe Auto Scaling pour le nœud isolé.
-
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.