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

Ce document vous explique comment gérer les mises à niveau de clusters Google Kubernetes Engine (GKE) qui utilisent le déploiement séquentiel avec des étapes personnalisées. Pour créer une séquence de déploiement, vous devez utiliser des groupes de clusters organisés en parcs et, éventuellement, des sous-ensembles de clusters de ces parcs. Vous pouvez 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 en savoir plus sur le fonctionnement de cette fonctionnalité, consultez À propos du séquençage du déploiement avec des étapes personnalisées.

Si vous gérez des déploiements sur plusieurs parcs, nous vous recommandons d'utiliser un projet dédié pour héberger vos objets RolloutSequence. Ce projet sert de parent et de coordinateur pour les déploiements de la séquence. Ce projet ne fait généralement pas partie de la séquence, c'est-à-dire qu'il ne contient pas de flottes ni de clusters qui font partie de la séquence.

Avant de commencer

Rôles requis

Pour créer un projet, vous devez disposer du rôle Créateur de projet (roles/resourcemanager.projectCreator), qui contient l'autorisation resourcemanager.projects.create. Découvrez comment attribuer des rôles.

Pour créer ou modifier une séquence de déploiement, vous devez disposer du rôle IAM Éditeur de parc (roles/gkehub.editor) dans chaque projet hôte de parc de la séquence de déploiement et dans votre projet hôte de séquence de déploiement. Ce rôle fournit les autorisations suivantes :

  • gkehub.rolloutsequences.create
  • gkehub.rolloutsequences.get
  • gkehub.rolloutsequences.list
  • gkehub.rolloutsequences.update
  • gkehub.rolloutsequences.delete
  • gkehub.fleet.update

Ces autorisations vous permettent de créer, d'accéder et de modifier des objets RolloutSequence, et d'utiliser des flottes dans la séquence de déploiement.

Si vous devez enregistrer ou annuler l'enregistrement de clusters dans un parc, vous devez disposer de toutes les autorisations suivantes :

Vous pouvez créer des séquences de déploiement à l'aide de parcs hébergés dans des projets d'une ou de plusieurs organisations, si vous disposez des autorisations nécessaires pour ces projets.

Pour en savoir plus sur les rôles IAM avec le moins de privilèges requis pour différentes tâches, consultez Obtenir des suggestions de rôles prédéfinis avec l'aide de Gemini.

Configurer une séquence de déploiement

Pour créer une séquence de déploiement, vos clusters doivent être organisés en groupes de parcs. Vous pouvez également créer des étapes précises qui peuvent cibler des sous-ensembles spécifiques de clusters au sein d'un parc à l'aide d'étiquettes Kubernetes. Pour savoir comment organiser vos clusters, consultez l'exemple de banque communautaire. Après avoir organisé les clusters en groupes et les avoir éventuellement libellés, vous créez une séquence de déploiement en définissant la liste ordonnée des étapes et le temps de stabilisation pour chaque groupe.

Organiser les clusters en parcs

Dans une séquence de déploiement, nous vous recommandons d'enregistrer tous les clusters dans le même version disponible. Si les clusters ne sont pas enregistrés dans le même canal, GKE sélectionne une version du canal le plus conservateur de la séquence. Par exemple, si des clusters sont enregistrés dans les canaux Stable et Standard, GKE choisit la version du canal Stable. Nous vous recommandons également que tous les clusters exécutent la même version mineure pour pouvoir bénéficier de la même version cible de mise à niveau automatique.

Si vous avez déjà organisé vos clusters en parcs, vous pouvez ignorer les étapes suivantes et passer à la section Créer des sous-ensembles de clusters.

  1. Regroupez vos clusters dans des parcs. Vous pouvez organiser vos clusters par environnement de déploiement, comme les tests, la préproduction et la production (recommandé).
  2. Enregistrez chaque cluster dans un parc en fonction du regroupement choisi.

Créer des sous-ensembles de clusters (facultatif)

Pour qu'une étape de votre séquence de déploiement cible des clusters spécifiques, vous devez les étiqueter.

Par exemple, pour tester une nouvelle version sur un petit sous-ensemble de clusters avant un déploiement complet, vous pouvez appliquer un libellé canary à ces clusters. Pour ajouter le libellé canary avec la valeur true à un cluster à l'aide de Google Cloud CLI, exécutez la commande suivante :

gcloud container clusters update CLUSTER_NAME \
    --location=CLUSTER_LOCATION\
    --update-labels=canary=true

Remplacez les éléments suivants :

L'option --update-labels=canary=true demande à GKE d'appliquer le libellé canary au cluster .

Pour savoir comment ajouter un libellé à un cluster, consultez Ajouter ou mettre à jour des libellés pour des clusters existants.

