À propos du séquençage du déploiement avec des étapes personnalisées

Vous pouvez gérer l'ordre des mises à niveau automatiques des clusters Google Kubernetes Engine (GKE) dans plusieurs environnements à l'aide du séquençage du déploiement. Par exemple, vous pouvez qualifier une nouvelle version dans des clusters de préproduction avant de mettre à niveau les clusters de production. GKE fournit également une version antérieure de cette fonctionnalité, le séquencement du déploiement basé sur le parc, qui offre des fonctionnalités plus limitées et n'est pas recommandée pour les nouveaux environnements.

Ce document suppose que vous connaissez les éléments suivants :

Pour configurer une séquence de déploiement, consultez Séquencer le déploiement des mises à niveau des clusters avec des étapes personnalisées.

Présentation

Le séquençage du déploiement GKE vous permet de définir une séquence spécifique et ordonnée pour les mises à niveau des clusters dans différents environnements (par exemple, en mettant à niveau d'abord les clusters de l'environnement de développement, puis ceux de l'environnement de test et enfin ceux de production). Cette stratégie progressive offre un temps de préparation intégré, ce qui vous permet de découvrir et d'atténuer les problèmes potentiels avant que la mise à niveau n'atteigne vos systèmes les plus critiques.

Le séquençage des déploiements repose sur le concept de parc, qui est un regroupement logique de clusters GKE mappés à un environnement (par exemple, le test). Pour utiliser cette fonctionnalité, vous devez définir une séquence composée de parcs et définir le temps de stabilisation entre chaque groupe. Lorsque GKE sélectionne une nouvelle version, vos clusters sont mis à niveau dans l'ordre défini, ce qui vous permet de valider les charges de travail avant que la version ne soit entièrement déployée dans votre environnement de production.

Les parcs sont compatibles avec les appartenances légères, qui vous permettent de regrouper logiquement les clusters pour le séquençage du déploiement sans activer toutes les configurations et fonctionnalités au niveau du parc. L'appartenance simplifiée est un bon choix si vous souhaitez utiliser le déploiement séquentiel sans certaines des autres implications de la gestion complète du parc, comme l'uniformité de l'espace de noms au niveau du parc. Pour en savoir plus, consultez Abonnements simplifiés.

Choisir une stratégie de déploiement séquentiel

GKE propose deux versions du séquençage du déploiement. Les deux versions sont basées sur les mêmes principes de base de mises à niveau progressives par parc. Toutefois, nous vous recommandons d'utiliser le séquençage du déploiement avec des étapes personnalisées pour les nouveaux environnements :

  • Séquence de déploiement avec des étapes personnalisées (recommandée pour les nouveaux environnements) : cette version est une évolution du modèle basé sur le parc. Elle offre un contrôle et une flexibilité plus précis, mais ne prend pas en charge la console Cloud de Confiance . Les étapes personnalisées vous permettent de définir des étapes spécifiques au sein d'un parc à l'aide d'étiquettes. Elles sont donc idéales pour les stratégies de déploiement plus complexes, comme le déploiement d'une nouvelle version sur un petit sous-ensemble de clusters de production avant un déploiement plus large. Vous avez également plus de contrôle sur les déploiements. Par exemple, vous pouvez lancer un déploiement vers une version spécifique, choisir les types de mises à niveau à déployer dans une séquence, et mettre en pause ou annuler des déploiements. Choisissez cette option si vous créez une séquence de déploiement pour la première fois.
  • Séquence de déploiement basée sur le parc : il s'agit de la seule version de cette fonctionnalité utilisable avec la console Cloud de Confiance . Elle offre toutefois des fonctionnalités plus limitées et n'est pas recommandée si vous créez une séquence de déploiement pour la première fois.

Le reste de ce document ne concerne que le déploiement séquentiel avec des étapes personnalisées.

Séquençage du déploiement avec des étapes personnalisées

Lorsque vous utilisez le séquencement du déploiement avec des étapes personnalisées, vous définissez l'ordre des mises à niveau de la flotte et définissez les temps de stabilisation. Vous pouvez également effectuer les opérations suivantes :

  • Définissez une séquence avec des étapes précises qui peuvent cibler des sous-ensembles spécifiques de clusters au sein d'un parc à l'aide d'étiquettes. C'est donc un bon choix pour les stratégies telles que les déploiements progressifs.
  • Bénéficiez d'un contrôle et d'une observabilité accrus grâce aux nouveaux objets d'API RolloutSequence et Rollout.

Cette méthode offre la plus grande flexibilité et le contrôle le plus précis sur les mises à niveau de votre cluster. Pour cibler des sous-ensembles spécifiques de clusters au sein d'un parc, vous utilisez un label-selector pour cibler uniquement les clusters qui comportent des étiquettes Kubernetes spécifiques.

Le schéma suivant montre comment GKE met automatiquement à niveau les clusters dans une séquence de déploiement qui utilise des étapes personnalisées. L'étape cible les clusters avec un label-selector nommé canary dans le parc prod :

Séquence de déploiement avec des étapes personnalisées dans GKE.
Figure  : Séquence de déploiement avec des étapes personnalisées

Lorsque GKE déploie une nouvelle version, il met d'abord à niveau les clusters de la flotte de test, puis ceux de la flotte de préproduction. Ensuite, dans le parc de production, GKE donne la priorité aux clusters qui correspondent à label-selector. Comme prod-cluster-1 est libellé avec canary: true, GKE met à niveau ce cluster en premier. GKE met à niveau tous les clusters restants du parc de production (dans l'étape principale) à la fin du processus, car cette étape ne comporte aucun sélecteur d'étiquette.

