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.
Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque 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.
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 :
-
Il crée une nouvelle version du modèle de EC2 lancement Amazon 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.
-
Il met à jour le groupe Auto Scaling afin d'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é
updateConfigpour 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 le manuel Amazon EKS API Reference.
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 des zones EC2 de disponibilité d'Amazon. Pour plus d'informations, consultez la section Rebalancing des zones de disponibilité dans le guide de l'utilisateur d'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 :
-
Il augmente la taille maximale du groupe Auto Scaling et la taille souhaitée 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
maxUnavailableest égal à un, le processus de mise à niveau peut lancer un maximum de 10 nœuds. Cependant, lorsqu'ilmaxUnavailableest é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, 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
-
-
-
Il marque les nœuds comme non planifiables pour éviter de planifier de nouveaux pods. Les nœuds
node.kubernetes.io/exclude-from-external-load-balancers=truesont é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.
- EC2 limites d'instances dans votre compte
-
Vous devrez peut-être augmenter le nombre d' EC2 instances Amazon que votre compte peut exécuter simultanément à l'aide de Service Quotas. Pour plus d'informations, consultez la section 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
kubeletne 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, veuillez consulter Spécification d'une AMI. - Toute modification qui rend un nœud défectueux ou n'est 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 met plus de 15 minutes à démarrer et à rejoindre le cluster, la mise à niveau expirera. Il s'agit du temps d'exécution total pour amorcer un nouveau nœud, mesuré entre le moment où un nouveau nœud est requis et le moment où il rejoint le 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 comporte de deux manières différentes, en fonction de la stratégie de mise à jour. Il existe deux stratégies de mise à jour : par défaut et minimale.
Nous recommandons la stratégie par défaut dans la plupart des scénarios. 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. La stratégie minimale est utile dans les scénarios où vous êtes limité en termes de ressources ou de coûts, par exemple avec des accélérateurs matériels tels que. GPUs Il met fin aux anciens nœuds avant d'en créer de nouveaux, de sorte que la capacité totale n'augmente jamais au-delà de la quantité configurée.
La stratégie de mise à jour par défaut comporte les étapes suivantes :
-
Cela augmente le nombre de nœuds (nombre souhaité) dans le groupe Auto Scaling, ce qui oblige le groupe de nœuds à créer des nœuds supplémentaires.
-
Un nœud est sélectionné aléatoirement pour mise à niveau, jusqu'au maximum indisponible configuré pour le groupe de nœuds.
-
Il draine les pods du nœud. Si les Pods ne quittent pas le nœud dans les 15 minutes et qu'aucun indicateur de force n'apparaît, la phase de mise à niveau échoue avec une
PodEvictionFailureerreur. Dans ce scénario, vous pouvez appliquer l'indicateur de force à laupdate-nodegroup-versiondemande de suppression des pods. -
Il boucle le nœud après l'expulsion de chaque pod et attend 60 secondes. Ceci est fait pour que le contrôleur de service n'envoie aucune nouvelle demande à ce nœud et supprime ce nœud 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.
La stratégie de mise à jour minimale comprend 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.
-
Il draine les pods du nœud. Si les Pods ne quittent pas le nœud dans les 15 minutes et qu'aucun indicateur de force n'apparaît, la phase de mise à niveau échoue avec une
PodEvictionFailureerreur. Dans ce scénario, vous pouvez appliquer l'indicateur de force à laupdate-nodegroup-versiondemande de suppression des pods. -
Il boucle le nœud après l'expulsion de chaque pod et attend 60 secondes. Ceci est fait pour que le contrôleur de service n'envoie aucune nouvelle demande à ce nœud et supprime ce nœud de sa liste de nœuds actifs.
-
Une demande d'arrêt est envoyée au groupe Auto Scaling pour le nœud isolé. L'Auto Scaling Group crée un nouveau nœud pour remplacer la capacité manquante.
-
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.
PodEvictionFailureerreurs 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 PDBs pointent vers le même Pod.
- Déploiement tolérant toutes les souillures
-
Une fois que chaque pod est expulsé, on s'attend à ce que le nœud soit vide car il a été contaminé lors
des étapes précédentes. Toutefois, si le déploiement tolère toutes les souillures, le nœud est plus susceptible de ne pas être vide, ce qui entraînera 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.
