Séquencer le déploiement des mises à niveau des clusters

Cette page explique comment gérer les mises à niveau des clusters GKE à l'aide du séquençage du déploiement. Pour en savoir plus, consultez la page À propos des mises à niveau des clusters avec le séquençage du déploiement.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

• Activez l'API Google Kubernetes Engine.
Activer l'API Google Kubernetes Engine
• Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.

• Assurez-vous d'avoir activé les API requises pour les parcs. Ces API doivent être activées dans vos projets hôtes de parc pour permettre la création de n'importe quel type de séquence de déploiement.
• Assurez-vous d'avoir activé GKE Enterprise dans vos projets hôtes de parc si vous souhaitez créer une séquence de déploiement basée sur une équipe (preview).
• Pour les instructions Terraform, assurez-vous d'utiliser la version 5.13.0 ou ultérieure du fournisseur google.

Rôles requis

• Assurez-vous de disposer des autorisations IAM requises pour l'enregistrement de cluster. Vous devez accorder les autorisations suivantes :
  • Des autorisations d'enregistrement de cluster, dans vos projets hôtes de parc.
  • Autorisations d'administrateur de cluster pour tous les clusters GKE à enregistrer.
  • Autorisations d'enregistrement de cluster multiprojets pour tous les clusters GKE à enregistrer dans un parc d'un autre projet.

Configurer une séquence de déploiement

Ce document explique comment créer une séquence de déploiement à l'aide de groupes de clusters organisés par parcs ou niveaux d'accès d'équipe. Ce document utilise le terme groupe pour désigner à la fois les parcs et les champs d'application d'équipe, car vous pouvez créer une séquence de déploiement organisée avec l'une ou l'autre méthode de regroupement.

Vous pouvez créer une séquence de cinq groupes de clusters au maximum (trois pour une séquence basée sur une équipe), et choisir le temps de stabilisation des tests souhaité une fois les mises à niveau des clusters terminées dans un groupe (30 jours maximum). Vous pouvez inclure à la fois des clusters Autopilot et Standard.

Pour créer une séquence de déploiement, vos clusters doivent être organisés en groupes de parcs ou de niveaux d'accès d'équipe. Pour savoir comment organiser vos clusters, consultez l'exemple de banque de la communauté. Une fois qu'ils sont organisés en groupes, vous pouvez créer une séquence de déploiement en définissant les relations de groupe en amont et le temps de stabilisation de chaque groupe. Dans une séquence de déploiement, en amont fait référence au groupe précédent et en aval au groupe suivant.

Organiser vos clusters en groupes

Dans une séquence de déploiement, tous les clusters de tous les groupes doivent être enregistrés dans le même canal de publication et dans la même version mineure. Si ces exigences ne sont pas remplies et si les versions présentent des écarts entre les clusters, cela peut entraîner des problèmes lors du déploiement de la version. Pour en savoir plus, consultez la section Éligibilité au déploiement.

Vous pouvez créer des séquences de déploiement entre les parcs ou des séquences de déploiement entre les niveaux d'accès d'équipe d'une équipe (preview).

Comme vous l'avez vu dans À propos des mises à niveau des clusters avec le séquençage du déploiement, 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'application spécifiques. Vous devez activer GKE Enterprise pour utiliser les champs d'application d'équipe. Les limites suivantes s'appliquent lors de l'utilisation ou de la création de niveaux d'accès d'équipe pour le séquençage du déploiement :