Pendant la période de stabilisation configurée entre les étapes, vous pouvez vérifier que vos charges de travail s'exécutent comme prévu sur les clusters mis à niveau. L'exemple précédent montre une étape personnalisée dans le parc de production, mais vous pouvez ajouter plusieurs étapes à n'importe quel parc ou n'utiliser qu'un seul parc avec plusieurs étapes.

Concepts clés

  • Temps de stabilisation : période d'attente configurable qui se produit une fois que tous les clusters d'une étape ont été mis à niveau. Ce temps de trempage vous permet de valider la nouvelle version dans un environnement et de détecter les problèmes potentiels avant que la mise à niveau ne passe à l'environnement suivant. Vous pouvez configurer un temps de stabilisation allant jusqu'à 30 jours pour chaque étape de votre séquence. Une période de stabilisation plus longue en phase de préproduction vous donne plus de temps pour la validation.
  • RolloutSequence : cet objet est la ressource principale que vous utilisez pour définir votre séquence de mise à niveau. RolloutSequence contient une série ordonnée d'étapes, qui vérifie que les clusters des étapes précédentes sont entièrement mis à niveau et ont terminé leur période de stabilisation avant que la mise à niveau ne passe à l'étape suivante. Chaque RolloutSequence possède un Rollout pour chaque nouvelle version déployée.
  • Rollout : cet objet vous permet d'observer la progression de la mise à niveau d'une seule version dans votre séquence. Vous pouvez utiliser Rollout pour afficher l'état du déploiement, suivre sa progression et voir si des clusters ne sont pas éligibles à la mise à niveau et pourquoi. Chaque Rollout est associé à un RolloutSequence spécifique représentant la séquence de déploiement de la version.
  • Projet hôte dédié : nous vous recommandons d'utiliser un projetCloud de Confiance by S3NS dédié pour héberger vos objets RolloutSequence. Placer la séquence dans un projet dédié fournit un point de contrôle neutre et central pour vos séquences de déploiement, ce qui constitue une bonne pratique similaire pour la gestion des pipelines CI/CD.
Bonne pratique :

Créez et gérez vos ressources RolloutSequence dans un projet hôte dédié.

  • Étapes : une étape est une étape de la séquence de déploiement. Chaque étape contient un groupe de clusters qui sont mis à niveau ensemble.
  • Parcs : les parcs sont le principal moyen de regrouper les clusters. Une étape d'une séquence de déploiement ne peut faire référence qu'à un seul parc.
  • Sélecteurs de libellés : une séquence de déploiement est composée d'une ou de plusieurs étapes. Chaque étape contient des clusters d'un parc. Vous pouvez utiliser des sélecteurs de libellés sur les clusters pour diviser un parc en plusieurs étapes. Cette approche permet d'utiliser des stratégies telles que les déploiements progressifs, où un petit sous-ensemble de clusters de production est mis à niveau en premier.

Comment GKE met-il à niveau les clusters dans une séquence de déploiement ?

Lorsque GKE met à niveau un cluster, d'abord le plan de contrôle, puis les nœuds sont mis à niveau. Dans une séquence de déploiement, les clusters sont toujours mis à niveau à l'aide de ce processus, mais vous contrôlez également l'ordre dans lequel les groupes (parcs) de clusters sont mis à niveau. Vous spécifiez également un temps de stabilisation qui définit la durée pendant laquelle GKE observe une pause avant que les mises à niveau ne passent d'un groupe au groupe suivant.

Les mises à niveau des clusters dans une séquence de déploiement se déroulent de la façon suivante :

  1. GKE lance un nouveau déploiement dans la séquence de déploiement. Par défaut, un déploiement démarre lorsque GKE définit une nouvelle cible de mise à niveau automatique pour les clusters d'une version mineure dans un version disponible spécifique. Pour le déploiement séquentiel avec des étapes personnalisées, vous pouvez également déclencher un nouveau déploiement dans une séquence de déploiement vers une version spécifique de votre choix.

  2. GKE commence à mettre à niveau les plans de contrôle de cluster vers la nouvelle version dans le premier groupe de clusters. Une fois que GKE a mis à niveau le plan de contrôle d'un cluster, il commence à mettre à niveau les nœuds du cluster. GKE respecte la disponibilité de la maintenance lors de la mise à niveau des clusters dans une séquence de déploiement.

  3. GKE effectue les étapes suivantes pour les mises à niveau du plan de contrôle :

    1. Une fois que toutes les mises à niveau du plan de contrôle du cluster dans le premier groupe sont terminées, GKE lance la période de stabilisation pour les mises à niveau du plan de contrôle. GKE lance également la période de stabilisation si plus de 30 jours se sont écoulés depuis le début des mises à niveau du plan de contrôle.

    2. Une fois la période de stabilisation terminée pour les mises à niveau du plan de contrôle du cluster du premier groupe, GKE commence à mettre à niveau les plans de contrôle du deuxième groupe vers la nouvelle version. Notez toutefois les points suivants :

      • Dans certains cas, GKE peut mettre à niveau les plans de contrôle des clusters du premier groupe plusieurs fois avant de mettre à niveau ceux du deuxième groupe. Dans ce cas, GKE choisit la dernière version qui présente également les attributs suivants :
        • La version est qualifiée par le premier groupe.
        • La version est au maximum une version mineure ultérieure à la version du plan de contrôle des clusters du deuxième groupe.
      • GKE ne met pas à niveau le plan de contrôle des clusters du deuxième groupe qui ont une version plus récente que celle qualifiée par le premier groupe.

  4. Parallèlement aux mises à niveau du plan de contrôle, GKE effectue les étapes suivantes pour les mises à niveau des nœuds :

    1. Une fois que toutes les mises à niveau des nœuds du premier groupe sont terminées, GKE lance la période de stabilisation pour les mises à niveau des nœuds. GKE lance également la période de stabilisation si plus de 30 jours se sont écoulés depuis le début des mises à niveau des nœuds.
    2. Une fois la période de stabilisation pour les mises à niveau des nœuds du premier groupe terminée, GKE commence à mettre à niveau les nœuds du deuxième groupe vers la nouvelle version. Toutefois, veuillez noter les points suivants :
      • Dans certains cas, GKE peut mettre à niveau les nœuds de cluster du premier groupe plusieurs fois avant de mettre à niveau ceux du deuxième groupe. Dans ce cas, GKE choisit la dernière version qui présente également les attributs suivants :
        • La version est qualifiée par le premier groupe.
        • La version n'est pas postérieure à la version du plan de contrôle du cluster du deuxième groupe.
      • GKE ne met pas à niveau les nœuds des clusters du deuxième groupe qui ont une version ultérieure à celle qualifiée par le premier groupe.

  5. GKE répète ces étapes du deuxième au troisième groupe, jusqu'à ce que les clusters de tous les groupes de la séquence de déploiement aient été mis à niveau vers la nouvelle version.

