Présentation de la mise à jour

La planification d'une mise à niveau de cluster pour Google Distributed Cloud (logiciel uniquement) pour VMware vous aide à déterminer l'ordre de mise à niveau requis, à choisir des outils de gestion compatibles et à minimiser les perturbations des charges de travail dans un environnement multicluster. Pour obtenir une checklist de préparation avant la mise à niveau, consultez Bonnes pratiques de mise à niveau.

Impact des versions, de l'ordre et des outils sur les mises à niveau

L'ordre dans lequel vous mettez à niveau les clusters, les outils que vous utilisez et les vérifications que vous devez effectuer varient considérablement en fonction des éléments suivants :

  • La version de départ
  • La version vers laquelle vous effectuez la mise à niveau
  • Si vous effectuez une mise à niveau à partir d'un cluster avancé ou non avancé
  • Si vous passez à un cluster avancé ou non avancé
  • Si Controlplane V2 est activé sur le cluster d'utilisateur

Selon la version de départ, l'ordre dans lequel vous mettez à niveau les clusters, les outils que vous utilisez pour la mise à jour, les versions des clusters et ce que vous pouvez et ne pouvez pas faire varient considérablement.

Vérifier si un cluster est avancé ou non avancé

Pour vérifier si vos clusters sont avancés ou non, identifiez la version que vous utilisez :

  • Si vos clusters utilisent la version 1.30 ou une version antérieure, il s'agit de clusters non avancés.
  • Si vos clusters utilisent la version 1.33 et que vous n'avez pas explicitement désactivé les clusters avancés, il s'agit de clusters avancés.
  • Si vos clusters utilisent la version 1.34 ou une version ultérieure, il s'agit de clusters avancés.

Si vos clusters utilisent les versions 1.31 et 1.32, vérifiez si un cluster est avancé ou non en vérifiant les ressources personnalisées du cluster avec kubectl :

  1. Dans le fichier kubeconfig de votre cluster d'administrateur, vérifiez le champ de spécification enableAdvancedCluster du cluster d'administrateur :

    kubectl get onpremadminclusters -A \
    -o custom-columns=NAME:.metadata.name,VERSION:.spec.gkeOnPremVersion,ADVANCED:.spec.enableAdvancedCluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    Remplacez ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès du fichier kubeconfig de votre cluster d'administrateur.

  2. Dans le fichier kubeconfig de votre cluster d'administrateur, vérifiez le champ de spécification enableAdvancedCluster pour les clusters d'utilisateur :

    kubectl get onpremuserclusters -A \
    -o custom-columns=NAME:.metadata.name,VERSION:.spec.gkeOnPremVersion,ADVANCED:.spec.enableAdvancedCluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Lorsque les clusters avancés sont activés, le résultat ressemble à ce qui suit :

NAME              VERSION           ADVANCED
gke-admin-abc12   1.32.0-gke.1085   true

Si ADVANCED est défini sur true, il s'agit d'un cluster avancé. Pour la version 1.32 ou une version antérieure, ADVANCED peut s'afficher sous la forme <none>.

Processus de mise à niveau général

Les sections suivantes décrivent le processus de mise à niveau global lors de la mise à niveau des clusters, en fonction du type de cluster que vous mettez à niveau et vers lequel vous effectuez la mise à niveau.

Avant de commencer une mise à niveau, consultez les informations détaillées sur l'impact des versions sur les mises à niveau. Consultez Règles de mise à niveau des versions pour obtenir une liste détaillée des dépendances par version, ainsi que des informations sur l'omission de versions et les règles d'écarts de version.

Clusters avancés et non avancés

Il existe deux types de clusters : avancés et non avancés. Tous les clusters créés dans les versions 1.33 ou ultérieures sont des clusters avancés. Les clusters avancés utilisent des architectures améliorées qui offrent plus de flexibilité et d'évolutivité.

Une fois que vous avez mis à niveau vos clusters vers des clusters avancés, vous utilisez toujours des clusters avancés et le processus de mise à niveau des clusters avancés. Le fait qu'un cluster soit avancé ou non n'a d'importance que lorsque vous effectuez une mise à niveau à partir d'une version antérieure à la version 1.33.

