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.

Rôles requis

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 trois groupes de clusters au maximum, 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 la banque communautaire. Une fois qu'ils sont organisés en groupes, vous pouvez créer une séquence de déploiement en définissant les relations entre les groupes 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 niveaux d'accès 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 une équipe nécessitent des clusters à location unique. En d'autres termes, chaque cluster individuel 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.

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

Parcs

Pour créer une séquence de déploiement basée sur un parc, vous devez d'abord regrouper vos clusters dans des parcs. Vous pouvez organiser vos clusters par environnements de déploiement tels que les tests, la préproduction et la production, comme indiqué dans l'exemple de séquence de déploiement basé sur un parc.

Enregistrez chaque cluster dans un parc en fonction du regroupement choisi.

Équipes

Pour créer une séquence de déploiement basée sur une équipe, vous devez regrouper vos clusters dans des niveaux d'accès d'équipe. Pour ce faire, commencez par organiser vos clusters dans des parcs en fonction des environnements de déploiement tels que les tests, la préproduction et la production, comme indiqué dans l'exemple de séquence de déploiement basée sur un niveau d'accès. Vous pouvez ensuite subdiviser davantage vos clusters en champs d'application pour les clusters de différentes équipes.

  1. Pour chaque cluster de la séquence, enregistrez votre cluster auprès d'un parc. Le cluster doit être enregistré dans le parc du projet dans lequel vous allez créer le niveau d'accès d'équipe de ce cluster. Si vous souhaitez enregistrer un cluster dans un parc dans un autre projet hôte, assurez-vous d'avoir défini les autorisations nécessaires pour l'enregistrement multiprojet.

  2. Créez deux ou trois niveaux d'accès d'équipe pour organiser vos clusters. Créez chaque niveau d'accès dans le projet hôte du parc de l'équipe correspondante. Une séquence de déploiement peut comporter jusqu'à trois niveaux d'accès d'équipe.

    Consultez la documentation de référence sur gcloud alpha container fleet scopes create pour obtenir la liste complète des options. Avec la commande create, vous pouvez utiliser les options des instructions pour créer une séquence de déploiement.

  3. Ajoutez chaque cluster à un champ d'application.

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 comportant jusqu'à trois éléments.

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.

Pour chacune des commandes suivantes, remplacez SOAK_TIME par le temps de stabilisation du groupe que vous mettez à jour.

Parcs (gcloud)

Les instructions suivantes utilisent la commande gcloud container fleet clusterupgrade update, mais vous pouvez définir les mêmes propriétés avec la commande gcloud container fleet clusterupgrade create.

Créez une séquence de déploiement :

  1. Définissez le temps de stabilisation pour le premier parc de la séquence :

    gcloud container fleet clusterupgrade update \
    --default-upgrade-soaking=SOAK_TIME \
    --project=FIRST_FLEET_PROJECT_ID

    Remplacez FIRST_FLEET_PROJECT_ID par l'ID du projet hôte du parc.

  2. Définissez le parc en amont et le temps de stabilisation pour le deuxième parc dans la séquence :

    gcloud container fleet clusterupgrade update \
    --upstream-fleet=FIRST_FLEET_PROJECT_ID \
    --default-upgrade-soaking=SOAK_TIME \
    --project=SECOND_FLEET_PROJECT_ID

    Remplacez FIRST_FLEET_PROJECT_ID par l'ID du projet hôte du premier parc et SECOND_FLEET_PROJECT_ID par l'ID du projet hôte du parc.

  3. Facultatif : si vous souhaitez disposer de trois parcs dans une séquence de déploiement, définissez le parc en amont pour le troisième parc de la séquence :

    gcloud container fleet clusterupgrade update \
    --upstream-fleet=SECOND_FLEET_PROJECT_ID \
    --default-upgrade-soaking=SOAK_TIME \
    --project=THIRD_FLEET_PROJECT_ID

    Remplacez SECOND_FLEET_PROJECT_ID par l'ID du projet hôte du deuxième parc et THIRD_FLEET_PROJECT_ID par l'ID du projet hôte du parc.

Parcs (Terraform)

Cette section explique comment créer une séquence basée sur un parc à 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_feature.