Pendant que les clusters de chaque groupe sont mis à niveau, vérifiez pendant le temps de stabilisation que vos charges de travail avec les clusters exécutant la nouvelle version de GKE fonctionnent comme prévu.

Les mises à niveau des clusters peuvent également être bloquées en raison d'exclusions ou d'intervalles de maintenance, de l'utilisation d'une API obsolète ou pour d'autres raisons.

Contrôler les mises à niveau dans une séquence de déploiement

Avec les mises à niveau séquentielles d'un cluster, les groupes de clusters sont mis à niveau dans l'ordre que vous avez défini et sont stabilisés dans chaque groupe pendant la durée que vous avez choisie. Pour en savoir plus sur le contrôle de ce processus, consultez les ressources suivantes :

Exemple : la banque communautaire déploie progressivement les modifications des tests en production.

L'administrateur de plate-forme d'une banque communautaire gère trois environnements de déploiement principaux : test, préproduction et production. Les clusters de production sont répartis sur plusieurs régions, avec différents niveaux de criticité. Pour gérer efficacement les mises à niveau, l'administrateur regroupe les clusters de chaque environnement dans des parcs. Comme cela est nécessaire pour le séquençage du déploiement, chaque cluster des trois parcs est enregistré dans le même version disponible (dans ce cas, le canal standard) et tous les clusters exécutent la même version mineure.

L'objectif principal de l'administrateur est de s'assurer que les nouvelles versions de GKE sont soigneusement examinées avant d'atteindre l'environnement de production critique de la banque. Ils souhaitent également mettre à niveau progressivement les clusters dans une région à faible trafic, puis passer à une région à trafic plus élevé et enfin à leur région la plus critique. Pour ce faire, ils utilisent le séquençage du déploiement avec des étapes personnalisées afin de définir une stratégie de mise à niveau progressive qui inclut l'étiquetage des clusters de production en fonction de leur région. Cette approche leur permet de valider une nouvelle version sur un petit sous-ensemble du trafic de production avant un déploiement complet.

Pour mettre en œuvre ce plan, l'administrateur applique les libellés suivants aux clusters du parc de production :

  • Les clusters dans us-west1 (trafic plus faible) sont associés à prod-region: us-west1.
  • Les clusters dans europe-west1 (trafic plus élevé) sont associés à prod-region: europe-west1.
  • Les clusters de us-east1 (trafic le plus critique) ne sont pas libellés. La dernière étape d'une flotte dans une séquence doit servir de "catch-all" pour tous les clusters restants. Par conséquent, l'administrateur n'a pas besoin d'ajouter d'étiquettes à ces clusters restants.

Ensuite, dans un projet hôte dédié utilisé pour gérer les configurations CI/CD, ils définissent un objet RolloutSequence. Cette nouvelle séquence comporte cinq étapes distinctes :

  1. Test : cette étape inclut tous les clusters du parc testing. L'administrateur définit un temps de stabilisation de trois jours pour permettre une validation approfondie.
  2. Préproduction : cette étape inclut tous les clusters de la flotte staging, avec un temps de stabilisation de trois jours.
  3. Production dans la région us-west1 : cette étape cible le parc de production, mais utilise un label-selector pour n'inclure que les clusters portant le libellé prod-region: us-west1. Cette étape permet à l'administrateur de surveiller les éventuels problèmes sur un petit sous-ensemble de clusters de production pendant trois jours.
  4. Production dans la région europe-west1 : cette étape inclut les clusters de la flotte production qui portent le libellé prod-region: europe-west1. L'administrateur définit une durée d'imprégnation plus longue (quatre jours) pour une validation plus approfondie.
  5. Production dans la région us-east1 : cette dernière étape inclut les clusters restants du parc production, c'est-à-dire tous les clusters de us-east1.

Cette approche permet à l'administrateur de contrôler précisément les mises à niveau de production, ce qui améliore considérablement la sécurité et la fiabilité du processus de mise à niveau en détectant les problèmes potentiels avant qu'ils n'affectent l'ensemble de l'environnement de production.

Lors d'une mise à niveau de routine des correctifs, les tests automatisés de la banque se terminent avec succès dans l'environnement de préproduction beaucoup plus rapidement que prévu. L'administrateur constate que la nouvelle version est stable et décide que la période de test de trois jours après la mise à niveau de la flotte de préproduction est inutilement longue pour ce type de mise à jour de routine.

