À propos des mises à niveau des clusters avec séquençage du déploiement

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 du séquençage du déploiement qui utilise des étapes personnalisées (preview) pour vous permettre de contrôler plus précisément les mises à niveau des clusters.

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.

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 le parc (DG) : cette version est la stratégie recommandée 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 (preview) : cette version est une évolution du modèle basé sur les parcs, offrant 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 un bon choix 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 du déploiement.

Séquence de déploiement basée sur un parc

Pour mettre à niveau automatiquement des clusters avec le séquençage du déploiement, utilisez des parcs dans lesquels vous avez regroupé vos clusters ayant le même version disponible et la même version mineure dans les étapes de déploiement. Définissez la séquence de parcs et le temps de stabilisation souhaité entre chaque groupe de clusters. Ensuite, lorsque GKE sélectionne une nouvelle version pour les mises à niveau automatiques dans le canal de publication, vos groupes de clusters sont mis à niveau dans l'ordre que vous avez défini. Vous pouvez ainsi valider l'exécution des charges de travail comme prévu avec une nouvelle version avant le début des mises à niveau avec vos clusters de production.

Le schéma suivant montre comment GKE met automatiquement à niveau les clusters dans une séquence de déploiement organisée avec des parcs :

Séquence de déploiement basée sur un parc, dans laquelle vous regroupez les clusters dans des parcs.
Figure  : Séquence de déploiement basée sur un parc

Avec une séquence basée sur le parc, lorsque GKE met à disposition une nouvelle cible de mise à niveau dans le version disponible où tous les clusters de cette séquence sont enregistrés, GKE met à niveau ces parcs de clusters dans cette séquence. Les clusters du parc en amont qualifient la nouvelle version pour les clusters du parc en aval, pour un maximum de cinq parcs. Dans une séquence de déploiement, en amont fait référence au groupe précédent et en aval au groupe suivant.

Pendant le temps de stabilisation configuré entre les parcs, vous pouvez vérifier que vos charges de travail s'exécutent comme prévu sur les clusters mis à niveau.

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 :

Séquence de déploiement avec des étapes personnalisées dans GKE.
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.

Pour en savoir plus sur le séquençage du déploiement avec des étapes personnalisées, consultez À propos du séquençage du déploiement avec des étapes personnalisées.

Le reste de ce document ne concerne que le séquençage du déploiement basé sur le parc.

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 .

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 :

  • 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.

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

Par exemple, l'administrateur de plate-forme d'une banque communautaire gère trois environnements de déploiement principaux : test, préproduction et production. Chaque environnement comporte un groupe de clusters organisé dans un parc. Comme cela est nécessaire pour le séquençage du déploiement, l'administrateur a enregistré chaque cluster dans les trois parcs du même version disponible (dans ces parcs, le canal standard, avec tous les clusters exécutant la même version mineure).

L'administrateur utilise le séquençage du déploiement pour définir l'ordre dans lequel GKE met à niveau les clusters dans ces environnements. L'ordre de déploiement permet à l'administrateur de vérifier que ses charges de travail s'exécutent comme prévu avec les clusters sur une nouvelle version de GKE avant que l'environnement de production ne soit mis à niveau vers la nouvelle version. Cette séquence est illustrée dans le diagramme de séquence de déploiement basé sur un parc.

L'administrateur utilise le temps de stabilisation entre les parcs pour vérifier que ses charges de travail s'exécutent comme prévu sur la nouvelle version de GKE. Pour le parc de test, l'administrateur définit le temps de stabilisation sur 14 jours afin de disposer de deux semaines complètes pour tester l'exécution des charges de travail. Pour la préproduction, il définit le délai de stabilisation sur sept jours, car il n'a pas besoin de plus de temps après l'exécution des charges de travail dans les tests.