Créez une séquence de déploiement :

  1. Ajoutez le bloc suivant à votre configuration Terraform pour définir le temps de stabilisation du premier parc dans la séquence :

    resource "google_gke_hub_feature" "feature" {
  name = "clusterupgrade"
  location = "global"
  spec {
    clusterupgrade {
      upstream_fleets = []
      post_conditions {
        soaking = "SOAK_TIME"
      }
    }
  }
  project = "FIRST_FLEET_PROJECT_ID"
}

    Remplacez FIRST_FLEET_PROJECT_ID par l'ID du projet hôte du parc.

  2. Ajoutez le bloc suivant à votre configuration Terraform pour définir le parc en amont et le temps de stabilisation du deuxième parc de la séquence :

    resource "google_gke_hub_feature" "feature" {
  name = "clusterupgrade"
  location = "global"
  spec {
    clusterupgrade {
      upstream_fleets = ["FIRST_FLEET_PROJECT_ID"]
      post_conditions {
        soaking = "SOAK_TIME"
      }
    }
  }
  project = "SECOND_FLEET_PROJECT_ID"
}

    Remplacez FIRST_FLEET_PROJECT_ID par l'ID du projet hôte du premier parc et SECOND_FLEET_PROJECT_ID par l'ID du projet hôte du parc.

  3. Facultatif : Si vous souhaitez disposer de trois parcs dans une séquence de déploiement, ajoutez le bloc suivant à votre configuration Terraform pour configurer le parc en amont du parc dans la séquence :

    resource "google_gke_hub_feature" "feature" {
  name = "clusterupgrade"
  location = "global"
  spec {
    clusterupgrade {
      upstream_fleets = ["SECOND_FLEET_PROJECT_ID"]
      post_conditions {
        soaking = "SOAK_TIME"
      }
    }
  }
  project = "THIRD_FLEET_PROJECT_ID"
}

    Remplacez SECOND_FLEET_PROJECT_ID par l'ID du projet hôte du deuxième parc et THIRD_FLEET_PROJECT_ID par l'ID du projet hôte du parc.

Équipes – gcloud

Vous pouvez définir ces propriétés lorsque vous créez ou mettez à jour un niveau d'accès d'équipe. Les instructions suivantes utilisent la commande gcloud alpha container fleet scopes update, mais vous pouvez définir les mêmes propriétés lorsque vous créez un niveau d'accès d'équipe avec la commande gcloud alpha container fleet scopes create.

Pour chacune de ces commandes, remplacez les variables par le nom du niveau d'accès d'équipe correspondant ou par l'ID de projet hôte du parc du niveau d'accès d'équipe.

Créez une séquence de déploiement :

  1. Définissez le temps de stabilisation pour le premier champ d'application de la séquence :

    gcloud alpha container fleet scopes update projects/FIRST_SCOPE_PROJECT_ID/locations/global/scopes/FIRST_SCOPE_NAME \
    --default-upgrade-soaking=SOAK_TIME \
    --project=FIRST_SCOPE_PROJECT_ID

  2. Définissez le champ d'application en amont et le temps de stabilisation pour le deuxième champ d'application de la séquence :

    gcloud alpha container fleet scopes update projects/SECOND_SCOPE_PROJECT_ID/locations/global/scopes/SECOND_SCOPE_NAME \
    --upstream-scope=projects/FIRST_SCOPE_PROJECT_ID/locations/global/scopes/FIRST_SCOPE_NAME \
    --default-upgrade-soaking=SOAK_TIME \
    --project=SECOND_SCOPE_PROJECT_ID

  3. Facultatif : si vous souhaitez disposer de trois niveaux d'accès d'équipe dans une séquence de déploiement, définissez le niveau d'accès d'équipe en amont du troisième niveau d'accès dans la séquence :

    gcloud alpha container fleet scopes update projects/THIRD_SCOPE_PROJECT_ID/locations/global/scopes/THIRD_SCOPE_NAME \
    --upstream-scope=projects/SECOND_SCOPE_PROJECT/locations/global/scopes/SECOND_SCOPE_NAME \
    --default-upgrade-soaking=SOAK_TIME \
    --project=THIRD_SCOPE_PROJECT_ID

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

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 détails fournis, consultez la section Informations sur l'état d'une séquence de déploiement.

Pour exécuter ces commandes, assurez-vous de disposer des autorisations requises pour chaque projet hôte du parc. Par exemple, si la séquence comporte des champs d'application multiprojets dans différents parcs, vous devez disposer 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.

Parcs

Vérifiez l'état d'une séquence de déploiement basée sur un parc :

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

Remplacez FLEET_PROJECT_ID par l'ID du projet hôte pour n'importe quel parc de la séquence.

Consultez la documentation de référence sur gcloud container fleet clusterupgrade describe pour obtenir la liste complète des options.

Équipes

Vérifiez l'état d'une séquence de déploiement basée sur une équipe :

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

Remplacez SCOPE_NAME par le nom de n'importe quel niveau d'accès d'équipe dans la séquence de déploiement, et SCOPE_PROJECT_ID par l'ID de projet de ce niveau d'accès d'équipe.

Consultez la documentation de référence sur gcloud alpha container fleet scopes describe pour obtenir la liste complète des options.

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 cluster au sein de ce groupe.

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

État Pour un cluster Pour un groupe
INÉLIGIBLE Ce cluster n'est pas éligible pour cette mise à niveau. Un ou plusieurs clusters de ce groupe ne sont pas éligibles pour cette mise à niveau.
EN ATTENTE La mise à niveau n'a pas démarré ou elle est en cours pour le cluster. La mise à niveau n'a démarré sur aucun des clusters du groupe.
IN_PROGRESS (EN_COURS) N/A La mise à niveau a commencé sur au moins un cluster, mais n'est pas terminée sur tous les clusters.
STABILISATION La mise à niveau a été terminée sur le cluster et n'est pas encore stabilisée. La mise à niveau a été terminée sur tous les clusters et n'est pas encore stabilisée.
FORCED_SOAKING La mise à niveau a pris plus de temps (30 jours). Nous l'avons donc forcée à entrer dans la phase de stabilisation. La mise à niveau peut continuer dans le cluster. La mise à niveau a pris plus de temps (30 jours). Nous l'avons donc forcée à entrer dans la phase de stabilisation. La mise à niveau peut continuer dans les clusters.
OK La mise à niveau est traitée comme "terminée", ce qui signifie que la mise à niveau a terminé de se stabiliser sur ce cluster. La mise à niveau est considérée comme "terminée" et prête à être utilisée par le groupe en aval, ce qui signifie que la mise à niveau a terminé de se stabiliser.