Pour accélérer ce déploiement, l'administrateur modifie la définition de RolloutSequence et réduit la durée de test pour l'étape us-west1 de la flotte de production. Étant donné que cette modification de la définition de RolloutSequence met à jour le temps de stabilisation par défaut pour tous les déploiements actuels et futurs, l'administrateur prend note de rétablir le temps de stabilisation à la période initiale de trois jours une fois ce déploiement de correctif spécifique terminé. Cette approche permet de s'assurer que leur temps de trempage standard et plus prudent est en place pour les futures mises à niveau des versions mineures.

L'administrateur utilise des intervalles et des exclusions de maintenance pour que GKE mette à jour les clusters au moment où cela perturbe le moins la banque. GKE respecte la disponibilité de la maintenance pour les clusters mis à niveau dans une séquence de déploiement :

  • L'administrateur a configuré des intervalles de maintenance pour ses clusters afin que GKE ne les mette à niveau qu'en dehors des heures de travail.
  • L'administrateur utilise également les exclusions de maintenance pour empêcher temporairement la mise à niveau des clusters s'il détecte des problèmes avec les charges de travail du cluster.

De plus, l'administrateur peut gérer un déploiement en effectuant des actions telles que la mise en pause d'un déploiement s'il détecte des problèmes ou la finalisation d'une étape s'il est satisfait des modifications apportées à cette étape et qu'il est prêt à passer immédiatement à la suivante.

L'administrateur utilise une combinaison de mises à niveau de surutilisation et de mises à niveau bleu-vert pour ses nœuds, équilibrant ainsi la vitesse et la tolérance aux risques selon les charges de travail s'exécutant sur ces nœuds.

Comment GKE lance-t-il le déploiement d'une nouvelle version ?

Par défaut, GKE crée un déploiement lorsqu'une nouvelle cible de mise à niveau automatique est définie. La version que GKE sélectionne pour le déploiement dépend de la version mineure et du version disponible des clusters de la séquence. Par exemple, si vos clusters exécutent la version 1.35 de GKE dans le canal Standard et que GKE définit une version cible de mise à niveau automatique sur 1.35.5-gke.1000000, GKE crée un Rollout.

Toutefois, vous pouvez également choisir la version que vous souhaitez que GKE déploie.

Déployer une version spécifique

Vous pouvez également lancer un déploiement vers une version spécifique si, par exemple, vous souhaitez corriger rapidement une faille de sécurité ou un problème critique avec vos clusters GKE. Cette action crée un objet Rollout, ce qui lance un déploiement dans votre séquence de déploiement de la même manière que lorsque GKE définit une cible de mise à niveau automatique. Pour déployer une nouvelle version, consultez Déployer une version spécifique.

Si vous devez déployer une nouvelle version sur un cluster le plus rapidement possible, vous pouvez également effectuer des mises à niveau manuelles des clusters pour les clusters individuels. Les mises à niveau manuelles des clusters sont effectuées au niveau du cluster.

Choisir les types de mises à niveau que GKE effectue dans une séquence de déploiement

Par défaut, GKE déploie tous les types de mises à niveau de cluster dans une séquence de déploiement, y compris les mises à niveau de version corrective et de version mineure du plan de contrôle et des nœuds.

Il existe quatre principaux types de mises à niveau :

  • Mises à niveau des versions de correctif du plan de contrôle
  • Mises à niveau des versions de correctif des nœuds
  • Mises à niveau des versions mineures du plan de contrôle
  • Mises à niveau de versions mineures des nœuds

Vous pouvez limiter le champ d'application des mises à niveau de cluster dans une séquence de déploiement pour n'effectuer que des types spécifiques de mises à niveau. Par exemple, si vous souhaitez que GKE ne déploie que les mises à niveau du plan de contrôle et non celles des nœuds, vous pouvez le spécifier pour votre séquence de déploiement.

Si vous limitez le champ d'application des mises à niveau de cluster pour une séquence de déploiement, GKE n'effectuera pas ce type de mise à niveau automatique pour les clusters de la séquence de déploiement, à l'exception des mises à niveau automatiques obligatoires. Pour en savoir plus, consultez Déploiements des mises à niveau automatiques obligatoires. La restriction de la portée des mises à niveau de cluster n'annule pas les déploiements en cours du type que vous restreignez. Elle empêche uniquement GKE de créer de futurs déploiements de ce type.

Étant donné que GKE ne met pas à niveau les nœuds d'un cluster vers une version ultérieure à celle du plan de contrôle, la restriction de la portée des mises à niveau du plan de contrôle peut également restreindre les mises à niveau des nœuds.

Pour limiter le champ d'application des mises à niveau automatiques dans une séquence de déploiement, consultez Choisir les types de mises à niveau que GKE effectue dans une séquence de déploiement.

La restriction du champ d'application d'une séquence de déploiement fonctionne de la même manière que les exclusions de maintenance, mais ces dernières sont définies pour des clusters ou des pools de nœuds individuels au sein d'un cluster.

Déploiements des mises à niveau automatiques obligatoires

Que votre cluster soit enregistré ou non dans une séquence de déploiement, GKE effectue des mises à niveau automatiques des clusters pour des raisons de sécurité et de compatibilité. Si les plans de contrôle des clusters de votre séquence de déploiement n'ont pas été mis à niveau depuis 90 jours ou si les clusters exécutent une version mineure qui a atteint sa date de fin de compatibilité, GKE crée un déploiement obligatoire pour effectuer des mises à niveau automatiques. Ces déploiements permettent de s'assurer que votre cluster reste performant, disponible et sécurisé. GKE crée des déploiements pour ces scénarios, quelles que soient les restrictions sur le champ d'application des déploiements, les exclusions de maintenance ou toute autre raison de retard.

