À propos des mises à jour de surutilisation

Ce document présente brièvement les mises à jour progressives standards, puis décrit en détail les mises à jour de surutilisation, qui sont un type particulier de mise à jour progressive. Contrairement aux mises à jour progressives standards, les mises à jour de surutilisation vous permettent de configurer la vitesse de la mise à jour. Les mises à jour de surutilisation vous permettent également de contrôler l'impact des mises à jour perturbatrices sur vos charges de travail.

Pour plus d'informations sur l'activation et la configuration des mises à jour de surutilisation pour GKE sur AWS, consultez Configurer les mises à jour de surutilisation des pools de nœuds.

Fonctionnement des mises à jour progressives standards

Certaines mises à jour d'un pool de nœuds, par exemple la modification des annotations d'un pool de nœuds, ne nécessitent pas le redémarrage des nœuds et ne déclenchent donc pas de mise à jour progressive. Si GKE sur AWS peut appliquer des modifications à un pool de nœuds sans avoir à redémarrer ou recréer des ressources, cette option est privilégiée pour éviter toute interruption.

Toutefois, la plupart des mises à jour d'un pool de nœuds dans GKE sur AWS impliquent généralement d'arrêter les nœuds existants et de lancer de nouveaux nœuds avec les paramètres mis à jour. Le processus d'arrêt des nœuds existants peut perturber les charges de travail.

Par défaut, GKE sur AWS effectue des mises à jour progressives standards. Cette méthode met à jour les nœuds un à la fois, après quoi ils sont remplacés avec une approche "arrêter avant de créer" : un nœud est arrêté, puis un nouveau nœud mis à jour est démarré. Cela minimise les perturbations, car les nœuds sont interrompus puis remplacés un à la fois.

Voici les étapes suivies par GKE sur AWS lors d'une mise à jour progressive standard :

  1. Sélectionne un nœud du pool de nœuds et le marque comme indisponible pour s'assurer qu'aucun nouveau pod ne démarre dessus. On dit que le nœud a été marqué comme non programmable.
  2. Déplace les pods actifs du nœud marqué comme non programmable vers d'autres nœuds disponibles dans le cluster. Si d'autres nœuds disposent d'une capacité suffisante, ils accueillent les pods évincés. Dans le cas contraire, l'autoscaler du cluster, qui reste actif lors d'une mise à jour progressive standard, démarre une mise à l'échelle et provisionne des nœuds supplémentaires afin de garantir une capacité suffisante pour planifier les pods expulsés. Pour en savoir plus sur les mesures prises pour protéger les charges de travail au cours de ce processus, consultez la section Protection des charges de travail lors du redimensionnement.
  3. Arrête le nœud marqué comme non programmable.
  4. Remplace le nœud marqué comme non programmable par un nouveau nœud avec les paramètres mis à jour.
  5. Effectue une vérification d'état sur le nouveau nœud opérationnel. Si le pool de nœuds échoue à la vérification d'état, il est marqué à l'état DEGRADED. Cet état peut être affiché en exécutant la commande gcloud container aws node-pools describe. Lorsqu'un pool de nœuds est marqué comme DEGRADED, il est possible que les nouveaux pods ne soient pas planifiés sur les nœuds de ce pool.
  6. Les mises à jour se poursuivent nœud par nœud, jusqu'à ce que tous les nœuds du pool soient mis à jour.

Fonctionnement des mises à jour de surutilisation

Dans GKE sur AWS, la méthode de déploiement progressif standard met à jour les nœuds un par un. Les mises à jour de surutilisation, qui sont une forme de mise à jour progressive, vous permettent de mettre à jour plusieurs nœuds simultanément. Les mises à jour de surutilisation sont donc plus rapides que les mises à jour progressives standards. Toutefois, la mise à jour simultanée de plusieurs nœuds peut perturber les charges de travail. Pour limiter ce problème, les mises à jour de surutilisation offrent des options permettant de moduler le niveau de perturbation de vos charges de travail.

La façon dont les nœuds sont remplacés est une autre différence entre les mises à jour de surutilisation et les mises à jour progressives standards. Les mises à jour progressives standards remplacent les nœuds en utilisant une stratégie de type "arrêter avant de créer". Selon les paramètres que vous choisissez, les mises à jour de surutilisation utilisent une stratégie de type "arrêter avant de créer", une stratégie de type "créer avant d'arrêter", ou une combinaison des deux.