Dans le résultat 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, décrites dans les sections suivantes.

Modifier le temps de stabilisation d'un groupe

Vous pouvez modifier le temps de stabilisation par défaut pour un groupe ou modifier le temps de stabilisation lorsque ce groupe est mis à niveau vers une version spécifique.

Mettre à jour le temps de stabilisation par défaut

Pour modifier la durée de stabilisation par défaut d'un groupe, suivez les instructions de la section Créer une séquence de déploiement en omettant les indicateurs permettant de définir le groupe en amont.

Ignorer le temps de stabilisation par défaut

Vous pouvez modifier le temps de stabilisation pour un déploiement de version spécifique pour 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.

Parcs (gcloud)

Exécutez cette commande dans le projet hôte du parc dans lequel vous souhaitez remplacer le temps de stabilisation utilisé pour le déploiement d'une version spécifique.

Modifiez le temps de stabilisation d'un parc :

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

Parcs (Terraform)

Ajoutez le bloc gke_upgrades_overrides suivant à votre configuration Terraform dans le bloc clusterupgrade pour remplacer le temps de stabilisation utilisé pour le déploiement d'une version spécifique :

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

Équipes – gcloud

Exécutez cette commande dans le projet hôte du parc du niveau d'accès d'équipe. Remplacez SCOPE_NAME par le nom du niveau d'accès d'équipe pour lequel vous souhaitez ignorer le temps de stabilisation utilisé pour le déploiement d'une version spécifique.

Modifiez le temps de stabilisation d'un niveau d'accès d'équipe :

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

Modifier l'ordre d'une séquence

Si vous souhaitez modifier l'ordre d'une séquence, suivez les instructions de la section Créer une séquence de déploiement pour mettre à jour les groupes en amont.

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.

Basculer entre les séquences de déploiement basées sur le parc et sur celles basées sur l'équipe

Vous pouvez passer de séquences basées sur un parc à des séquences basées sur une équipe, et inversement. Dans ces instructions, nous partons du principe que vous transférez des séquences organisées comme celles illustrées dans les exemples de diagrammes.

Des parcs vers les équipes

Pour passer d'une séquence de déploiement basée sur un parc à une séquence de déploiement basée sur une équipe procédez comme suit :

  1. Configurez des exclusions de maintenance pour tous les clusters de chacun de vos parcs afin d'éviter les mises à niveau lorsque vous modifiez la configuration.
  2. Assurez-vous d'avoir activé GKE Enterprise dans vos projets hôtes de parc.
  3. Dans chacun de vos parcs, créez un ou plusieurs niveau d'accès d'équipe pour subdiviser le groupe de clusters de ce parc.
  4. Créez une ou plusieurs séquences de déploiement entre les champs d'application correspondants dans chaque parc.
  5. Ajoutez vos clusters à leurs nouveaux niveaux d'accès d'équipe.
  6. Supprimez les exclusions de maintenance que vous avez configurées pour cette modification.

Des équipes vers les parcs

Pour passer d'une séquence de déploiement basée sur un niveau d'accès d'équipe à une séquence de déploiement basée sur un parc, procédez comme suit :

  1. Configurez des exclusions de maintenance pour tous les clusters de chacun de vos parcs afin d'éviter les mises à niveau lorsque vous modifiez la configuration.
  2. Créez une séquence de déploiement entre vos parcs.
  3. Supprimez vos clusters des niveaux d'accès d'équipe. Désormais, ces clusters ne sont enregistrés que dans les parcs respectifs de leur niveau d'accès que, à l'étape précédente, vous avez rejoints dans une séquence de déploiement.
  4. Supprimez les niveaux d'accès d'équipe.
  5. Supprimez les exclusions de maintenance que vous avez configurées pour cette modification.

Supprimer une séquence

Pour supprimer une séquence, vous devez supprimer les associations en amont pour les deuxième et troisième groupes (si la séquence de déploiement comporte trois groupes).

Pour les parcs

Exécutez la commande suivante dans le projet hôte de parc des deuxième et troisième parcs dans la séquence de déploiement :

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

Pour les équipes

Exécutez la commande suivante dans le projet hôte de parc des deuxième et troisième niveaux d'accès d'équipe dans la séquence de déploiement :

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

Remplacez SCOPE_NAME par les noms des deuxième et troisième niveaux d'accès d'équipe, respectivement.

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 continuer 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é dans 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.

Corriger 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