• Les séquences basées sur l'équipe nécessitent des clusters à location unique. En d'autres termes, chaque cluster n'est associé qu'à une seule équipe. Les clusters partagés (qui sont compatibles avec la gestion d'équipe de flotte générale) ne sont pas compatibles avec le séquençage du déploiement.

• Chaque niveau d'accès d'équipe doit se trouver dans un parc différent afin de créer une séquence de déploiement entre eux. Il n'est pas possible de créer une séquence de déploiement entre différents niveaux d'accès d'équipe dans le même parc.

Si vous avez déjà organisé vos clusters groupes, vous pouvez ignorer les étapes suivantes et passer à la section Créer une séquence de déploiement.

Créer une séquence de déploiement

Une séquence de déploiement est organisée sous la forme d'une liste associée avec cinq éléments maximum.

Lorsque vous créez une séquence de déploiement, vous définissez les propriétés suivantes pour chaque groupe de clusters, soit un parc, soit un niveau d'accès d'équipe :

• Groupe en amont : parc ou niveau d'accès d'équipe en amont, qui qualifie de nouvelles versions pour le groupe en aval. Vous ne configurez pas de groupe en amont pour le premier groupe d'une séquence.
• Temps de stabilisation : le temps de stabilisation d'un groupe correspond au délai entre la fin des mises à niveau (ou le déploiement a pris 30 jours) et le début des mises à niveau sur le groupe en aval. Pour en savoir plus, consultez la section Fonctionnement de la qualification des versions dans une séquence de déploiement.

Vérifier l'état d'une séquence de déploiement

Vous pouvez vérifier l'état d'une séquence de déploiement à l'aide de l'une des méthodes suivantes :

• Surveillez une représentation visuelle d'une séquence de déploiement dans la console Google Cloud (preview, séquence de déploiement basée sur un parc uniquement).
• Utiliser gcloud CLI ou l'API GKE Hub pour vérifier l'état d'une séquence de déploiement.

Surveiller une séquence de déploiement dans la console Google Cloud

1. Accédez à la page Séquençage du déploiement dans la console Google Cloud .

   Accéder à la page "Séquençage du déploiement"

2. Affichez la séquence dans la section Surveiller votre séquence de déploiement. Si aucune séquence de déploiement ne s'affiche, passez à une autre séquence de déploiement ou créez une séquence de déploiement si vous ne l'avez pas déjà fait.

Surveiller une séquence de déploiement à l'aide de la console

Sur cette page, vous pouvez afficher la séquence de déploiement associée au parc de votre projet. Vous pouvez afficher la progression d'une séquence de déploiement selon deux méthodes :

• Afficher l'intégralité de la séquence de déploiement, ou consulter les états des parcs et des clusters individuels dans ces parcs, ainsi que le temps de stabilisation entre les parcs. Vous pouvez également visualiser la séquence où il n'y a pas de mise à niveau active si vous souhaitez vérifier la configuration de la séquence.
• Filtrer les résultats par type de mise à niveau (plan de contrôle ou nœud) et par version spécifique (par exemple, 1.31.6-gke.500).

Vous pouvez surveiller visuellement l'ensemble de votre séquence de déploiement pendant que GKE met à niveau tous les clusters de la séquence, en qualifiant une nouvelle version dans tous les environnements avant de mettre à niveau les clusters de votre environnement de production. Vous pouvez gérer une séquence de déploiement à l'aide de gcloud CLI et apporter les modifications nécessaires pendant cette surveillance.

Passer à une autre séquence de déploiement

Cette page affiche la séquence de déploiement basée sur un parc si le projet actif dans la console Google Cloud est un projet hôte de parc pour un parc inscrit dans une séquence de déploiement.

Si vous souhaitez afficher une séquence de déploiement différente, sélectionnez un projet hôte de parc associé à une séquence de déploiement différente dans le sélecteur de projets en haut de la page.

Utiliser la CLI gcloud

Utilisez ces commandes dans les sections suivantes pour vérifier la progression des mises à niveau dans une séquence de déploiement. Pour en savoir plus sur les informations fournies, consultez la section Informations d'état pour une séquence de déploiement.

Pour exécuter ces commandes, assurez-vous de disposer des autorisations requises pour chaque projet hôte de parc. Par exemple, si la séquence comporte des champs d'application multiprojets dans différents parcs, vous avez besoin d'autorisations dans chaque projet pour décrire la séquence.

Pour les commandes suivantes, si vous n'avez besoin d'informations que sur un parc ou un champ d'application de la séquence, remplacez l'option --show-linked-cluster-upgrade par --show-cluster-upgrade.

gcloud container fleet clusterupgrade describe \
    --show-linked-cluster-upgrade --project=FLEET_PROJECT_ID

gcloud container fleet scopes describe SCOPE_NAME \
    --show-linked-cluster-upgrade
    --project=SCOPE_PROJECT_ID

Pour afficher l'état de clusters individuels dans un parc ou un niveau d'accès d'équipe, exécutez la commande suivante dans le projet hôte du parc et consultez la section membershipStates :

gcloud container fleet features describe clusterupgrade

Informations sur l'état d'une séquence de déploiement

Lorsque vous vérifiez l'état d'un déploiement de version, vous pouvez voir la progression de chaque groupe et de chaque cluster au sein de ce groupe.

Consultez le tableau suivant pour connaître les états potentiels d'un cluster ou d'un groupe :

Dans la sortie de ces commandes, les attributs clusterUpgrade(s).spec et clusterUpgrade(s).state contiennent des informations supplémentaires sur la mise à niveau du cluster, telles que le temps de stabilisation, les remplacements de mise à niveau du cluster et l'état de la mise à niveau.

Gérer une séquence de déploiement

Vous pouvez contrôler les mises à niveau automatiques des clusters avec le séquençage du déploiement de plusieurs manières, comme expliqué dans les sections suivantes.

Modifier le temps de stabilisation d'un groupe

Vous pouvez modifier le délai de stabilisation par défaut pour un groupe ou le délai de stabilisation pour la mise à niveau de ce groupe vers une version spécifique. La valeur maximale est de 30 jours.

Modifier le temps de stabilisation par défaut

Vous pouvez modifier le temps de trempage par défaut dans la console Google Cloud (Preview, séquence de déploiement basée sur un parc uniquement) ou avec gcloud CLI.

Ignorer le temps de stabilisation par défaut

Vous pouvez modifier le temps de stabilisation pour un déploiement de version spécifique afin qu'il soit différent du temps de stabilisation par défaut du groupe. Par exemple, si vous avez déjà qualifié une nouvelle version et que vous souhaitez que les mises à niveau commencent dans le groupe suivant, vous pouvez définir le temps de stabilisation sur zéro. Vous pouvez également l'utiliser si vous souhaitez obtenir plus de temps que le temps de stabilisation par défaut pour qualifier une version spécifique.

Le temps de stabilisation étant défini par groupe, si vous souhaitez remplacer le temps de stabilisation pour d'autres groupes de cette séquence, mettez-les à jour à l'aide de cette même commande avec le nom du parc ou du champ d'application remplacé, en fonction du type de séquence.

Pour les instructions de cette section, remplacez les variables suivantes :

• SOAK_TIME : temps de stabilisation à utiliser autre que la valeur par défaut (par exemple, "0d" si vous souhaitez ignorer le temps de stabilisation pour un déploiement de version).
• UPGRADE_NAME : type de mise à niveau, soit k8s_control_plane pour les mises à niveau du plan de contrôle, soit k8s_node pour les mises à niveau des nœuds.

• VERSION : version de GKE pour laquelle vous souhaitez remplacer le temps de stabilisation par défaut après le déploiement de la version (par exemple, 1.25.2-gke.400) dans ce groupe.

gcloud container fleet clusterupgrade update
    --add-upgrade-soaking-override=SOAK_TIME \
    --upgrade-selector=name=UPGRADE_NAME,version=VERSION

gke_upgrade_overrides {
    upgrade {
      name = "UPGRADE_NAME"
      version = "VERSION"
    }
    post_conditions {
      soaking = "SOAK_TIME"
    }
  }

gcloud container fleet scopes update SCOPE_NAME \
    --add-upgrade-soaking-override=SOAK_TIME \
    --upgrade-selector=name=UPGRADE_NAME,version=VERSION

Mettre à jour les groupes dans une séquence de déploiement

Vous pouvez modifier une séquence de déploiement existante pour ajouter, supprimer ou modifier l'ordre des groupes dans la séquence. Pour effectuer ces modifications, mettez à jour les associations entre les groupes.

Vous pouvez effectuer ces étapes dans la console Google Cloud (preview, séquence de déploiement basée sur un parc uniquement) ou avec la gcloud CLI.

Retarder l'achèvement du déploiement de la version du groupe

Si vous devez empêcher temporairement un groupe de terminer le déploiement d'une nouvelle version sur ses clusters, vous pouvez ajouter une exclusion de maintenance à tout cluster qui n'est pas mis à niveau vers la version cible. Cela peut suspendre le délai d'évaluation d'un groupe ou le laisser en aval pendant 30 jours maximum. Au bout de 30 jours, le groupe commence à se stabiliser.

Vous pouvez également modifier le temps de stabilisation pour ce groupe sur 30 jours afin de maximiser la durée d'attente de la séquence de déploiement avant de passer au groupe suivant.

Si vous devez retarder davantage les mises à niveau à venir pour le groupe suivant, vous pouvez utiliser des exclusions de maintenance pour les clusters du groupe suivant.

Passer d'une séquence de déploiement basée sur un parc à une séquence de déploiement basée sur une équipe

Vous pouvez passer de séquences basées sur un parc à des séquences basées sur une équipe, et inversement. Les instructions supposent que vous effectuez un transfert entre des séquences organisées comme celles illustrées dans les diagrammes d'exemple.

Supprimer une séquence

Pour supprimer une séquence, vous devez supprimer les associations en amont pour chacun des groupes, à l'exception du premier. Le premier groupe n'a pas de groupe en amont.

Vous pouvez effectuer ces étapes dans la console Google Cloud (preview, séquence de déploiement basée sur un parc uniquement) ou avec la gcloud CLI.

gcloud container fleet clusterupgrade update --reset-upstream-fleet

gcloud container fleet scopes update SCOPE_NAME --reset-upstream-scope

Dépannage

Résoudre les problèmes d'éligibilité au déploiement

Si tous les clusters d'une séquence de déploiement n'ont pas la même cible de mise à niveau, GKE risque de ne pas pouvoir procéder aux mises à niveau des clusters. Les mises à niveau automatiques ne peuvent pas être effectuées si un groupe en amont ne qualifie pas une cible de mise à niveau à transmettre au groupe en aval. Les mises à niveau automatiques ne peuvent pas non plus être effectuées si les clusters du groupe en amont qualifient une cible de mise à niveau non valide pour les clusters du groupe en aval.

Pour vérifier si votre séquence de déploiement présente des problèmes d'éligibilité, vérifiez l'état de la séquence de déploiement. Si un groupe n'est pas éligible, suivez les instructions pour afficher l'état des clusters individuels dans un groupe.

Pour faire progresser immédiatement les mises à niveau des clusters, supprimez tous les clusters dont l'état est INELIGIBLE en suivant les instructions de la section Faire progresser les déploiements partiellement éligibles.

Corriger l'éligibilité d'un groupe

Si un cluster n'est pas éligible car il utilise une version antérieure (par exemple, la plupart des clusters du groupe sont mis à niveau de la version 1.23 vers la version 1.24 et un cluster se trouve dans la version 1.22), vous pouvez mettre à jour le cluster manuellement vers la version 1.24 pour résoudre l'écart de version.

Dans un groupe, si un cluster n'est pas éligible en raison d'une version ultérieure (par exemple, la plupart des clusters du groupe sont mis à niveau de la version 1.23 à la version 1.24 et un cluster se trouve dans la version 1.25), vous ne pouvez pas revenir manuellement au cluster pour résoudre l'écart de version et supprimer le cluster.

Correction de l'éligibilité entre les groupes

Entre les groupes, en cas de non-concordance dans les cibles de mise à niveau où le groupe en aval se trouve sur une version plus récente (par exemple, le groupe en amont est passé de la version 1.23 à la version 1.24, et les clusters du groupe en aval se trouvent dans la version 1.25), vous pouvez mettre à niveau manuellement les clusters du groupe en amont vers la version 1.25 pour vous assurer que les mises à niveau se poursuivent.

Entre les groupes, en cas de non-concordance dans les cibles de mise à niveau où le groupe en aval se trouve dans une version antérieure (par exemple, le groupe en amont est passé de 1.24 à 1.25, et les clusters du groupe en aval se trouvent dans la version 1.23), vous pouvez mettre à niveau manuellement les clusters du groupe en aval vers la version 1.24 ou 1.25 pour vous assurer que les mises à niveau se poursuivent.

Faire progresser les déploiements partiellement éligibles

Si les mises à niveau d'un cluster dans un groupe ne se terminent pas en raison de problèmes d'éligibilité au déploiement (par exemple, des écarts de version au sein d'un groupe), vous pouvez supprimer du groupe les clusters qui ne sont pas éligibles à la mise à niveau cible du groupe pour terminer le déploiement de la version et commencer le temps de stabilisation, ou passer au groupe suivant dans la séquence de déploiement. Vous pouvez également supprimer un cluster d'un groupe pour d'autres raisons, par exemple si l'utilisation de ce cluster n'est plus liée aux autres clusters du groupe.

Suivez les instructions pour annuler l'enregistrement d'un cluster d'un parc ou supprimer des clusters des niveau d'accès d'équipe, selon le type de séquence de déploiement.

Une fois que vous avez supprimé tous les clusters qui empêchent le déploiement de la version d'un groupe, celui-ci peut se terminer. Pour vérifier cela, suivez les instructions de la section Vérifier l'état d'un déploiement de version.

Étapes suivantes

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