Créer une séquence de déploiement avec des étapes personnalisées

Une séquence de déploiement avec des étapes personnalisées définit l'ordre des mises à niveau en définissant les étapes de manière déclarative. Avec la gcloud CLI, vous utilisez un fichier YAML, et avec Terraform, vous ajoutez un bloc de ressources à votre configuration. En suivant les étapes décrites dans cette section, vous allez créer un RolloutSequence.

Pour que la séquence capture tous les clusters, chaque parc doit inclure une étape globale (une étape sans sélecteur de libellé). Cette étape générique capture tous les clusters restants que GKE n'a pas sélectionnés lors des étapes précédentes. Si vous attribuez un même cluster à plusieurs étapes d'un même RolloutSequence, pour résoudre les conflits, GKE attribue implicitement le cluster uniquement à l'étape la plus ancienne.

Les exemples de configurations suivants créent trois étapes :

  • La première étape cible tous les clusters du parc dev. Une fois la mise à niveau terminée, une période de stabilisation de sept jours (7d) est nécessaire.
  • La deuxième étape cible les clusters du parc prod qui comportent le libellé canary=true. Une fois la mise à niveau terminée, une période de stabilisation de sept jours (7d) est nécessaire.
  • La troisième étape cible les clusters restants du parc prod. Une fois la mise à niveau terminée, un temps de stabilisation de sept jours (7d) est nécessaire.

gcloud

  1. Enregistrez le manifeste suivant sous le nom rollout-sequence.yaml :

    - stage:
      fleet-projects:
      - projects/dev
      soak-duration: 7d
    - stage:
      fleet-projects:
      - projects/prod
      soak-duration: 7d
      label-selector: resource.labels.canary=='true'
    - stage:
      fleet-projects:
      - projects/prod
      soak-duration: 7d
    

    Veuillez noter les points suivants :

    • stage : inclut un parc ou un sous-ensemble de clusters au sein d'un parc. Les clusters des étapes précédentes doivent être entièrement mis à niveau et testés avant que la séquence ne passe à l'étape suivante. Toutefois, si un cluster n'a pas terminé sa mise à niveau 30 jours après le début du processus de mise à niveau, GKE lance la période de stabilisation.
    • fleet-projects : liste des parcs à partir desquels sélectionner des clusters pour cette étape. Vous ne pouvez faire référence qu'à une seule flotte par étape. Un parc est identifié par le projet dans lequel il est hébergé. Ce projet peut être différent de celui dans lequel se trouvent les clusters, si le parc contient des appartenances inter-projets. Le format permettant de spécifier un projet de parc est projects/PROJECT_ID.
    • label-selector (facultatif) : sélectionne un sous-ensemble de clusters à partir des parcs spécifiés. Ce champ utilise la syntaxe du Common Expression Language (CEL) et doit commencer par resource.labels.
    • soak-duration : délai d'attente après la mise à niveau de tous les clusters d'une étape précédente avant de passer à l'étape suivante. Exprimée en secondes, minutes, heures et jours.
  2. Pour créer la séquence de déploiement que vous avez définie dans le fichier manifeste rollout-sequence.yaml, exécutez la commande suivante :

    gcloud container fleet rolloutsequences create ROLLOUT_SEQUENCE_NAME \
        --display-name=DISPLAY_NAME \
        --stage-config=rollout-sequence.yaml
    

    Remplacez les éléments suivants :

    • ROLLOUT_SEQUENCE_NAME : identifiant immuable conforme aux spécifications RFC-1034, par exemple test-rollout-sequence.
    • DISPLAY_NAME : chaîne lisible pour votre séquence de déploiement.

Terraform

Cette section explique comment créer une séquence de déploiement avec des étapes personnalisées à l'aide de Terraform. Vous pouvez également utiliser cette ressource pour mettre à jour la séquence. Pour en savoir plus, consultez la documentation de référence sur google_gke_hub_rollout_sequence.

  1. Ajoutez le bloc suivant à votre configuration Terraform pour créer une ressource de séquence de déploiement :

    resource "google_gke_hub_rollout_sequence" "rollout_sequence" {
      rollout_sequence_id = "ROLLOUT_SEQUENCE_NAME"
      display_name        = "DISPLAY_NAME"
      stages {
        fleet_projects = ["projects/dev"]
        soak_duration  = "7d"
      }
      stages {
        fleet_projects = ["projects/prod"]
        cluster_selector {
          label_selector = "resource.labels.canary=='true'"
        }
        soak_duration  = "7d"
      }
      stages {
        fleet_projects = ["projects/prod"]
        soak_duration  = "7d"
      }
    }
    

    Remplacez les éléments suivants :

    • ROLLOUT_SEQUENCE_NAME : identifiant immuable conforme aux spécifications RFC-1034, par exemple test-rollout-sequence.
    • DISPLAY_NAME : chaîne lisible pour votre séquence de déploiement.