Vous ne pouvez pas suspendre ni annuler ces types de déploiements. GKE effectue ces types de mises à niveau de cluster, que le séquençage du déploiement soit activé ou non.

Pour en savoir plus sur ces règles, consultez les sections suivantes :

Éligibilité au déploiement

Pour qu'une version soit déployée via une séquence utilisant des étapes personnalisées, les clusters doivent être éligibles à une cible de mise à niveau à partir de leur version disponible. Lorsqu'une nouvelle version de GKE est disponible, le système crée un objet Rollout si les clusters de la séquence sont éligibles à la nouvelle version. Bien que nous vous recommandions d'enregistrer tous les clusters dans le même canal de publication, si ce n'est pas le cas, GKE sélectionne une version du canal le plus conservateur de la séquence. Par exemple, si les clusters sont répartis entre les canaux "Stable" et "Regular", GKE choisit la version du canal "Stable".

L'Rollout progresse ensuite à travers les étapes définies dans votre RolloutSequence. Au cours d'une étape donnée, le déploiement du plan de contrôle et celui du pool de nœuds peuvent s'exécuter en parallèle. Une règle clé régissant cette progression est que, lorsqu'une étape est dans un état SOAKING avec une version spécifique, elle n'est pas éligible pour commencer un nouvel état Rollout pour une version plus récente. Cela permet de s'assurer qu'une version est entièrement validée avant le début de la mise à niveau suivante. Vous pouvez observer la progression et l'éligibilité de chaque cluster en surveillant l'objet Rollout. Si vous constatez des écarts de version qui rendent un cluster inéligible, vous devrez peut-être prendre des mesures, comme mettre à niveau manuellement le cluster ou ignorer un cluster dans une séquence de déploiement, pour permettre au déploiement de se poursuivre. Si un cluster n'est éligible à aucun déploiement, GKE ne le met pas à niveau automatiquement tant qu'il n'a pas besoin de créer des déploiements pour les mises à niveau automatiques obligatoires, comme décrit dans la section précédente.

Les clusters exécutant des versions ultérieures à la version cible de la mise à niveau n'empêchent pas les mises à niveau.

Si une étape de la séquence contient des clusters qui exécutent une version ultérieure à la version cible d'un déploiement, GKE met à niveau les clusters éligibles à la version cible et ignore les clusters qui sont déjà sur une version ultérieure. Ce comportement n'empêche pas la séquence de déploiement de passer à l'étape suivante.

Par exemple, si la version cible d'un déploiement pour une étape est 1.32 et que cette étape comporte des clusters exécutant à la fois les versions 1.31 et 1.33, GKE met à niveau les clusters de la version 1.31 vers la version 1.32 et ignore les clusters qui sont déjà à la version 1.33.

L'étape précédente a qualifié plusieurs cibles de mise à niveau pour l'étape suivante.

Une étape précédente d'une séquence peut terminer les déploiements de plusieurs nouvelles versions, tandis qu'une étape ultérieure est suspendue (par exemple, par une exclusion de maintenance) ou est toujours en train de traiter une mise à niveau précédente. Dans ce cas, lorsque l'étape suivante est prête à accepter une nouvelle mise à niveau, GKE met à niveau l'étape vers la dernière version qualifiée. Pour les mises à niveau du plan de contrôle, cette version peut être au maximum une version mineure ultérieure à la version du plan de contrôle des clusters de l'étape suivante. Pour les mises à niveau de nœuds, cette version peut être égale à la version du plan de contrôle des clusters de l'étape suivante, mais pas ultérieure.

Par exemple, ce scénario est pertinent si vous avez configuré des exclusions de maintenance pour empêcher temporairement les mises à niveau sur vos clusters de production. Si vos clusters de préproduction n'avaient pas les mêmes exclusions de maintenance, ils peuvent être mis à niveau plusieurs fois, ce qui permet de valider plusieurs nouvelles versions, mais vos étapes de production ne sont pas mises à niveau.

Forced soaking après 30 jours

Pour s'assurer qu'une séquence de déploiement termine la mise à niveau des clusters, GKE lance la période de stabilisation pour un groupe si les mises à niveau du plan de contrôle ou des nœuds, respectivement, ne sont pas terminées sur tous les clusters dans le délai de mise à niveau maximal (30 jours). Les mises à niveau des clusters restants du groupe peuvent toujours se poursuivre pendant la période de stabilisation.

Fonctionnement du séquençage du déploiement avec d'autres fonctionnalités de mise à niveau