Les clusters avancés utilisent une architecture Google Distributed Cloud consolidée en utilisant Google Distributed Cloud (logiciel uniquement) pour Bare Metal comme framework sous-jacent pour Google Distributed Cloud (logiciel uniquement) pour VMware. Vous pouvez voir des références à "bare metal" dans les libellés de nœuds, les ressources d'API et les tags système.

La fonctionnalité de clusters avancés implémente une architecture de cluster qui aligne mieux Google Distributed Cloud (logiciel uniquement) pour VMware avec le reste des produits Google Distributed Cloud. Un cluster pour lequel les clusters avancés sont activés dispose d'une plate-forme partagée avec d'autres clusters Google Distributed Cloud. Cette plate-forme partagée utilise les mêmes contrôleurs et agents, ce qui augmente la fiabilité et peut aider Google à fournir une meilleure assistance. Les performances des opérations de cluster sont également améliorées lorsque les clusters avancés sont activés.

La nouvelle architecture offre une expérience et une mise en œuvre cohérentes avec toutes les autres offres Google Distributed Cloud. Pour en savoir plus sur les fonctionnalités disponibles pour les clusters avancés par rapport aux clusters non avancés, consultez Fonctionnalités compatibles avec les clusters avancés.

Mettre à niveau des clusters avancés vers des clusters avancés (versions actuelles, à partir de la version 1.31)

Dans la version 1.32 et les versions ultérieures, lorsque vous passez d'un cluster avancé à un autre, vous pouvez effectuer des mises à niveau de version de correctif et des mises à niveau de version mineure séquentielles. Dans la version 1.31 Preview, vous ne pouvez effectuer que des mises à niveau de version de correctif dans la version 1.31.

Pour effectuer cette mise à niveau, vous pouvez utiliser la CLI gkectl, la Google Cloud CLI, la console Google Cloud ou Terraform (selon la version).

Pour passer d'un cluster avancé à un cluster avancé, vous devez suivre cet ordre :

  1. Mettez à niveau le poste de travail administrateur, le cas échéant.
  2. Utilisez gkectl diagnose cluster pour vérifier que votre cluster d'administrateur est opérationnel. Résolvez les problèmes.
  3. Mettez à niveau le cluster d'administrateur.
  4. Utilisez gkectl diagnose cluster pour vérifier que la mise à niveau a réussi et que vos clusters d'utilisateur sont opérationnels. Résolvez les problèmes.
  5. Mettez à niveau les clusters d'utilisateur, un par un. Vous pouvez mettre à niveau le plan de contrôle et les pools de nœuds du cluster d'utilisateur ensemble ou séparément. Pour en savoir plus, consultez Mettre à niveau les pools de nœuds.
  6. Vérifiez que la mise à niveau a réussi à l'aide de gkectl diagnose cluster.

Lorsque tous les pools de nœuds d'un cluster d'utilisateur sont à la même version que le plan de contrôle du cluster d'utilisateur, le cluster d'utilisateur est mis à niveau et la mise à niveau est terminée.

Le plan de contrôle du cluster d'utilisateur s'exécute sur le cluster d'utilisateur lui-même et est mis à niveau lors de la mise à niveau du cluster d'utilisateur. Les nœuds du plan de contrôle du cluster d'administrateur sont mis à niveau lors de la mise à niveau du cluster d'administrateur.

Pour en savoir plus sur le diagnostic des clusters à l'aide de gkectl diagnose cluster, consultez Diagnostiquer les clusters.

Pour savoir comment effectuer des mises à niveau de clusters avancés vers des clusters avancés, consultez Mettre à niveau un cluster.

Passer de clusters non avancés à des clusters avancés

Les mises à niveau d'un cluster non avancé vers un cluster avancé ne sont possibles que pour les versions 1.31, 1.32, 1.33 et 1.34. Pour en savoir plus sur la mise à niveau de clusters non avancés vers des clusters avancés dans ces versions, consultez Règles de mise à niveau de version.