Déployer une version spécifique

Vous pouvez déployer une version spécifique dans votre séquence de déploiement. Pour en savoir plus, consultez Déployer une version spécifique.

Vous pouvez déployer une version sur les plans de contrôle ou les nœuds des clusters de votre séquence de déploiement. Vous pouvez sélectionner indépendamment les versions à déployer sur les plans de contrôle ou les nœuds.

GKE ne peut déployer qu'une seule version à la fois dans une étape vers le plan de contrôle ou les nœuds, respectivement. Si vous avez un déploiement en cours dans la première étape de la séquence de déploiement, GKE effectue les opérations suivantes, selon que vous gérez votre séquence de déploiement avec gcloud CLI ou Terraform :

  • gcloud CLI : lorsque vous exécutez la commande, une invite interactive vous demande si vous souhaitez annuler le déploiement existant pour créer le déploiement vers la version que vous avez spécifiée. Si vous répondez par l'affirmative, GKE annule le déploiement existant et en crée un autre. Sinon, GKE conserve le déploiement existant et n'en crée pas de nouveau, comme vous l'aviez demandé à l'origine dans la commande.
  • Terraform : lorsque vous mettez à jour votre configuration Terraform comme décrit dans la section suivante, GKE annule le déploiement existant s'il est en cours lors de la première étape.

Déployer une version sur les plans de contrôle dans une séquence de déploiement

gcloud

Exécutez la commande ci-dessous.

gcloud container fleet rolloutsequences upgrade ROLLOUT_SEQUENCE_NAME \
    --control-plane-version="CONTROL_PLANE_VERSION"

Remplacez les éléments suivants :

  • ROLLOUT_SEQUENCE_NAME : nom de la séquence de déploiement.
  • CONTROL_PLANE_VERSION : version à déployer. Vous pouvez choisir une version spécifique, telle que 1.34.7-gke.1055000, ou utiliser un alias de version. Pour en savoir plus, consultez la section Spécifier la version du cluster.

Terraform

Si vous utilisez Terraform pour gérer votre séquence de déploiement, vous pouvez déployer une version spécifique en l'ajoutant au bloc que vous avez utilisé pour créer la séquence de déploiement.

Ajoutez le champ suivant au bloc. Vous pouvez ajouter le champ n'importe où, sauf entre les blocs stages, qui doivent être consécutifs :

min_control_plane_version = "CONTROL_PLANE_VERSION"

Remplacez CONTROL_PLANE_VERSION par la version à déployer. Vous pouvez choisir une version spécifique, telle que 1.34.7-gke.1055000, ou utiliser un alias de version. Pour en savoir plus, consultez la section Spécifier la version du cluster.

Si vous avez déjà utilisé ce champ pour déployer une version du plan de contrôle, il reste dans le bloc. Remplacez la version précédente déployée par la version CONTROL_PLANE_VERSION que vous souhaitez déployer cette fois-ci.

Déployer une version sur les nœuds d'une séquence de déploiement

gcloud

Exécutez la commande ci-dessous.

gcloud container fleet rolloutsequences upgrade ROLLOUT_SEQUENCE_NAME \
    --node-version="NODE_VERSION"

Remplacez les éléments suivants :

  • ROLLOUT_SEQUENCE_NAME : nom de la séquence de déploiement.
  • NODE_VERSION : version à déployer, par exemple 1.34.7-gke.1055000.

Terraform

Si vous utilisez Terraform pour gérer votre séquence de déploiement, vous pouvez déployer une version spécifique en l'ajoutant au bloc que vous avez utilisé pour créer la séquence de déploiement.

Ajoutez le champ suivant au bloc. Vous pouvez ajouter le champ n'importe où, sauf entre les blocs stages, qui doivent être consécutifs :

min_node_version = "NODE_VERSION"

Remplacez NODE_VERSION par la version à déployer, par exemple 1.34.7-gke.1055000. Si vous avez déjà utilisé ce champ pour déployer une version de nœud, il reste dans le bloc. Remplacez la version précédente déployée par la NODE_VERSION que vous souhaitez déployer cette fois-ci.

Vérifier l'état d'un déploiement

Une fois que vous avez configuré une séquence de déploiement, le système crée automatiquement des objets Rollout pour gérer les mises à niveau. Vous pouvez observer et suivre la progression de ces objets à l'aide des commandes Google Cloud CLI.

Lister les déploiements

Pour lister tous les déploiements actifs et historiques dans le projet hôte de votre séquence de déploiement, exécutez la commande suivante :

gcloud container fleet rollouts list --project=HOST_PROJECT_ID