L'administrateur peut également remplacer le temps de stabilisation par défaut pour les mises à niveau vers des versions spécifiques, ce qui peut être fait dans l'une des situations suivantes :

  • L'administrateur termine de qualifier la version avant la fin du temps de stabilisation et souhaite que les mises à niveau passent au parc suivant. Il définit donc le temps de stabilisation sur zéro.
  • L'administrateur a besoin de plus de temps pour qualifier la nouvelle version avant que les mises à niveau ne soient déployées sur le prochain parc. En effet, il a remarqué un problème avec certaines de ses charges de travail. Il définit donc le temps de stabilisation sur le maximum de 30 jours.

L'administrateur utilise des intervalles et des exclusions de maintenance pour permettre à GKE de mettre à niveau 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 basé sur le parc

Pour que les clusters soient mis à niveau automatiquement avec le séquençage du déploiement, tous les clusters de tous les parcs d'une séquence de déploiement doivent recevoir la même cible de mise à niveau. Les clusters doivent être enregistrés dans la même version disponible et nous vous recommandons d'exécuter la même version mineure car les cibles de mise à niveau sont définies par version mineure. Cependant, pour certaines versions, comme la version dans l'exemple suivant, les clusters de plusieurs versions mineures ont reçu la même cible, ce qui signifie que les clusters peuvent être mis à niveau avec succès dans la séquence de déploiement exécutant plusieurs versions mineures.

Vous pouvez vérifier l'état du déploiement de la version en séquence pour obtenir plus d'informations sur cet état et savoir si des problèmes d'éligibilité des versions empêchent les mises à niveau. Selon les écarts de version, vous devrez peut-être prendre des mesures telles que la mise à niveau manuelle d'un cluster ou sa suppression d'un groupe pour que les mises à niveau de cluster puisse se poursuivre. Si un cluster d'une séquence de déploiement ne possède pas de cible de mise à niveau éligible, GKE ne met pas à niveau automatiquement le cluster tant que la version mineure existante du cluster n'a pas atteint la fin de vie.

Pour résoudre les problèmes d'éligibilité au déploiement, consultez la section Résoudre les problèmes d'éligibilité au déploiement.

Exemple de version GKE

Par exemple, la version 2025-R45 a défini une cible de mise à niveau pour plusieurs versions mineures dans les clusters enregistrés dans le canal standard. Une cible de mise à niveau peut être une nouvelle version mineure (1.30 à 1.31) ou simplement une nouvelle version de correctif (1.31.x-gke.x à 1.31.13-gke.1023000). Dans cette version, dans le canal standard, les nouvelles versions suivantes ont été mises à la disposition des clusters sur des versions mineures spécifiques :

  • Les clusters exécutant la version 1.30 ont été mis à niveau vers la version 1.31.13-gke.1023000.
  • Les clusters exécutant la version 1.31 ont été mis à niveau vers la version 1.32.9-gke.1108000.
  • Les clusters exécutant la version 1.32 ont été mis à niveau vers la version 1.33.5-gke.1162000.

Le groupe le plus en amont reçoit toutes les cibles de mise à niveau.

Pour les clusters du premier groupe d'une séquence, qui ne possède pas de groupe en amont en vue de qualifier les nouvelles versions, GKE met à niveau tous les clusters avec des cibles de mise à niveau éligibles, que ces cibles de mise à niveau soient différentes ou non les unes des autres. Par exemple, dans le premier groupe d'une séquence, si certains clusters exécutent la version 1.30, ils peuvent être mis à niveau vers la version 1.31.13-gke.1023000, et les clusters exécutant la version 1.32 peuvent être mis à niveau vers la version 1.33.5-gke.1162000. En effet, pour le premier groupe d'une séquence, GKE considère que toutes les cibles de mise à niveau sont qualifiées pour ces clusters, car il n'existe pas de groupe en amont pour qualifier une nouvelle version.

Un groupe en amont ne doit qualifier qu'une seule version.

