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. Pour utiliser cette fonctionnalité, vous devez être familiarisé avec les mises à niveau des clusters, les canaux de publication et la gestion des parcs.
Pour commencer, consultez la page Séquencer le déploiement de mises à niveau du cluster.
Qualifier les mises à niveau dans tous les environnements
Pour mettre à niveau automatiquement des clusters avec le séquençage du déploiement, utilisez les parcs ou les niveaux d'accès d'équipe dans lesquels vous avez regroupé vos clusters ayant le même canal de publication et la même version mineure dans les étapes de déploiement. Choisissez la séquence de parcs ou la séquence de niveaux d'accès d'équipe, puis définissez la durée de stabilisation des tests souhaitée 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 et vous pouvez 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.
Séquence de déploiement basée sur le parc
Le schéma suivant montre comment GKE met automatiquement à niveau les clusters dans une séquence de déploiement organisée avec des parcs :
Avec une séquence basée sur le parc, lorsque GKE rend disponible une nouvelle cible de mise à niveau dans la version disponible où tous les clusters de cette séquence sont enregistrés, GKE met à niveau ces parcs de clusters dans cette séquence, avec les clusters du parc en amont qui qualifient la nouvelle version pour les clusters du parc en aval, jusqu'à trois 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 (après la fin des mises à niveau sur le parc en amont et avant leur début sur le parc en aval), vous pouvez vérifier que vos charges de travail s'exécutent comme prévu sur les clusters mis à niveau.
Séquence de déploiement basée sur l'équipe
Si vous avez subdivisé davantage les clusters d'un parc par équipe ou par application, vous pouvez créer une séquence de déploiement entre les champs d'application d'équipe. Les niveaux d'accès d'équipe sont une construction au niveau du parc d'entreprise permettant d'associer des sous-ensembles de clusters de parc à des équipes d'applications spécifiques. Ils peuvent être utilisés pour activer un éventail de fonctionnalités basées sur l'équipe, telles que le contrôle des accès et une observabilité basée sur l'équipe ainsi que le séquençage du déploiement.
Avec les niveaux d'accès d'équipe, vous pouvez créer plusieurs séquences de déploiement dans un parc, chacune avec ses propres canaux de publication, cibles de mise à niveau et temps de stabilisation indépendants. Une séquence de déploiement basée sur l'équipe fonctionne de la même manière qu'une séquence de déploiement basée sur un parc, à la différence que les mises à niveau sont qualifiées entre les clusters d'une équipe spécifique dans chaque parc, plutôt que de parc à parc. Cela est particulièrement utile pour les opérateurs d'application qui souhaitent gérer les mises à niveau dans les clusters de leur propre équipe.
La séquence de déploiement basée sur l'équipe est en version preview, tandis que la séquence de déploiement basée sur les parcs est en disponibilité générale.
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 ou champs d'application) des clusters sont mis à niveau et vous spécifiez le temps de stabilisation à choisir pour 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 :
- GKE définit une nouvelle cible de mise à niveau automatique pour les clusters sur une version mineure dans une version disponible, la note de version mentionnant le message suivant : "Les plans de contrôle et nœuds avec mise à niveau automatique activée dans le canal standard seront mis à niveau de la version 1.21 vers la version 1.22.15-gke.1000 avec cette version."
- GKE commence à mettre à niveau les plans de contrôle de cluster vers la nouvelle version du premier groupe de clusters. Après avoir mis à niveau le plan de contrôle d'un cluster, GKE 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.
- GKE effectue les étapes suivantes pour les mises à niveau du plan de contrôle :
- GKE lance la période de stabilisation pour les mises à niveau du plan de contrôle une fois que toutes les mises à niveau du plan de contrôle du cluster dans le premier groupe sont terminées, ou que 30 jours se sont écoulés depuis le début des mises à niveau du plan de contrôle.
- Après la période de stabilisation pour les mises à niveau du plan de contrôle du cluster du premier groupe, GKE commence les mises à niveau du deuxième groupe.
- Parallèlement aux mises à niveau du plan de contrôle, GKE effectue les étapes suivantes pour les mises à niveau des nœuds :
- GKE lance la période de stabilisation pour les mises à niveau des nœuds une fois que toutes les mises à niveau des nœuds du premier groupe sont terminées ou que 30 jours se sont écoulés depuis le début des mises à niveau des nœuds.
- GKE lance les mises à niveau des nœuds du deuxième groupe pour les clusters où le plan de contrôle a déjà été mis à niveau une fois la période de stabilisation terminée pour les mises à niveau du nœud du premier groupe.
- GKE répète ces étapes du deuxième groupe 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.
Lorsque les clusters sont mis à niveau dans chaque groupe, vérifiez pendant le temps de stabilisation que vos charges de travail s'exécutent comme prévu avec les clusters exécutant la nouvelle version de GKE.
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. Pour en savoir plus, consultez la section Fonctionnement du séquençage du déploiement avec d'autres fonctionnalités de mise à niveau.
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 d'une séquence de déploiement et gérer la séquence de déploiement selon vos besoins. Vous pouvez également contrôler le processus des manières suivantes :
- Pour un groupe dans une séquence de déploiement, vous pouvez remplacer le temps de stabilisation par défaut si vous avez besoin de plus ou moins de stabilisation pour une version spécifique.
- 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.
Pour en savoir plus, consultez la section Fonctionnement du séquençage du déploiement avec d'autres fonctionnalités de mise à niveau.
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, chacun étant un groupe de clusters organisés dans un parc : test, préproduction et production. 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 canal de publication (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. Le fait de commander le déploiement permet à l'administrateur de vérifier que ses charges de travail s'exécutent comme prévu avec des clusters sur une nouvelle version de GKE avant la mise à niveau de l'environnement de production vers la nouvelle version. Cette séquence est illustrée par le schéma de la séquence de déploiement basée sur un parc.
L'administrateur utilise le temps de stabilisation entre ces parcs mis à niveau pour vérifier que leurs charges de travail s'exécutent comme prévu avec des clusters sur la nouvelle version de GKE. Pour le parc de tests, l'administrateur définit le temps de stabilisation sur 14 jours pour qu'il dispose 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 la qualification de la version avant la fin du temps de stabilisation et souhaite que les mises à niveau passent au parc suivant. Il définit donc ce temps de stabilisation sur zéro.
- L'administrateur a besoin de plus de temps pour qualifier la nouvelle version avant de procéder aux mises à niveau vers le parc suivant, car il a constaté un problème avec certaines de leurs charges de travail. Il définit donc le temps de stabilisation sur la durée maximale de 30 jours.
L'administrateur utilise des intervalles et des exclusions de maintenance pour s'assurer que GKE met à jour les clusters au moment où cela perturbe le moins la banque. GKE respecte la disponibilité de 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 de s'assurer que GKE ne met à niveau les clusters qu'après les heures d'ouverture.
- 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.
L'administrateur passe aux séquences de déploiement basées sur une équipe
Si l'administrateur décide de regrouper davantage les clusters dans un parc par application et de donner à ses administrateurs d'équipe d'applications un meilleur contrôle sur leurs mises à niveau, il peut utiliser des niveaux d'accès d'équipe. Grâce aux niveaux d'accès d'équipe, les administrateurs d'équipe de développement peuvent créer des séquences de déploiement indépendantes avec les groupes de clusters attribués à leurs équipes, s'exécutant potentiellement sur différents canaux de publication ou à des temps de stabilisation différents.
Par exemple, si l'équipe de base de données souhaite que ses clusters utilisent le canal stable et des temps de stabilisation plus longs, tandis que les clusters de l'équipe de l'interface du site Web utilisent le canal rapide et des temps de stabilisation plus courts, il est possible d'utiliser les champs d'application d'équipe pour créer une séquence de déploiement distincte. Ce type de séquence est illustré par le schéma de la séquence de déploiement par équipe. Pour ce faire, suivez les instructions permettant de basculer entre les séquences de déploiement basées sur le parc et sur l'équipe.
Notez que l'utilisation de cette fonctionnalité nécessite des clusters à location unique. En d'autres termes, chaque cluster n'est associé qu'à une seule équipe. Les clusters partagés (compatibles avec la gestion générale des équipes de parc) ne sont pas compatibles avec le séquençage du déploiement. Pour en savoir plus sur la gestion des clusters pour les équipes, consultez la page Gestion des équipes de parc.
Éligibilité au déploiement
Pour que les clusters soient automatiquement mis à niveau avec le séquençage de déploiement, tous les clusters de tous les groupes (parcs ou champs d'application) 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 2022-R25 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.20 à 1.21) ou simplement une nouvelle version de correctif (1.21.x-gke.x à 1.21.14-gke.4300). 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 les versions 1.20 et 1.21 ont été mis à niveau vers la version 1.21.14-gke.4300.
- Les clusters exécutant la version 1.22 ont été mis à niveau vers la version 1.23.8-gke.1900.
- Les clusters exécutant la version 1.24 ont été mis à niveau vers la version 1.24.5-gke.600.
Le groupe 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.20, ils peuvent être mis à niveau vers la version 1.21.14-gke.4300 et les clusters exécutant la version 1.24 peuvent être mis à niveau vers la version 1.24.5- gke.600 En effet, pour le premier groupe d'une séquence, GKE considère que toutes les cibles de mise à niveau sont éligibles 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.
Dans les groupes en aval, la capacité de GKE à mettre à niveau les clusters varie selon que le groupe en amont a qualifié une cible de mise à niveau pour laquelle tous les clusters de ce groupe sont éligibles. En règle générale, cela signifie que tous les clusters démarrent sur la même version mineure. Toutefois, dans l'exemple de version, les clusters 1.20 et 1.21 disposaient de la même cible de mise à niveau. Par conséquent, les clusters exécutant les deux versions peuvent, dans le même groupe, qualifier la mise à niveau 1.21.14-gke.4300
Si tous les clusters d'un groupe n'ont pas la même cible de mise à niveau, ce groupe ne peut pas qualifier une cible de mise à niveau pour le groupe suivant. Dans cette situation, GKE ne peut pas mettre à niveau automatiquement les clusters dans les groupes en aval. Par exemple, si dans le premier groupe, certains clusters ont été mis à niveau vers la version 1.21.14-gke.4300, et d'autres vers la version 1.23.8-gke.1900, les clusters du deuxième groupe ne peuvent pas être mis à niveau automatiquement car le groupe n'a pas reçu de version qualifiée. Pour faire avancer la mise à niveau dans cette situation, consultez la section Corriger l'éligibilité au sein d'un groupe.
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 pour laquelle les clusters du groupe suivant étaient éligibles, GKE ne peut pas non plus mettre à niveau automatiquement les clusters de groupes en aval.
Par exemple, si tous les clusters du premier groupe ont été mis à niveau vers la version 1.21.14-gke.4300, mais que les clusters du deuxième groupe exécutent la version 1.22 (où la cible de mise à niveau est 1.23.8-gke.1900), les clusters du deuxième groupe ne sont pas mis à jour automatiquement. Le premier groupe a qualifié la version 1.21.14-gke.4300, mais les clusters du deuxième groupe (actuellement sur la version 1.22) ne sont éligibles que pour la cible de mise à niveau 1.23.8-gke.1900. GKE ne peut donc pas automatiquement mettre à niveau ces clusters. Pour faire avancer la mise à niveau dans cette situation, consultez la section Corriger l'éligibilité entre les groupes.
Fonctionnement du séquençage du déploiement 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 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 la section Retarder l'achèvement du déploiement de la version du groupe.
Fonctionnement du séquençage du déploiement 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 la section 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 des nœuds utilisent leur stratégie de mise à niveau des 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 la section Mises à niveau automatiques des nœuds.
Si les mises à niveau de nœuds ne peuvent pas se terminer 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. Pour en savoir plus, consultez la section Considérations lors de la configuration d'un intervalle de maintenance.
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.24.2-gke.100, le premier groupe de la séquence peut déployer simultanément la version 1.24.3-gke.500.
É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 solution 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 canal de publication 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 avec trois étapes de déploiement, car vous ne pouvez créer une séquence de déploiement qu'à trois 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 trois groupes.
- Vous ne pouvez pas utiliser la gestion de parc.
- Vous effectuez fréquemment des mises à niveau manuelles, qui entraînent des mises à niveau automatiques différentes pour les clusters d'un groupe.
Pour créer des séquences de déploiement basées sur l'équipe, vous devez également pouvoir activer GKE Enterprise dans vos projets hôtes de parc.
Limites
Pour mettre à niveau vos clusters avec le séquençage du déploiement, vous devez respecter les limites suivantes :
- Si vous utilisez le séquençage du déploiement basée sur l'équipe, enregistrez un cluster dans un seul niveau d'accès d'équipe. Si un cluster est enregistré dans plusieurs niveaux d'accès d'équipe, GKE ne peut pas automatiquement le mettre à niveau dans une séquence de déploiement basée sur l'équipe.
- Il n'est pas possible de créer une séquence de déploiement basée sur l'équipe avec plusieurs niveaux d'accès d'équipe dans le même parc.
- 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 des séquences de déploiement entre les niveaux d'accès d'une équipe ou des séquences de déploiement entre les parcs. Vous ne pouvez pas créer de séquences mixtes avec des parcs et des niveaux d'accès d'équipe dans la même séquence.
- Assurez-vous que tous les clusters d'une séquence de déploiement sont enregistrés dans la même version disponible et exécutent la même version mineure.
Problèmes connus
- 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. Cette erreur est plus susceptible de se produire sur le premier groupe de clusters et devrait être résolue 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 ne comporte pas de groupe en amont, les mises à niveau du cluster ne sont pas transmises au groupe en aval, car le groupe vide ne peut pas qualifier les versions.
- Si le groupe vide comporte un groupe en amont, toutes les mises à niveau de cluster en attente passent à l'état
COMPLETEet se propagent au groupe en aval.
- En raison de la façon dont GKE suit les mises à niveau correctives et mineures, vous pouvez voir deux mises à niveau du même type et de la même version, mais avec des états différents lors de la vérification de l'état du champ d'application.