Remplacez HOST_PROJECT_ID par l'ID de votre projet hôte de séquence de déploiement.

Vous pouvez omettre l'option --project=HOST_PROJECT_ID si vous vous trouvez déjà dans le projet où votre séquence de déploiement est hébergée.

Le résultat ressemble à ce qui suit :

NAME                                              STATE      CREATE_TIME
05eb251e4f19269e23-node-1-33-5-gke-1201000-t7mqd  COMPLETED  2025-10-30T20:07:46
05eb251e4f19269e23-kcp-1-33-5-gke-1201000-djwst   COMPLETED  2025-10-30T18:07:06
05eb251e4f19269e23-node-1-33-5-gke-1125000-6bxvu  COMPLETED  2025-10-23T17:46:54
05eb251e4f19269e23-kcp-1-33-5-gke-1125000-2f6ct   RUNNING    2025-10-23T16:41:33

Dans le résultat précédent, les noms de déploiement qui contiennent kcp font référence aux mises à niveau du plan de contrôle, et ceux qui contiennent node font référence aux mises à niveau des nœuds. Le segment du nom du déploiement après kcp ou node est dérivé de la version GKE.

Décrire un déploiement

Pour obtenir des informations détaillées sur un déploiement spécifique, y compris la version cible, l'état et les clusters qui ont été mis à niveau, utilisez la commande describe avec l'ID de déploiement que vous avez obtenu à partir de la commande précédente :

gcloud container fleet rollouts describe ROLLOUT_ID \
  --project=HOST_PROJECT_ID

Remplacez les éléments suivants :

  • ROLLOUT_ID : ID du déploiement que vous avez obtenu lorsque vous avez listé les déploiements.
  • HOST_PROJECT_ID : ID du projet dans lequel votre séquence de déploiement est hébergée.

Exemple :

gcloud container fleet rollouts describe 927e9a989930cf3b55-kcp-1-32-4-gke-1106006 \
  --project=my-hostfleet

Le résultat ressemble à ce qui suit :

createTime: '2025-05-26T11:47:29.909959672Z'
membershipStates:
  projects/dev-project-id/locations/us-central1/memberships/c-1:
    lastUpdateTime: '2025-05-26T12:20:55.601542481Z'
    targets:
    - cluster:   projects/dev-project-id/locations/us-central1/clusters/c-1
      operation: //container.googleapis.com/v1/projects/dev-project-id/locations/us-central1/operations/operation-1234567890-abcdefg-hijklm-nopqrst
      state: SUCCEEDED
    stageAssignment: 1
  projects/dev-project-id/locations/us-central1/memberships/c-2:
    lastUpdateTime: '2025-05-26T12:22:57.151203493Z'
    targets:
    - cluster:   projects/dev-project-id/locations/us-central1/clusters/c-2
      operation: //container.googleapis.com/v1/projects/dev-project-id/locations/us-central1/operations/operation-987654321-ghijkl-mno-pqr-stu-vwxyz
      state: SUCCEEDED
    stageAssignment: 1
  projects/prod-project-id/locations/us-central1/memberships/c-1:
    lastUpdateTime: '2025-05-26T13:03:34.134308942Z'
    targets:
    - cluster: projects/prod-project-id/locations/us-central1/clusters/c-1
      operation: //container.googleapis.com/v1/projects/prod-project-id/locations/us-central1/operations/operation-567891234-efghij-klm-nopq-rstu-vwxyz
      state: SUCCEEDED
    stageAssignment: 2
  projects/prod-project-id/locations/us-central1/memberships/c-2:
    lastUpdateTime: '2025-05-26T13:06:34.025261641Z'
    targets:
    - cluster: projects/prod-project-id/locations/us-central1/clusters/c-1
      operation: //container.googleapis.com/v1/projects/prod-project-id/locations/us-central1/operations/operation-765432198-01a7b896-67c2-523-6fjjh4-icmdydh
      state: SUCCEEDED
    stageAssignment: 2
name: projects/user-hostfleet/locations/global/rollouts/05eb251e4f19269e23-kcp-1-32-4-gke-1106006
rolloutSequence: projects/project-id/locations/global/rolloutSequences/my-sequence
state: COMPLETED
updateTime: '2025-07-22T07:36:51.052691989Z'
versionUpgrade:
  desiredVersion: 1.32.4-gke.1106006
  type: TYPE_CONTROL_PLANE
stages:
- state: COMPLETED
  endTime: '2025-05-26T12:22:28.828506491Z'
  stageNumber: 1
  startTime: '2025-05-26T11:48:28.772658427Z'
  soakDuration: 600s
- state: COMPLETED
  endTime: '2025-05-26T13:06:20.026390832Z'
  stageNumber: 2
  startTime: '2025-05-26T12:32:38.419372153Z'
  soakDuration: 600s