Le séquençage du déploiement fonctionne avec d'autres fonctionnalités de mise à niveau de GKE :

  • Intervalles et exclusions de maintenance : vous pouvez toujours utiliser des intervalles et des exclusions de maintenance pour contrôler à quel moment les mises à niveau peuvent être effectuées ou non sur vos clusters. GKE ne lance la mise à niveau d'un cluster que dans l'intervalle de maintenance du cluster. Vous pouvez utiliser une exclusion de maintenance pour empêcher temporairement la mise à niveau d'un cluster. Les deux méthodes suivantes peuvent restreindre GKE à l'exécution de certains types de mises à niveau :

    Toutefois, aucune de ces méthodes qui limitent le champ d'application des mises à niveau de cluster n'empêche les mises à niveau automatiques obligatoires. Si GKE ne peut pas mettre à niveau un cluster en raison d'un intervalle ou d'une exclusion de maintenance, cela peut empêcher l'achèvement des mises à niveau du cluster dans une phase. Si une mise à niveau de cluster ne peut pas être terminée dans les 30 jours en raison d'intervalles ou d'exclusions de maintenance, l'étape entre dans sa phase de stabilisation, que tous les clusters aient terminé ou non la mise à niveau.

  • Stratégies de mise à niveau des nœuds : le séquençage du déploiement n'a aucune incidence sur les stratégies de mise à niveau des nœuds que vous avez configurées (par exemple, les mises à niveau bleu-vert). Comme pour les mises à niveau de clusters sans séquençage du déploiement, GKE utilise les mises à niveau de la surutilisation pour les nœuds Autopilot. Pour en savoir plus, consultez la section Mises à niveau automatiques des nœuds.

    Si une mise à niveau des nœuds ne peut pas être terminée dans les 30 jours, le groupe entre dans sa phase de stabilisation, que tous les clusters aient terminé la mise à niveau ou non. Ce comportement peut se produire si la stratégie de mise à niveau de nœuds entraîne une mise à niveau plus longue des nœuds d'un cluster Standard, en particulier s'il s'agit d'un pool de nœuds volumineux. Cette situation peut également être exagérée par des intervalles de maintenance qui ne sont pas assez importants pour qu'une mise à niveau de nœuds se termine.

  • Canaux de publication : nous vous recommandons d'enregistrer tous les clusters d'une séquence de déploiement dans le même version disponible.

  • Détection de l'utilisation d'éléments obsolètes : la détection de l'utilisation d'éléments obsolètes de GKE fonctionne toujours comme prévu, ce qui peut mettre en pause les mises à niveau sur les clusters qui utilisent une API obsolète.

  • Mises à niveau manuelles : la mise à niveau manuelle des clusters de la première étape d'une séquence ne qualifie pas en soi cette version ni ne déclenche de déploiement pour continuer. Le processus de déploiement automatique est basé sur les cibles de mise à niveau automatique officielles définies pour le version disponible. Une mise à niveau manuelle met à jour les clusters, mais la séquence ne commence à progresser pour cette version que lorsqu'elle devient la cible de mise à niveau automatique désignée.

  • Notifications de cluster : GKE fournit des notifications pour le séquençage du déploiement, en plus des autres notifications de cluster disponibles. Pour en savoir plus, consultez Notifications pour le séquençage des déploiements.

Recevoir plusieurs mises à niveau au sein d'une séquence

Un version disponible sélectionne une cible de mise à niveau pour le cluster. Si une nouvelle version devient disponible alors que les mises à niveau vers une cible précédente sont toujours en cours, la première étape peut commencer le déploiement d'une nouvelle version, même lorsque les étapes ultérieures reçoivent toujours la mise à niveau précédente. Par exemple, si le troisième groupe d'une séquence déploie la version 1.31.12-gke.1265000, le premier groupe de la séquence peut déployer simultanément la version 1.31.13-gke.1008000.

Éléments à prendre en compte lors du choix du séquençage du déploiement

Pensez à utiliser le séquençage du déploiement si vous souhaitez gérer les mises à niveau de cluster en qualifiant de nouvelles versions dans un environnement avant de les déployer dans un autre.

Toutefois, cette stratégie peut ne pas convenir dans votre environnement si l'une des affirmations suivantes est vraie :

  • Vous disposez de clusters qui ne sont pas sur le même version disponible ou sur la même version mineure dans le même environnement de production.
  • Vous effectuez fréquemment des mises à niveau manuelles qui entraînent des versions cibles de mise à niveau automatique différentes pour les clusters d'un même groupe.

Notifications pour le séquençage du déploiement

GKE envoie des notifications de cluster qui fournissent des informations essentielles sur les mises à niveau de cluster au niveau du cluster. De plus, GKE fournit des notifications sur les séquences de déploiement avec des étapes personnalisées, ainsi que sur les déploiements qui ont lieu avec ces séquences. Par exemple, GKE envoie des notifications lorsqu'une phase de déploiement commence, se termine ou est bloquée. GKE envoie également une notification si vous avez mal configuré une séquence de déploiement. Pour en savoir plus, consultez le document Notifications de cluster et les sections correspondantes pour RolloutEvent et RolloutSequenceEvent.

Gérer un déploiement

Lorsque GKE déploie une nouvelle version sur les clusters de votre séquence de déploiement, vous pouvez utiliser les actions suivantes pour contrôler le processus pendant que vous évaluez la façon dont votre cluster et vos charges de travail réagissent au changement. Vous pouvez également créer un déploiement pour déployer une version spécifique.

Tant que les mises à niveau sont en cours, vous pouvez vérifier leur état. En fonction de la progression de la mise à niveau, vous pouvez utiliser les actions expliquées dans les sous-sections suivantes.

Suspendre un déploiement

Vous pouvez suspendre un déploiement en cours. Par exemple, si vous avez remarqué un problème potentiel avec vos clusters et la nouvelle version en cours de déploiement, vous pouvez suspendre temporairement le déploiement. GKE ne lancera pas de nouvelles opérations de mise à niveau vers cette version, ce qui vous permettra d'examiner tout problème, si nécessaire. GKE n'arrêtera pas les opérations de mise à niveau en cours, mais n'en démarrera pas de nouvelles, y compris pour les étapes suivantes.

Pour mettre en pause un déploiement, consultez Mettre en pause un déploiement.

Une fois le déploiement mis en veille, vous pouvez le reprendre ou l'annuler. Vous pouvez mettre en veille un déploiement pendant 90 jours maximum. Après 90 jours, GKE annule le déploiement.