L'autoscaler de cluster joue un rôle plus important dans les mises à jour de surutilisation que dans les mises à jour progressives standards, c'est pourquoi il occupe une place prépondérante dans la liste des actions entreprises par GKE sur AWS lors d'une mise à jour de surutilisation :

  1. Création d'un groupe d'autoscaling : GKE sur AWS provisionne de nouveaux nœuds avec les modifications spécifiées par la commande "update" et attribue ces nouveaux nœuds à un nouveau groupe d'autoscaling (ASG) AWS.
  2. Comportement de l'autoscaler de cluster : lorsque la mise à jour de surutilisation commence, l'autoscaler de cluster est activé pour le nouveau groupe d'autoscaling. L'autoscaler de cluster est désactivé pour le groupe d'autoscaling d'origine. Cela garantit que les opérations de scaling ne ciblent que le nouveau groupe.
  3. Remplacement des nœuds : selon les paramètres de mise à jour de surutilisation, différentes stratégies de remplacement des nœuds sont utilisées :
    • "créer avant d'arrêter" : cette stratégie est activée lorsque le paramètre max-surge-update est défini sur une valeur supérieure à zéro. Elle génère de nouveaux nœuds dans le nouvel ASG avant d'arrêter les anciens nœuds dans l'ASG d'origine, afin de minimiser les interruptions de service.
    • "arrêter avant de créer" : cette méthode est déclenchée lorsque le paramètre max-surge-update est défini sur zéro et que la valeur du paramètre max-unavailable-update est supérieure à zéro. Les nœuds de l'ASG d'origine sont d'abord arrêtés, puis de nouveaux nœuds sont créés dans le nouvel ASG.
  4. Ajustements de la taille du pool de nœuds : lors de la mise à jour, la taille du pool de nœuds (c'est-à-dire, la somme des nœuds dans l'ancien et le nouvel ASG) peut fluctuer au dessus ou en dessous du nombre initial de nœuds présents dans le pool de nœuds avant le début de la mise à jour. Plus précisément, GKE sur AWS vise à maintenir nombre de nœuds compris dans la plage de (original_count - max-unavailable-update) à (original_count + max-surge-update). Au final, les nœuds de l'ancien ASG (original_count) sont remplacés par des nœuds mis à jour dans le nouvel ASG. L'autoscaler de cluster peut lancer davantage de nœuds dans le nouveau groupe ASG s'il détecte que les pods ne peuvent pas être programmés. Il reste toutefois dans les limites définies par min-nodes et max-nodes.

Un exemple pour illustrer le processus

Pour mieux comprendre le fonctionnement des mises à jour de surutilisation, prenons l'exemple suivant. Supposons que vous disposiez d'un pool de cinq nœuds et que vous exécutiez la commande suivante :

  gcloud container aws node-pools update production-node-pool
      --cluster my-cluster \
      --location us-west1 \
      --max-surge-update 2 \
      --max-unavailable-update 1 \
      --node-version 1.27.6-gke.700

Dans cet exemple, max-surge-update est défini sur 2, max-unavailable-update est défini sur 1 et vous fournissez une nouvelle version du pool de nœuds (c'est-à-dire que vous modifiez la version de GKE qui s'exécute sur les nœuds du pool de nœuds).

L'exécution de cette commande déclenche une mise à jour de surutilisation, et GKE sur AWS effectue les actions suivantes :

  1. Crée deux nœuds supplémentaires, car la valeur de max-surge-update est égale à 2.
  2. Attribue ces deux nœuds supplémentaires à un nouveau groupe d'autoscaling AWS.
  3. Supprime les nœuds du groupe d'autoscaling d'origine une fois que ces nouveaux nœuds sont opérationnels. GKE sur AWS arrête jusqu'à trois nœuds (la valeur combinée de max-surge-update et max-unavailable-update), mais garantit qu'un seul nœud devient indisponible à tout moment (en raison de la valeur de max-unavailable-update qui est définie sur 1).
  4. Ces étapes sont répétées jusqu'à ce que tous les nœuds du pool aient été mis à jour vers la nouvelle version de GKE.

Au cours de cette mise à jour, le pool de nœuds contient entre quatre et sept nœuds opérationnels.

Points à prendre en compte avant d'exécuter des mises à jour de surutilisation

Avant d'exécuter une mise à jour de surutilisation, tenez compte des points suivants :

  • Les instances supplémentaires créées lors de cette étape de surutilisation peuvent potentiellement dépasser votre limite de quota d'instances AWS. Si vous ne disposez pas d'un quota suffisant et que les instances supplémentaires ne peuvent pas être provisionnées, la mise à jour peut échouer.
  • Si max-unavailable-update est défini sur 0, des perturbations au niveau des charges de travail peuvent toujours survenir lorsque les pods sont évincés et reprogrammés sur des nœuds plus récents.
  • Le nombre maximal de nœuds pouvant être mis à jour simultanément est égal à la somme de max-surge-update et de max-unavailable-update, et est limité à 20.

