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

Autopilot Standard

Rollout sequencing with custom stages

• Séquençage du déploiement avec des étapes personnalisées (bêta)
• Séquençage du déploiement (disponibilité générale)

Preview

Cette fonctionnalité est soumise(s) aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les fonctionnalités de pré-DG sont disponibles "en l'état" et peuvent avoir une prise en charge limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

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 propose également une version en disponibilité générale du séquençage du déploiement qui utilise un modèle plus linéaire sans étapes personnalisées.

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

• Mises à niveau de cluster
• Présentation de la gestion de parc
• Canaux de publication
• Schéma de gestion des versions dans GKE
• Tests d'endurance

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

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 consiste en 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 des clusters de manière logique pour le déploiement séquentiel 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 séquence de déploiement

GKE propose deux versions du séquençage du déploiement. Les deux versions sont basées sur les mêmes principes fondamentaux de mises à niveau progressives basées sur le parc, mais elles offrent différents niveaux de flexibilité. Cette section vous aide à choisir la version la mieux adaptée à votre cas d'utilisation.

• Séquence de déploiement basée sur les parcs (DG) : cette version est la stratégie recommandée et généralement disponible pour la plupart des cas d'utilisation en production. Le séquençage du déploiement basé sur les parcs fournit une méthode stable et compatible pour déployer progressivement les mises à niveau dans différents environnements (tels que les environnements de test, de préproduction et de production). Il utilise une séquence linéaire de parcs.

• Séquence de déploiement avec des étapes personnalisées (version Preview) : cette version est une évolution du modèle basé sur les parcs, qui offre un contrôle et une flexibilité plus précis. 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. Choisissez cette option si vous avez besoin de plus de flexibilité ou si vous souhaitez prévisualiser les dernières fonctionnalités de séquençage des déploiements.

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équençage 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 :

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

Lorsqu'une nouvelle cible de mise à niveau devient disponible dans le canal de publication auquel tous les clusters de cette séquence sont inscrits, GKE met d'abord à niveau les clusters du parc de test, puis ceux du parc 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 "Main") à la fin du processus, car cette étape ne comporte aucun sélecteur de libellés.

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 d'imprégnation : il s'agit d'une période d'attente configurable qui se produit une fois que tous les clusters d'une étape ont été mis à niveau. Ce temps de préparation 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 d'attente de 30 jours maximum pour chaque étape de votre séquence. Une période d'incubation plus longue en phase de préproduction vous permet de disposer de plus de temps pour la validation.
• RolloutSequence : 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.
• 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 la progression et voir si des clusters ne sont pas éligibles à la mise à niveau et pourquoi.
• Projet hôte dédié : nous vous recommandons d'utiliser un projet Google Clouddé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 définit une nouvelle cible de mise à niveau automatique pour les clusters d'une version mineure dans un version disponible spécifique, avec des notes de version semblables au message suivant : "Avec cette version, les plans de contrôle et les nœuds pour lesquels la mise à niveau automatique est activée dans le canal standard" passeront de la version 1.29 à la version 1.30.14-gke.1150000."

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 du 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 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 ultérieure à la cible de mise à niveau automatique 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 à la cible de mise à niveau automatique 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 cible de mise à niveau.

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

Avertissement : GKE peut ne pas réussir à effectuer les mises à niveau automatiques dans une séquence de déploiement en cas d'écarts de version entre les clusters des groupes de la séquence. Pour en savoir plus, consultez la section Éligibilité au déploiement.

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. Tant que les mises à niveau sont en cours, vous pouvez vérifier l'état et gérer la séquence de déploiement selon vos besoins. Vous pouvez également contrôler le processus des manières suivantes :

• Vous pouvez modifier le temps de stabilisation par défaut d'un groupe dans une séquence de déploiement. Cela peut être utile si les tests révèlent qu'une version spécifique nécessite plus ou moins de temps de stabilisation. Cette modification du temps de stabilisation met à jour le temps de stabilisation par défaut pour tous les déploiements actuels et futurs (quelle que soit la version) créés après la modification.

• Pour les mises à niveau individuelles des clusters, vous pouvez continuer à utiliser les outils suivants :
  • 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.

Attention : 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.

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 testé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 séquence pour une flotte doit servir de "catch-all" pour tous les clusters restants. L'administrateur n'a donc 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 trempage 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 une période de test de trois jours.
4. Production dans la région europe-west1 : cette étape inclut les clusters du parc production qui portent le libellé prod-region: europe-west1. L'administrateur définit une période de test plus longue de 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, 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 le temps de stabilisation de trois jours après la mise à niveau de la flotte de préproduction est inutilement long pour ce type de mise à jour de routine.

Pour accélérer ce déploiement, l'administrateur modifie la définition RolloutSequence et réduit la durée d'imprégnation pour l'étape us-west1 du parc 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, plus prudent, est en place pour les futures mises à niveau de 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 bureau.
• 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.

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.

Éligibilité au déploiement

Pour qu'une version soit déployée dans une séquence à l'aide d'é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 version disponible, 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".

Le Rollout progresse ensuite dans 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 non éligible, vous devrez peut-être prendre des mesures, comme mettre à niveau manuellement le cluster, pour permettre à la séquence de se poursuivre. Si un cluster n'est éligible à aucun déploiement, GKE ne le met pas à niveau automatiquement tant que la version actuelle n'a pas atteint la fin de la période d'assistance.

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 exécutent déjà 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 ne bénéficiaient pas des mêmes exclusions de maintenance, ils peuvent être mis à niveau plusieurs fois, ce qui permet de qualifier plusieurs nouvelles versions, mais vos étapes de production ne sont pas mises à niveau.

Stabilisation forcée 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 test.

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. 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 étape. 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é la mise à niveau ou non. Les déploiements du plan de contrôle et des pools de nœuds peuvent s'exécuter en parallèle au cours d'une même étape.

• 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 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 des fonctionnalités obsolètes : la détection de l'utilisation des fonctionnalités 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.

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 différences entre les versions cibles de mise à niveau automatique des clusters d'un même groupe.

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 Google Cloud 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.
• Vous ne pouvez pas accélérer manuellement un déploiement actif pour une version spécifique. Lorsque vous modifiez la durée de stabilisation dans la définition de la séquence de déploiement, la modification met à jour la durée de stabilisation par défaut pour tous les déploiements actuels et futurs créés après la modification.
• GKE met automatiquement à niveau les clusters qui ont atteint la fin de leur période d'assistance vers une version compatible. Cette mise à niveau peut ne pas suivre la séquence de déploiement définie.
• Une plate-forme ne peut référencer 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.

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

• Séquencer le déploiement des mises à niveau des clusters avec des étapes personnalisées