Pour que les clusters d'un groupe en aval puissent commencer à être mis à niveau, le groupe en amont doit avoir qualifié avec succès une cible de mise à niveau unique et commune à laquelle tous les clusters du groupe en aval sont éligibles. Si le groupe en amont comporte des clusters qui ont été mis à niveau vers deux versions différentes (ce qui peut se produire lorsque le groupe en amont est le premier groupe d'une séquence), il qualifie la version la plus basse des deux comme cible de mise à niveau commune pour le groupe en aval. Par exemple, si le groupe en amont comporte des clusters mis à niveau vers la version 1.31.13-gke.1023000 et d'autres vers la version 1.33.5-gke.1162000, le groupe qualifie la version 1.31.13-gke.1023000 comme cible de mise à niveau commune pour le groupe en aval.

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

Si un groupe en aval comporte des clusters qui exécutent une version ultérieure à la cible de mise à niveau qualifiée par un groupe en amont, GKE met à niveau les clusters éligibles à la cible de mise à niveau et ignore les clusters qui exécutent déjà une version ultérieure. Ce comportement n'empêche pas la progression de la séquence de déploiement, à condition qu'au moins un cluster du groupe en aval soit éligible à la cible de mise à niveau.

Par exemple, si le groupe en amont a qualifié la mise à niveau vers la version 1.32 et que le groupe en aval comporte des clusters exécutant les versions 1.31 et 1.33, GKE met à niveau les clusters exécutant la version 1.31 vers la version 1.32 et ignore les clusters exécutant la version 1.33.

Un groupe en amont doit qualifier une version correspondant aux clusters du groupe suivant.

Si les clusters d'un groupe en amont ont qualifié une version différente de celle à laquelle les clusters du groupe suivant étaient éligibles, GKE ne peut pas non plus mettre à niveau automatiquement les clusters des groupes en aval.

Par exemple, si tous les clusters du premier groupe ont été mis à niveau vers la version 1.31.13-gke.1023000, mais que les clusters du deuxième groupe exécutent une version plus récente, telle que la version 1.32.9-gke.1108000, les clusters du deuxième groupe ne seront pas mis à niveau automatiquement. Le premier groupe a qualifié la version 1.31.13-gke.1023000, mais les clusters du deuxième groupe (actuellement sur la version 1.32) ne sont éligibles que pour la cible de mise à niveau 1.33.5-gke.1162000. GKE ne peut donc pas automatiquement mettre à niveau ces clusters. Pour faire progresser les mises à niveau dans cette situation, consultez Résoudre les problèmes d'éligibilité entre les groupes.

Le groupe en amont a qualifié plusieurs cibles de mise à niveau pour le groupe en aval.

Si GKE a mis à niveau les clusters du groupe en amont plusieurs fois avant de mettre à niveau les clusters du groupe en aval, GKE met à niveau les clusters du groupe en aval vers la dernière version qualifiée par le groupe en amont, à laquelle les clusters du groupe en aval sont éligibles. 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 du groupe en aval. Pour les mises à niveau de nœuds, cette version peut être égale à la version du plan de contrôle des clusters du groupe en aval, 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 de votre groupe en aval, qui inclut vos clusters de production. Toutefois, votre groupe en amont, qui inclut les clusters de préproduction, n'a pas utilisé d'exclusions de maintenance pour empêcher les mises à niveau. Votre groupe en amont a donc été mis à niveau plusieurs fois, ce qui a qualifié plusieurs cibles de mise à niveau potentielles, tandis que votre groupe en aval n'a pas été mis à niveau.

Les mises à niveau non effectuées dans les 30 jours seront forcées pour débloquer la séquence.

Pour s'assurer qu'une séquence de déploiement termine la mise à niveau des clusters, GKE lance la période de stabilisation d'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 maximal de mise à niveau (30 jours). Les mises à niveau des clusters restants du groupe peuvent toujours se poursuivre pendant la période de stabilisation. Pour en savoir plus, consultez la ligne FORCED_SOAKING dans le tableau des informations sur l'état d'une séquence de déploiement.

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

Le séquençage du déploiement est une fonctionnalité d'un ensemble de fonctionnalités qui vous permet de contrôler l'aspect des mises à niveau du cycle de vie du cluster. Cette section explique le fonctionnement de cette fonctionnalité avec d'autres fonctionnalités disponibles liées aux mises à niveau des clusters.