La suspension d'un déploiement n'empêche pas le démarrage des déploiements suivants. Toutefois, ces déploiements ne remplaceront pas l'étape de déploiement en pause. Par exemple, si GKE a déjà déployé la version 1.34.8-gke.1000000 dans les première et deuxième étapes, et que vous mettez en veille le déploiement dans la troisième étape, GKE peut lancer un nouveau déploiement vers la version 1.35.5-gke.1163000 et mettre à niveau les clusters des deux premières étapes. Toutefois, GKE ne lancera pas les mises à niveau vers la version 1.35.5-gke.1163000 lors de la troisième étape tant que le déploiement de la version 1.34.8-gke.1000000 n'aura pas été effectué lors de la troisième étape ou annulé.

Si plusieurs déploiements sont en cours pour une séquence de déploiement et que vous souhaitez les mettre tous en veille, vous devez mettre en veille chaque déploiement individuellement. Si vous souhaitez empêcher GKE de démarrer des déploiements supplémentaires, vous pouvez choisir les types de mises à niveau que GKE effectue dans une séquence de déploiement.

Reprendre un déploiement

Vous pouvez reprendre un déploiement suspendu depuis moins de 90 jours, une fois que vous avez examiné les éventuels problèmes et que vous êtes prêt à poursuivre les mises à niveau. Vous ne pouvez reprendre un déploiement mis en pause que si aucun autre déploiement du même type (déploiement du plan de contrôle ou déploiement de nœud) n'est en cours d'exécution en même temps sur la même étape. Vous pouvez également reprendre un déploiement qui a été automatiquement mis en veille par GKE pour des raisons techniques ou commerciales, mais nous vous recommandons d'être prudent avant de le faire.

Si vous reprenez le déploiement, GKE lance de nouvelles opérations de mise à niveau pour continuer à déployer la nouvelle version dans les étapes de la séquence de déploiement.

Pour reprendre un déploiement, consultez Reprendre un déploiement.

Annuler un déploiement

Vous pouvez annuler un déploiement, y compris ceux qui sont actifs ou qui ont été suspendus. Lorsque vous annulez un déploiement, GKE ne crée pas automatiquement de déploiement vers la même version. Toutefois, l'annulation d'un déploiement n'empêche pas GKE de déployer des versions ultérieures. Si vous souhaitez empêcher GKE de déployer également les versions ultérieures, annulez tous les déploiements en cours et limitez le champ d'application des mises à niveau de cluster dans la séquence de déploiement.

Pour annuler un déploiement, consultez Annuler un déploiement.

Si vous devez déployer la même version que celle qui a été annulée, déployez une version spécifique.

Terminer une étape de déploiement

Si vous êtes sûr que le déploiement d'une version peut passer à l'étape suivante de la séquence de déploiement (par exemple, parce que vous avez terminé vos tests à cette étape), vous pouvez faire progresser manuellement votre déploiement en terminant l'étape. Si vous terminez l'étape, les clusters que GKE n'a pas encore mis à niveau ne le seront pas dans le cadre de ce déploiement. Si vous terminez l'étape, le temps de trempage restant est également ignoré. Cette action signifie également que vous n'avez pas besoin de modifier le temps de trempage au niveau de la séquence de déploiement.

Pour terminer une étape de déploiement, consultez Terminer une étape de déploiement.

Gérer un déploiement en modifiant la séquence de déploiement

Vous pouvez également gérer un déploiement en effectuant des actions qui affectent l'ensemble de la séquence de déploiement. Toutefois, pensez à effectuer les actions décrites dans les sections précédentes avant de le faire, comme suspendre un déploiement. Certaines modifications apportées à une séquence de déploiement peuvent entraîner l'annulation des déploiements en cours, en plus d'affecter le fonctionnement des futurs déploiements de la séquence. Si vous ne souhaitez modifier qu'un seul déploiement, utilisez les outils fournis pour gérer un seul déploiement au lieu de modifier l'ensemble de la séquence.

Toutefois, si vous souhaitez modifier le fonctionnement d'une séquence de déploiement pour tous les déploiements (et pas seulement pour le déploiement d'une nouvelle version), consultez la section Gérer une séquence de déploiement.

Contrôler les mises à niveau de chaque cluster pour gérer le déploiement

Pour les mises à niveau individuelles des clusters, vous pouvez utiliser les outils suivants pour les gérer :

  • Contrôler manuellement les mises à niveau en effectuant des actions telles que l'annulation, la reprise, le rollback ou la fin de mises à niveau des pools de nœuds
  • Utilisez des intervalles et des exclusions de maintenance pour décider si un cluster peut être mis à niveau ou non.
  • Configurez des stratégies de mise à niveau des nœuds pour équilibrer la vitesse et la tolérance aux risques en fonction des charges de travail s'exécutant sur ces nœuds.

Pour en savoir plus, consultez Fonctionnement du séquençage du déploiement avec d'autres fonctionnalités de mise à niveau.

Gérer une séquence de déploiement

Pour gérer une séquence de déploiement, vous pouvez effectuer des actions de base telles que les suivantes :

  • Lister vos séquences de déploiement
  • Décrire une séquence de déploiement

Vous pouvez également effectuer des actions telles que modifier une séquence de déploiement et ignorer un cluster dans une séquence de déploiement. Ces actions sont décrites dans les sous-sections suivantes.

Pour en savoir plus sur la gestion du déploiement d'une version au lieu de l'ensemble de la séquence de déploiement, consultez la section précédente, Gérer un déploiement.

Ignorer un cluster dans une séquence de déploiement

Par défaut, tous les clusters qui font partie d'un parc dans une séquence de déploiement sont mis à niveau dans le cadre de cette séquence. Vous pouvez ajouter des clusters à des étapes spécifiques. Tous les clusters d'un parc qui ne sont pas étiquetés seront mis à niveau ensemble.