Choisir les paramètres de surutilisation adaptés à vos besoins

Bien que les mises à jour progressives standards aient souvent recours à l'approche "arrêter avant de créer", les mises à jour de surutilisation offrent plus de flexibilité. En fonction de la configuration, les mises à jour de surutilisation peuvent suivre une stratégie "créer avant d'arrêter", une stratégie "arrêter avant de créer" ou une combinaison des deux. Cette section décrit différentes configurations pour vous aider à choisir la meilleure approche pour vos charges de travail.

Le tableau suivant présente trois exemples de paramètres et souligne leur impact sur la vitesse de la mise à jour ainsi que sur les perturbations potentielles de vos charges de travail :

Nom Description Configuration
Paramètre équilibré (valeur par défaut) Équilibré, plus lent mais moins perturbateur. maxSurge=1, maxUnavailable=0
Mises à jour rapides sans ressources supplémentaires Rapide, sans ressources de surutilisation, le plus perturbateur. maxSurge=0, maxUnavailable=20
Mises à jour rapides et moins perturbatrices Rapide, avec le plus de ressources de surutilisation, moins perturbateur maxSurge=20, maxUnavailable=0

Chacun des paramètres du tableau est décrit dans les sections suivantes.

Paramètre équilibré (valeur par défaut)

Le moyen le plus simple d'utiliser les mises à jour de surutilisation consiste à utiliser la configuration par défaut de max-surge-update=1 et max-unavailable-update=0. Cette configuration ajoute un seul nœud de surutilisation au pool de nœuds lors de la mise à jour, et un seul nœud est mis à jour à la fois, à la suite d'une approche "créer avant d'arrêter". Par rapport à la mise à jour progressive standard sans surutilisation, qui équivaut à (max-surge-update=0, max-unavailable-update=1), cette méthode est moins perturbatrice, accélère les redémarrages de pod lors des mises à jour et est plus conservatrice dans sa progression.

Il est important de noter qu'utiliser le paramètre équilibré peut entraîner une augmentation des coûts en raison du nœud de surutilisation temporaire ajouté lors de la mise à jour. Ce nœud supplémentaire entraîne des frais lorsqu'il est actif, ce qui augmente légèrement les dépenses globales par rapport aux méthodes sans nœuds de surutilisation.

Mises à jour rapides sans ressources supplémentaires

Pour les charges de travail qui peuvent tolérer des interruptions, une approche de mise à jour plus rapide peut être appropriée. Configurer max-surge-update=0 et max-unavailable-update=20 permet d'obtenir ce résultat. Cette configuration permet de mettre à jour 20 nœuds simultanément sans ajouter de nœuds de surutilisation. Cette méthode de mise à jour suit une approche de type "arrêter avant de créer". Comme aucun nœud de surutilisation supplémentaire n'est introduit, cette méthode est également la plus rentable, car elle permet d'éviter les frais supplémentaires associés à des nœuds temporaires.

Mises à jour rapides et moins perturbatrices

Si vos charges de travail sont sensibles aux perturbations, vous pouvez accélérer la mise à jour à l'aide des paramètres suivants : max-surge-update=20 et max-unavailable-update=0. Cette configuration met à jour 20 nœuds en parallèle avec l'approche "créer avant d'arrêter".

Toutefois, la vitesse globale de la mise à jour peut être limitée si vous avez configuré PodDisruptionBudgets (PDB) pour vos charges de travail. En effet, le PDB limite le nombre de pods qui peuvent être vidés à un moment donné. Bien que les configurations des PDB puissent varier, si vous créez un PDB avec maxUnavailable égal à 1 pour une ou plusieurs charges de travail exécutées sur le pool de nœuds, un seul pod de ces charges de travail peut être supprimé à la fois, ce qui limite le parallélisme de la mise à niveau.

Rappeler que le lancement de plusieurs nœuds de surutilisation au début du processus de mise à jour peut entraîner une augmentation temporaire des coûts, en particulier par rapport des configurations qui n'ajoutent pas de nœuds supplémentaires ou qui ajoutent moins de nœuds lors des mises à jour.

Étapes suivantes

Pour plus d'informations sur l'activation et la configuration des mises à jour de surutilisation pour GKE sur AWS, consultez Configurer les mises à jour de surutilisation des pools de nœuds.