Informations sur l'état d'un déploiement

Lorsque vous décrivez un déploiement, les champs stages et membershipStates de la sortie indiquent respectivement l'état d'avancement de chaque étape et de chaque cluster au sein de cette étape.

Le tableau suivant répertorie les états potentiels d'une étape :

État Description
PENDING La mise à niveau n'a pas encore commencé pour cette étape.
RUNNING La mise à niveau est en cours pour cette étape. Si vous avez configuré un intervalle de maintenance pour les clusters de l'étape, GKE attend que l'intervalle s'ouvre avant de mettre à niveau les clusters.
SOAKING Tous les clusters de cette étape ont terminé leur mise à niveau et l'étape est dans sa période de stabilisation configurée.
FORCED_SOAKING La mise à niveau a pris plus de temps (30 jours). GKE a donc forcé le démarrage de la phase de stabilisation. La mise à niveau se poursuit sur les clusters restants.
COMPLETED La phase d'imprégnation est terminée et le déploiement passe à la phase suivante.

Le tableau suivant liste les états potentiels d'un cluster dans une séquence :

État Description
PENDING La mise à niveau est en attente sur ce cluster.
INELIGIBLE Ce cluster n'est pas éligible à la mise à niveau, probablement en raison d'un écart de version. Le motif d'inéligibilité est indiqué dans le résultat.
RUNNING La mise à niveau est en cours sur ce cluster.
SUCCEEDED La mise à niveau a bien été effectuée sur ce cluster.
FAILED La mise à niveau a échoué sur ce cluster. Les cibles ayant échoué sont réessayées indéfiniment tant que leur étape est active (à l'état RUNNING ou FORCED_SOAKING).

Gérer un déploiement

Vous pouvez gérer un déploiement individuel en suivant les instructions fournies dans les sections suivantes. Pour en savoir plus sur la gestion d'un déploiement et sur les actions correspondantes que vous pouvez effectuer, consultez Gérer un déploiement.

Pour gérer une séquence de déploiement complète, et pas seulement un déploiement spécifique, consultez la section suivante : Gérer une séquence de déploiement.

Suspendre un déploiement

Vous pouvez suspendre un déploiement actif. Pour en savoir plus sur cette action, consultez Mettre en veille un déploiement.

Pour mettre en veille un déploiement, exécutez la commande suivante :

gcloud container fleet rollouts pause ROLLOUT_ID

Remplacez ROLLOUT_ID par l'ID du déploiement que vous souhaitez mettre en veille. Pour obtenir les ID de déploiement des déploiements de votre séquence de déploiement, consultez Lister les déploiements.

Reprendre un déploiement

Vous pouvez reprendre un déploiement suspendu depuis moins de 90 jours. Pour en savoir plus sur cette action, consultez Reprendre un déploiement.

Pour reprendre un déploiement suspendu, exécutez la commande suivante :

gcloud container fleet rollouts resume ROLLOUT_ID

Remplacez ROLLOUT_ID par l'ID du déploiement que vous souhaitez reprendre. Pour obtenir les ID de déploiement des déploiements de votre séquence de déploiement, consultez Lister les déploiements.

Annuler un déploiement

Vous pouvez annuler un déploiement, qu'il soit actif ou mis en veille. Vous ne pouvez pas annuler les déploiements de mises à niveau automatiques obligatoires. Pour en savoir plus sur l'annulation des déploiements, consultez Annuler un déploiement.

Pour annuler un déploiement, exécutez la commande suivante :

gcloud container fleet rollouts cancel ROLLOUT_ID

Remplacez ROLLOUT_ID par l'ID du déploiement que vous souhaitez annuler. Pour obtenir les ID de déploiement des déploiements de votre séquence de déploiement, consultez Lister les déploiements.

Terminer une phase de déploiement

Vous pouvez terminer une étape de déploiement si vous souhaitez que les mises à niveau passent à l'étape suivante. Pour en savoir plus sur cette action, consultez Terminer une étape de déploiement.

Pour terminer une étape de déploiement, exécutez la commande suivante :

gcloud container fleet rollouts force-complete-stage ROLLOUT_ID \
    --stage=STAGE

Remplacez les éléments suivants :

  • ROLLOUT_ID : ID du déploiement pour lequel vous souhaitez terminer une étape. Pour obtenir les ID de déploiement des déploiements de votre séquence de déploiement, consultez Lister les déploiements.
  • STAGE : étape que vous souhaitez terminer maintenant. Par exemple, si vous souhaitez passer à la deuxième étape, saisissez 2. Pour utiliser cette commande, la scène doit être en cours d'exécution ou en phase de trempage.

Ignorer un cluster dans une séquence de déploiement pour un déploiement spécifique

Vous pouvez demander à GKE d'ignorer un cluster dans une séquence de déploiement si vous ne souhaitez pas qu'il soit mis à niveau dans le cadre d'un déploiement actif. Toutefois, cette action supprime le cluster de la séquence de déploiement pour les déploiements actifs et futurs, et pas seulement pour les déploiements actifs.

Pour effectuer cette action et empêcher la mise à niveau d'un cluster lors d'un déploiement actif, consultez Ignorer un cluster dans une séquence de déploiement.

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.

Si vous souhaitez gérer un déploiement d'une séquence de déploiement au lieu de la séquence de déploiement entière et de tous ses déploiements, consultez Gérer un déploiement.

Lister vos séquences de déploiement

Pour lister toutes les séquences de déploiement dans votre projet hôte, exécutez la commande suivante :

gcloud container fleet rolloutsequences list --project=HOST_PROJECT_ID

Remplacez HOST_PROJECT_ID par l'ID de votre projet hôte de séquence de déploiement.

Décrire une séquence de déploiement

Pour afficher les détails d'une séquence de déploiement spécifique, exécutez la commande suivante :

gcloud container fleet rolloutsequences describe ROLLOUT_SEQUENCE_NAME \
  --project=HOST_PROJECT_ID

Remplacez les éléments suivants :

  • ROLLOUT_SEQUENCE_NAME : nom de la séquence de déploiement.
  • HOST_PROJECT_ID : ID du projet hôte de votre séquence de déploiement.

Le résultat ressemble à ce qui suit :

createTime: '2025-10-23T16:40:16.403871189Z'
displayName: my-display-name
name: projects/HOST_PROJECT_ID/locations/global/rolloutSequences/ROLLOUT_SEQUENCE_NAME
stages:
- clusterSelector:
    labelSelector: resource.labels.canary=='true'
  fleetProjects:
  - projects/FLEET_PROJECT_ID
  soakDuration: 600s
- fleetProjects:
  - projects/FLEET_PROJECT_ID
  soakDuration: 300s
uid: 5c5b2ac8-9d76-45f9-92ca-5e6bd3fbcaef
updateTime: '2025-10-23T17:11:57.285678399Z'

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

Par défaut, GKE effectue tous les types de mises à niveau de cluster dans une séquence de déploiement. Vous pouvez limiter le champ d'application des mises à niveau de cluster dans une séquence de déploiement pour n'effectuer que certains types de mises à niveau. Pour en savoir plus, consultez Choisir les types de mises à niveau que GKE effectue dans une séquence de déploiement.

Pour indiquer les types de mises à niveau que vous souhaitez que GKE effectue dans une séquence de déploiement, suivez ces instructions, selon la façon dont vous gérez votre séquence de déploiement :

gcloud

Exécutez la commande ci-dessous.

gcloud container fleet rolloutsequences update ROLLOUT_SEQUENCE_NAME \
    --auto-rollout-scope=TYPES_OF_UPGRADES

Remplacez les éléments suivants :

Terraform

Si vous utilisez Terraform pour gérer votre séquence de déploiement, vous pouvez indiquer les types de mises à niveau que vous souhaitez que GKE effectue dans cette séquence de déploiement en les ajoutant au bloc que vous avez utilisé pour créer la séquence de déploiement.

Ajoutez le champ suivant au bloc. Vous pouvez ajouter le champ n'importe où, sauf entre les blocs stages, qui doivent être consécutifs :

auto_upgrade_config {
  rollout_creation_scope {
    upgrade_types = [
      UPGRADE_TYPES
    ]
  }
}

Remplacez UPGRADE_TYPES par la liste des mises à niveau à effectuer, qui peut inclure une ou plusieurs des options suivantes (chacune entre guillemets) :

Par exemple, si vous souhaitez que seules les versions correctives soient déployées dans la séquence de déploiement, spécifiez la configuration upgrade_types = ["CONTROL_PLANE_PATCH", "NODE_PATCH"].

Si vous définissez upgrade_types = [], GKE n'effectue aucune mise à niveau de cluster dans la séquence de déploiement, à l'exception des déploiements pour les mises à niveau automatiques obligatoires.

Pour revenir au comportement par défaut où GKE effectue tous les types de mises à niveau de cluster dans la séquence de déploiement, spécifiez la configuration upgrade_types = ["CONTROL_PLANE_PATCH", "CONTROL_PLANE_MINOR", "NODE_PATCH", "NODE_MINOR"]. Vous pouvez également supprimer le bloc auto_upgrade_config de votre configuration Terraform.

Modifier une séquence de déploiement

Vous pouvez modifier une séquence de déploiement existante après l'avoir créée. Modifiez votre séquence de déploiement en suivant les instructions ci-dessous, selon la façon dont vous la gérez.

gcloud

Si vous utilisez la gcloud CLI pour gérer votre séquence de déploiement, vous pouvez modifier le fichier de configuration YAML dans lequel vous avez défini la séquence. Par exemple, vous pouvez modifier le temps d'imprégnation d'une étape ou modifier l'étape pour changer l'ordre des mises à niveau. Après avoir modifié le fichier, appliquez les modifications.

Par exemple, si vous avez défini la séquence de déploiement d'origine dans un fichier nommé rollout-sequence.yaml, modifiez le fichier selon vos besoins. Exécutez ensuite la commande suivante :

gcloud container fleet rolloutsequences update test-rollout-sequence \
  --display-name="My Updated Rollout Sequence" \
  --stage-config=rollout-sequence.yaml

Terraform

Si vous utilisez Terraform pour gérer votre séquence de déploiement, modifiez-la en modifiant le bloc que vous avez utilisé pour créer la séquence de déploiement.

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

Vous pouvez demander à GKE d'ignorer un cluster dans une séquence de déploiement. Vous pouvez ignorer un ou plusieurs clusters dans une séquence de déploiement. Pour en savoir plus, consultez Ignorer un cluster dans une séquence de déploiement.

Pour que GKE ignore un cluster dans une séquence de déploiement, procédez comme suit :

  1. Ajoutez un libellé au cluster que vous souhaitez que GKE ignore, ou utilisez un libellé existant. Vous pouvez demander à GKE d'ignorer, par exemple, un libellé tel que status ou un libellé lorsqu'il a une valeur spécifique, telle que status=quarantine.
  2. Définissez la séquence de déploiement pour ignorer les clusters portant ce libellé. Pour ce faire, procédez comme suit, selon la façon dont vous gérez votre séquence de déploiement :

    gcloud

    Exécutez la commande ci-dessous.

    gcloud container fleet rolloutsequences update ROLLOUT_SEQUENCE_NAME \
        --ignored-clusters-selector="resource.labels.LABEL_TO_IGNORE"
    

    Remplacez les éléments suivants :

    • ROLLOUT_SEQUENCE_NAME : nom de la séquence de déploiement.
    • LABEL_TO_IGNORE : nom du libellé des clusters que GKE doit ignorer pour la séquence de déploiement.

    Terraform

    Si vous utilisez Terraform pour gérer votre séquence de déploiement, ajoutez le champ suivant au bloc que vous avez utilisé pour créer la séquence de déploiement. Vous pouvez ajouter le champ n'importe où, sauf entre les blocs stages, qui doivent être consécutifs :

    ignored_clusters_selector {
      label_selector = "resource.labels.LABEL_TO_IGNORE"
    }
    

    Remplacez LABEL_TO_IGNORE par le nom du libellé des clusters que GKE doit ignorer pour la séquence de déploiement.

Ces instructions configurent GKE pour qu'il ignore un type de libellé dans la séquence de déploiement. Si vous souhaitez ignorer plusieurs libellés ou créer des expressions plus complexes pour ignorer les clusters avec des libellés spécifiques, vous pouvez transmettre des valeurs à ce champ à l'aide de la syntaxe d'expression CEL. Tous les libellés doivent utiliser le préfixe resource.labels..

Ajouter un cluster à une séquence de déploiement

Si vous avez suivi les instructions de la section précédente pour que GKE ignore un cluster dans une séquence de déploiement, vous pouvez annuler cette action. Si vous ne souhaitez plus que GKE ignore les clusters, supprimez le sélecteur d'ignorance en suivant les instructions ci-dessous, selon la façon dont vous gérez votre séquence de déploiement :

gcloud

Exécutez la commande suivante :

gcloud container fleet rolloutsequences update ROLLOUT_SEQUENCE_NAME \
    --clear-ignored-clusters-selector

Remplacez ROLLOUT_SEQUENCE_NAME par le nom de la séquence de déploiement.

Cette commande réinitialise le sélecteur d'ignorance afin que GKE n'ignore aucun cluster de la séquence.

Terraform

Si vous utilisez Terraform pour gérer votre séquence de déploiement, supprimez le bloc ignored_clusters_selector du bloc que vous avez utilisé pour créer la séquence de déploiement.

Si vous ne souhaitez pas que GKE ignore un cluster spécifique, supprimez les libellés du cluster.

Supprimer une séquence de déploiement

Pour supprimer une séquence de déploiement, exécutez la commande suivante :

gcloud container fleet rolloutsequences delete ROLLOUT_SEQUENCE_NAME \
  --project=HOST_PROJECT_ID

Remplacez les éléments suivants :

  • ROLLOUT_SEQUENCE_NAME par le nom de la séquence de déploiement.
  • Remplacez HOST_PROJECT_ID par l'ID de votre projet hôte de séquence de déploiement.

Lorsque vous supprimez une séquence de déploiement, tous les déploiements en cours pour cette séquence sont annulés. Les clusters qui faisaient partie de la séquence reviennent au comportement de mise à niveau automatique par défaut pour leur version disponible enregistré.

Migrer une séquence de déploiement existante pour utiliser des étapes personnalisées

Si vous utilisez la version basée sur les flottes de la séquence de déploiement, vous pouvez migrer vers une séquence qui utilise des étapes personnalisées en créant un RolloutSequence qui fait référence à vos flottes existantes. Notez que cette version de la séquence de déploiement n'est pas compatible avec la console Cloud de Confiance .

Pour migrer votre séquence de déploiement, procédez comme suit :

  1. Si vous le souhaitez, avant de migrer la séquence, copiez la configuration de votre séquence de déploiement actuelle. Pour copier la configuration, procédez comme suit :

    Nous vous recommandons de ne pas supprimer votre séquence de déploiement basée sur le parc, afin de pouvoir revenir plus facilement à la version antérieure de la séquence de déploiement, si nécessaire. Vous n'avez pas besoin de supprimer la séquence de déploiement basée sur le parc pour que la séquence de déploiement avec des étapes personnalisées fonctionne, car GKE ne respecte que la séquence de déploiement avec des étapes personnalisées lorsque les deux existent.

  2. Créez un projet Cloud de Confiance by S3NS dédié pour héberger votre séquence de déploiement. Ce projet ne fait généralement pas partie de la séquence, c'est-à-dire qu'il ne contient pas de parcs ni de clusters qui en font partie.

  3. Si vous souhaitez que la séquence de déploiement inclue des clusters spécifiques dans un parc, ajoutez des libellés à ces clusters. Cette étape est facultative.

  4. Suivez les instructions de la section Créer une séquence de déploiement avec des étapes personnalisées.

    Par exemple, le fichier manifeste suivant, nommé rollout-sequence-migrate.yaml, fait référence aux flottes existantes dans une séquence de déploiement précédente. Ce fichier manifeste décrit trois étapes, dont une étape canary dans le parc prod :

    - stage:
      fleet-projects:
      - projects/dev
      soak-duration: 604800s
    - stage:
      fleet-projects:
      - projects/prod
      soak-duration: 604800s
      label-selector: canary=true
    - stage:
      fleet-projects:
      - projects/prod
      soak-duration: 604800s
    

Immédiatement après avoir défini un nouveau RolloutSequence pour vos parcs, GKE commence à mettre à niveau les parcs selon la nouvelle séquence et supprime la configuration précédente.

Migrer une séquence de déploiement avec des étapes personnalisées vers la séquence de déploiement précédente

Cette section explique comment revenir du séquençage du déploiement avec des étapes personnalisées au modèle de séquençage du déploiement basé sur le parc. Ce processus implique la suppression du nouveau fichier RolloutSequence et la restauration de votre configuration d'origine basée sur le parc.

Éviter une mise à niveau dans le désordre lors de la migration

Pour éviter les mises à niveau non souhaitées ou dans le désordre pendant que vous reconfigurez votre séquence, appliquez une exclusion de maintenance à vos clusters de production. Cette étape suspend temporairement toutes les mises à niveau automatiques sur ces clusters. Par exemple, vous pouvez configurer une exclusion de maintenance de type no upgrades sur vos clusters de production.

Supprimer la séquence de déploiement

Supprimez l'objet RolloutSequence qui gère vos clusters. Cette suppression désactive la fonctionnalité d'étapes personnalisées.

Pour supprimer le RolloutSequence, exécutez la commande suivante :

gcloud container fleet rolloutsequences delete ROLLOUT_SEQUENCE_NAME

Remplacez ROLLOUT_SEQUENCE_NAME par le nom de votre séquence de déploiement.

Restaurer la configuration précédente de votre séquence de déploiement (sans étapes personnalisées)

Une fois que vous avez supprimé le RolloutSequence, vous pouvez restaurer votre configuration d'origine basée sur le parc. Ce processus consiste à recréer les fonctionnalités clusterupgrade avec leurs paramètres d'origine, y compris les liens upstreamFleet et les temps d'imprégnation pour chaque parc de votre séquence. Pour en savoir plus, consultez Créer une séquence de déploiement.

Supprimer les exclusions de maintenance

Une fois que vous avez restauré votre configuration d'origine de séquence de déploiement basée sur le parc, supprimez l'exclusion de maintenance que vous avez appliquée lors de la première étape de cette section. GKE reprend les mises à niveau automatiques, qui sont désormais régies par votre séquence restaurée basée sur le parc.

Étape suivante