Toutefois, si vous avez un cluster que vous ne souhaitez pas inclure dans la séquence de déploiement, vous pouvez le libeller afin que GKE l'ignore lors du déploiement de nouvelles versions. Vous devrez peut-être le faire si, par exemple, vous avez besoin de temps supplémentaire avant de mettre à niveau ce cluster spécifique. Vous pouvez ignorer un ou plusieurs clusters dans une séquence de déploiement.

Si vous ignorez un cluster dans une séquence de déploiement, GKE ne le prendra pas en compte lors du déploiement d'une nouvelle version et n'effectuera pas de mise à niveau automatique pour le cluster, à l'exception des mises à niveau automatiques obligatoires, y compris les mises à niveau automatiques à la fin de la période de compatibilité et les mises à niveau automatiques pour les plans de contrôle qui n'ont pas été mis à niveau depuis 90 jours.

Pour ignorer un cluster dans une séquence de déploiement, consultez Ignorer un cluster dans une séquence de déploiement.

Modifier une séquence de déploiement

Si vous souhaitez modifier le déroulement des déploiements dans une séquence de déploiement existante, vous pouvez modifier la séquence de deux manières :

  • Modifiez une séquence de déploiement en modifiant le fichier de configuration YAML dans lequel vous avez défini la séquence.
  • Modifiez les clusters de la séquence.

Voici ce qui se passe si vous modifiez une séquence de déploiement :

  • Si vous ajoutez, supprimez ou modifiez une étape, ou si vous changez l'ordre des étapes (par exemple, pour modifier l'ID de projet ou les sélecteurs de libellés d'une étape) dans une séquence de déploiement, GKE annule tous les déploiements actifs.
  • Si vous modifiez la durée de stabilisation d'une phase, GKE n'annule pas les déploiements actifs.

Pour modifier une séquence de déploiement, consultez Modifier une séquence de déploiement.

Voici ce qui se passe si vous modifiez les clusters d'une séquence :

  • Si vous supprimez un cluster d'une séquence de déploiement en le supprimant d'un parc, les déploiements actifs se poursuivent. GKE peut mettre à niveau automatiquement le cluster en fonction des procédures habituelles pour les clusters non enregistrés dans une séquence.
  • Si vous ajoutez un cluster à un parc dans une séquence de déploiement, GKE mettra à niveau ce cluster dans le cadre de tous les déploiements actifs qui n'ont pas encore dépassé l'étape à laquelle vous l'avez ajouté. Toutefois, si l'étape a été effectuée pour le déploiement, GKE ne mettra pas à niveau le cluster dans ce déploiement.

  • Si vous déplacez un cluster vers une autre étape sans modifier la configuration de la séquence de déploiement, les événements suivants se produisent, selon que l'étape vers laquelle vous déplacez le cluster est terminée ou non :

    • Si vous déplacez un cluster vers une étape dont le déploiement est déjà terminé, GKE ne met pas à niveau le cluster dans ce déploiement.
    • Si vous déplacez un cluster qui a déjà été mis à niveau dans un déploiement vers une étape ultérieure non terminée, GKE ignore le cluster et n'interrompt pas la progression du déploiement.

Pour modifier les clusters d'une séquence, consultez Enregistrer un cluster sur Cloud de Confiance by S3NS dans votre parc.

Limites

Les limites suivantes s'appliquent lorsque vous mettez à niveau vos clusters à l'aide du séquençage du déploiement avec des étapes personnalisées :

  • Vous ne pouvez pas utiliser la console Cloud de Confiance pour créer ni afficher des séquences de déploiement avec des étapes personnalisées.
  • Lorsqu'une séquence de déploiement fait référence à un parc, vous devez inclure l'intégralité du parc. Cette contrainte signifie que si vous définissez une étape pour cibler uniquement un sous-ensemble de clusters d'un parc avec un label-selector (par exemple, pour un déploiement progressif), vous devez également définir une étape "catch-all" ultérieure qui inclut tous les clusters restants de ce même parc. Cette étape générique cible le même parc, mais n'inclut pas de label-selector. Elle inclut donc automatiquement tous les clusters qui n'ont pas été sélectionnés par les étapes précédentes de la séquence.
  • Si vous modifiez une séquence pendant un déploiement, en particulier les modifications qui affectent les clusters participants, GKE annule immédiatement tous les déploiements existants. Si vous ne modifiez que la durée de stabilisation d'une séquence, GKE n'annule pas le déploiement.
  • Une étape ne peut faire référence qu'à un seul parc. Vous ne pouvez pas avoir plusieurs flottes dans une même étape.
  • Un même parc ne peut être référencé que dans une seule séquence de déploiement. Deux séquences de déploiement ne peuvent pas faire référence au même parc.
  • Vous ne pouvez pas mettre à niveau les clusters avec séquençage du déploiement qui utilisent les mises à niveau automatiques accélérées des correctifs.
  • Vous pouvez créer une séquence de déploiement comportant jusqu'à 15 étapes.
  • Vous pouvez inclure jusqu'à 250 clusters dans un parc. Pour les clusters avec des appartenances légères, vous pouvez demander une augmentation de quota pour un maximum de 2 000 clusters dans un parc. Pour en savoir plus, consultez Quotas et limites.
  • Vous pouvez configurer une durée d'imprégnation maximale par séquence (jusqu'à 90 jours) pour toutes les étapes.

Problèmes connus

Cette section décrit les problèmes connus liés au séquençage du déploiement avec des étapes personnalisées.

  • Si une étape de votre séquence de déploiement ne contient aucun cluster, elle est ignorée, mais la période de stabilisation définie pour cette étape s'écoule quand même avant que le déploiement ne passe à l'étape suivante.

Étapes suivantes