Pour passer d'un cluster non avancé à un cluster avancé, vous devez utiliser gkectl avec la même version que la version cible (par exemple, si vous passez à la version 1.32.0, vous devez utiliser gkectl version 1.32.0) et suivre cet ordre :

  1. Mettez à niveau le poste de travail administrateur et les artefacts.
  2. Utilisez gkectl diagnose cluster pour vérifier que votre cluster d'administrateur est opérationnel. Résolvez les problèmes.
  3. Mettez à niveau le cluster d'administrateur.
  4. Utilisez gkectl diagnose cluster pour vérifier que la mise à niveau a réussi et que vos clusters d'utilisateur sont opérationnels. Résolvez les problèmes.
  5. Mettez à niveau le cluster d'utilisateur.
  6. Vérifiez que la mise à niveau a réussi à l'aide de gkectl diagnose cluster.

Pour en savoir plus sur le diagnostic des clusters à l'aide de gkectl diagnose cluster, consultez Diagnostiquer les clusters.

Pour en savoir plus sur la mise à niveau d'un cluster non avancé vers un cluster avancé, consultez Mettre à jour ou mettre à niveau un cluster non avancé vers un cluster avancé.

Mise à niveau d'un cluster non avancé vers un cluster non avancé

Vous pouvez passer d'un cluster non avancé à un autre cluster non avancé pour la version 1.33 et les versions antérieures. Pour en savoir plus sur les versions qui permettent de passer d'un cluster non avancé à un autre cluster non avancé, consultez Règles de version pour les mises à niveau.

L'ordre dans lequel vous mettez à niveau les clusters non avancés dépend de la version cible :

  • Pour les versions cibles 1.31, 1.32 et 1.33, vous devez mettre à niveau le cluster d'administrateur avant de mettre à niveau les clusters d'utilisateur.
  • Pour les versions cibles 1.30 et antérieures, vous devez mettre à niveau tous les clusters d'utilisateur avant de mettre à niveau le cluster d'administrateur.

Passer à la version 1.31, 1.32 ou 1.33

Pour passer à la version 1.31, 1.32 ou 1.33 tout en conservant vos clusters non avancés, vous devez suivre cet ordre :

  1. Mettez à niveau le poste de travail administrateur et préparez les artefacts du bundle.
  2. Utilisez gkectl diagnose cluster pour vérifier que votre cluster d'administrateur est opérationnel. Résolvez les problèmes.
  3. Mettez à niveau le cluster d'administrateur.
  4. Utilisez gkectl diagnose cluster pour vérifier que la mise à niveau a réussi et que vos clusters d'utilisateur sont opérationnels. Résolvez les problèmes.
  5. Mettez à niveau les clusters d'utilisateur, un par un.
  6. Vérifiez que la mise à niveau a réussi à l'aide de gkectl diagnose cluster.

Mettre à niveau vers la version 1.30 ou une version antérieure

Pour passer à la version 1.30 ou antérieure, vous devez suivre cet ordre :

  1. Mettez à niveau le poste de travail administrateur et préparez les artefacts du bundle.
  2. Utilisez gkectl diagnose cluster pour vérifier que vos clusters d'utilisateur sont opérationnels. Résolvez les problèmes.
  3. Mettez à niveau tous les clusters d'utilisateur, un par un.
  4. Utilisez gkectl diagnose cluster pour vérifier que la mise à niveau a réussi et que votre cluster d'administrateur est opérationnel. Résolvez les problèmes.
  5. Mettez à niveau le cluster d'administrateur.
  6. Vérifiez que la mise à niveau a réussi à l'aide de gkectl diagnose cluster.

Pour en savoir plus sur le diagnostic des clusters à l'aide de gkectl diagnose cluster, consultez Diagnostiquer les clusters.

Pour en savoir plus sur la mise à niveau d'un cluster non avancé vers un cluster non avancé, consultez Mettre à niveau et gérer des clusters non avancés.

Mise à niveau des clusters

Vous devez toujours mettre à niveau les clusters d'administrateur un par un.