Fonctionnement du séquençage du déploiement basé sur un parc avec des intervalles et des exclusions de maintenance

GKE respecte les intervalles de maintenance et les exclusions de maintenance lors de la mise à niveau des clusters avec le séquençage du déploiement. 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 un groupe. 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, le groupe entre dans sa phase de stabilisation, que tous les clusters aient terminé ou non la mise à niveau.

Vous pouvez utiliser les exclusions de maintenance comme mesure temporaire pour empêcher une séquence de terminer un déploiement vers un groupe et de passer au groupe suivant. Pour en savoir plus, consultez Retarder l'achèvement du déploiement de la version du groupe.

Fonctionnement du séquençage du déploiement basé sur un parc avec la détection de l'utilisation d'éléments obsolètes

GKE met en pause les mises à niveau de cluster lorsqu'il détecte l'utilisation de certaines API et fonctionnalités obsolètes. Les mises à niveau automatiques sont également mises en pause pour les clusters d'un groupe dans une séquence de déploiement. Pour en savoir plus, consultez Impact des abandons de Kubernetes sur GKE.

Fonctionnement du séquençage du déploiement avec les stratégies de mise à niveau de nœuds

Les mises à niveau de nœuds utilisent leur stratégie de mise à niveau de nœuds configurée lors de la mise à niveau dans une séquence de déploiement. 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. Cela 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.

Fonctionnement du séquencement du déploiement avec les canaux de publication

Les canaux de publication sont obligatoires pour l'utilisation du séquençage du déploiement. Tous les clusters de tous les groupes d'une séquence de déploiement doivent se trouver sur le même canal de publication.

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

Si une nouvelle version devient une cible de mise à niveau sur la version disponible alors que les mises à niveau du cluster vers une cible de mise à niveau précédente sont toujours en cours de séquence, un groupe en amont peut commencer le déploiement d'une nouvelle version, tandis qu'un groupe en aval reçoit 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 basé sur un parc

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 devez automatiser les mises à niveau qui ne peuvent pas être mappées à seulement cinq étapes de déploiement, car vous ne pouvez créer une séquence de déploiement qu'avec cinq groupes de clusters au maximum. Vous ne pouvez pas associer des groupes dans plusieurs séquences de déploiement pour créer une séquence de déploiement comportant plus de cinq groupes. Les séquences basées sur un parc peuvent inclure jusqu'à cinq parcs.
  • 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 du séquençage du déploiement basé sur un parc

Pour mettre à niveau vos clusters avec le séquençage du déploiement, vous devez respecter les limites suivantes :

  • Assurez-vous que tous les clusters d'une séquence de déploiement sont enregistrés dans la même version disponible. Nous vous recommandons également que tous les clusters exécutent la même version mineure afin de qualifier une cible de mise à niveau. Pour en savoir plus, consultez la section Éligibilité au déploiement.
  • Créez une séquence de déploiement linéaire sans cycles (un groupe a un groupe en aval comme groupe en amont) ni branches (un groupe comporte plusieurs groupes en aval).
  • Créez une séquence de déploiement entre des clusters d'une même organisation. Vous ne pouvez pas créer de séquences avec des clusters dans plusieurs organisations.

Problèmes connus liés au séquençage du déploiement basé sur la flotte

  • Si un groupe contient des clusters provenant de différents emplacements, il est possible qu'une mise à niveau de cluster ne soit temporairement disponible que pour certains clusters en raison du déploiement progressif de la nouvelle version. Ce comportement est plus susceptible de se produire pour le premier groupe de clusters et devrait se résoudre dans un délai d'une semaine.
  • Si une séquence de déploiement comporte un groupe vide, l'impact de cette situation sur la qualification des versions dépend des conditions suivantes :
    • Si le groupe vide n'a pas de groupe en amont, les mises à niveau de cluster ne sont pas transmises au groupe en aval, car le groupe vide ne peut pas qualifier de versions.
    • Si le groupe vide a un groupe en amont, toutes les mises à niveau de cluster en attente passent à l'état COMPLETE et se propagent au groupe en aval.

Étapes suivantes