Lorsque vous mettez à niveau des clusters d'utilisateur, vous pouvez mettre à niveau l'ensemble du cluster d'utilisateur (le plan de contrôle et tous les pools de nœuds du cluster en même temps), ou mettre à niveau le plan de contrôle du cluster d'utilisateur et laisser les pools de nœuds à la version actuelle. L'approche que vous adoptez dépend de plusieurs facteurs, tels que :

  • Environnement (production ou hors production) dans lequel se trouve le cluster.
  • La durée de votre intervalle de maintenance.
  • Version du cluster d'utilisateur.

Par exemple, dans un environnement de développement, vous pouvez choisir de simplifier le processus et de mettre à niveau à la fois le plan de contrôle du cluster d'utilisateur et tous les pools de nœuds. Toutefois, dans un environnement de production avec un court intervalle de maintenance, vous pouvez choisir de ne mettre à niveau que le plan de contrôle, car cela prend moins de temps. Avec les plans de contrôle haute disponibilité, la mise à niveau du plan de contrôle ne devrait pas perturber les charges de travail des utilisateurs.

Choisir un outil pour mettre à niveau les clusters

L'outil que vous utilisez dépend de la manière dont vous prévoyez d'effectuer la mise à niveau et de ce que vous souhaitez mettre à niveau.

Pour les clusters d'administrateur, vous devez utiliser gkectl pour effectuer la mise à niveau.

Pour les clusters d'utilisateur, vous pouvez utiliser l'un des outils suivants pour mettre à niveau les clusters :

  • L'outil de ligne de commande gkectl (requis pour les mises à niveau de clusters non avancés vers des clusters avancés)
  • Terraform, si vous avez créé le cluster d'utilisateur à l'aide de Terraform
  • ConsoleGoogle Cloud
  • Google Cloud CLI

Le tableau suivant indique les outils compatibles avec chaque cas d'utilisation.

Cas d'utilisation de la mise à niveau gkectl gcloud CLI Console Terraform Remarques et restrictions
Mettre à niveau les clusters d'administrateur (n'importe quel chemin d'accès) Oui Non Non Non Les clusters d'administrateur nécessitent toujours gkectl.
Mettre à niveau des clusters non avancés vers des clusters avancés (conversion) Oui Non Non Non La version de gkectl doit correspondre à la version cible. Aucun décalage de version n'est autorisé entre le plan de contrôle et les pools de nœuds.
Mettre à niveau des clusters non avancés vers des clusters non avancés (anciens) Oui Non Non Non Disponible uniquement dans la version 1.33 et les versions antérieures (chemin d'accès de désactivation) ; les clients API ne sont pas compatibles.
Mettre à niveau des clusters d'utilisateur : d'Advanced vers Advanced Oui Oui Oui Oui1 Les règles standards de décalage de version s'appliquent.
Mettre à niveau l'ensemble du cluster d'utilisateur (plan de contrôle et pools de nœuds) Oui Oui Oui Oui1 Compatible avec tous les outils pour les clusters d'utilisateur avancés.
Mettre à niveau le plan de contrôle du cluster d'utilisateur séparément (CP uniquement) Oui Oui Non Oui1 La console ne permet pas de mettre à niveau uniquement le plan de contrôle.
Mettre à niveau de manière sélective les pools de nœuds après la mise à niveau du plan de contrôle Oui Oui Non Oui1 La console ne permet pas de mettre à niveau des pools de nœuds individuels.
Mettre à niveau le plan de contrôle et un ou plusieurs pools de nœuds en même temps Oui Non Non Non Seul gkectl accepte les mises à niveau simultanées partielles de la version du plan de contrôle et du pool de nœuds.

1 Exigence Terraform : vous ne pouvez utiliser Terraform pour mettre à niveau un cluster d'utilisateur que si celui-ci a été créé et géré à l'origine à l'aide de Terraform.

Pour obtenir des informations sur les clusters que vous avez créés avec gkectl à l'aide de la console ou de gcloud CLI, enregistrez le cluster dans l'API GKE On-Prem.

Étapes suivantes

Consultez les règles de mise à niveau des versions pour comprendre l'impact des versions sur les mises à niveau et pour trouver les règles de version pour la version dont vous disposez et celle vers laquelle vous effectuez la mise à niveau.

Consultez les bonnes pratiques de mise à niveau et créez un plan de mise à niveau de vos clusters.