Mettre à jour ou migrer un cluster vers un cluster avancé

Ce document explique comment mettre à jour ou migrer un cluster vers un cluster avancé à partir de la version 1.32.

Important : Les clusters non avancés seront automatiquement mis à niveau vers des clusters avancés dans la version 1.33.

Prérequis

• La version de gkectl doit être identique à celle du cluster cible.

  • Si nécessaire, consultez Télécharger gkectl pour obtenir une version compatible de gkectl.

• Diagnostiquez toujours votre cluster avant de le mettre à jour ou de le migrer vers un cluster avancé :

  • Exécutez gkectl diagnose cluster sur vos clusters d'administrateur et d'utilisateur pour vous assurer qu'ils sont opérationnels.
  • Si la commande signale des erreurs ou des avertissements, résolvez-les avant de commencer la mise à jour ou la mise à niveau vers un cluster avancé.

• Assurez-vous que vos clusters n'utilisent que les caractéristiques recommandées.

• Avant de commencer la mise à jour ou la mise à niveau, vérifiez que vos clusters n'utilisent pas de fonctionnalités non compatibles avec les clusters avancés. Si des fonctionnalités non compatibles sont actives, désactivez-les d'abord à l'aide de update.

  • Bien que les clusters d'utilisateur à haute disponibilité (HA) soient requis sur les clusters avancés, vous pouvez toujours mettre à jour ou migrer un cluster d'utilisateur non HA vers un cluster avancé HA en suivant ce guide.

• Vous devez mettre à jour ou à niveau le cluster d'administrateur vers un cluster avancé avant de mettre à jour ou à niveau les clusters d'utilisateur.

• À propos de l'installation de cert-manager : cert-manager est installé automatiquement sur les clusters avancés. Lorsque vous migrez d'un cluster non avancé vers un cluster avancé, le cert-manager intégré remplace automatiquement toutes les versions de cert-manager installées par le client. Avant de mettre à jour ou de migrer vers des clusters avancés, assurez-vous qu'aucune configuration ni fonctionnalité personnalisée critique n'est appliquée à votre cert-manager existant. Pour en savoir plus, consultez Mettre à niveau vers cert-manager fourni avec les clusters avancés.

Mettre à jour ou migrer le cluster d'administrateur vers un cluster avancé

Attention : Si une mise à jour ou une mise à niveau des clusters d'administrateur échoue, assurez-vous de ne pas supprimer le cluster d'amorçage externe de la station de travail. Le cluster bootstrap contient tous les états requis pour reprendre la mise à jour ou la mise à niveau. Si vous devez relancer gkectl update admin ou gkectl upgrade admin après un échec, vous devez ajouter l'indicateur --reuse-bootstrap-cluster (ou -r). Si vous n'utilisez pas cet indicateur, vous risquez de perdre des données critiques.

Mettre à jour

Important : Assurez-vous que la version de votre cluster est au moins la version 1.32.0.

1. Diagnostiquez votre cluster pour vous assurer qu'il est en bon état :

   gkectl diagnose cluster \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

   • Si la commande signale des erreurs ou des avertissements, consultez Diagnostiquer les problèmes de cluster et résolvez-les avant de continuer.

2. Préparez-vous pour le cluster avancé :

   gkectl prepare \
       --bundle-path BUNDLE_PATH \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --advanced-cluster
   

   Remplacez les éléments suivants :

   • BUNDLE_PATH : chemin d'accès au fichier de bundle. Ce fichier se trouve sur votre poste de travail administrateur, dans /var/lib/gke/bundles/. Exemple :

     /var/lib/gke/bundles/gke-onprem-vsphere-1.32.0-gke.1085-full.tgz
     

   • ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur

3. Définissez enableAdvancedCluster sur true dans votre fichier de configuration de cluster d'administrateur.

4. Mettez à jour le cluster d'administrateur vers le cluster avancé :

   gkectl update admin \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --config ADMIN_CLUSTER_CONFIG
   

   Remplacez les éléments suivants :

   • ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
   • ADMIN_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'administrateur

   La commande recréera tous les nœuds du cluster d'administrateur.

Mettre à niveau

Attention : Si votre cluster utilise cos ou cos_cgv2 comme type d'image d'OS du plan de contrôle ou type d'image d'OS du pool de nœuds, assurez-vous que la version de votre cluster est au moins 1.32.0 avant de procéder à la mise à niveau. Sinon, assurez-vous que la version de votre cluster est au moins 1.31.100.

1. Mettez à niveau votre poste de travail administrateur si nécessaire.

2. Diagnostiquez votre cluster pour vous assurer qu'il est en bon état :

   gkectl diagnose cluster \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

   • Si la commande signale des erreurs ou des avertissements, consultez Diagnostiquer les problèmes de cluster et résolvez-les avant de continuer.

3. Préparez-vous pour le cluster avancé :

   gkectl prepare \
       --bundle-path BUNDLE_PATH \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --advanced-cluster
   

   Remplacez les éléments suivants :

   • BUNDLE_PATH : chemin d'accès au fichier de bundle. Ce fichier se trouve sur votre poste de travail administrateur, dans /var/lib/gke/bundles/. Exemple :

     /var/lib/gke/bundles/gke-onprem-vsphere-1.32.0-gke.1085-full.tgz
     

   • ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur

4. Définissez enableAdvancedCluster sur true dans votre fichier de configuration du cluster d'administrateur.

5. Assurez-vous que le champ bundlepath du fichier de configuration du cluster d'administrateur correspond au chemin du bundle vers lequel vous souhaitez effectuer la mise à niveau.

6. Mettez à niveau le cluster d'administrateur vers le cluster avancé :

   gkectl upgrade admin \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --config ADMIN_CLUSTER_CONFIG
   

   Remplacez les éléments suivants :

   • ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
   • ADMIN_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'administrateur

   La commande recréera tous les nœuds du cluster d'administrateur. Avec la stratégie de déploiement "Recréer", les nœuds sont mis à niveau un par un. Lors de la mise à niveau du nœud, la VM est supprimée, puis recréée avec la nouvelle version.

Une fois le cluster d'administrateur mis à jour ou migré vers un cluster avancé :

• Vos clusters d'utilisateur non avancés existants continuent de fonctionner normalement.

• Vous ne pouvez créer que des clusters d'utilisateur avancés gérés par le cluster d'administrateur avancé.

Nous vous recommandons de mettre à niveau tous les clusters d'utilisateur vers des clusters avancés peu de temps après pour maintenir un environnement cohérent et complet.

Mettre à jour ou migrer le cluster d'utilisateur vers un cluster avancé

Important : Assurez-vous que le cluster d'administrateur a déjà été mis à jour ou migré vers le cluster avancé.

Mettre à jour

Important : Assurez-vous que la version de votre cluster est au moins la version 1.32.0.

1. Diagnostiquez votre cluster pour vous assurer qu'il est en bon état :

   gkectl diagnose cluster \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --cluster-name USER_CLUSTER_NAME
   

   • Si la commande signale des erreurs ou des avertissements, consultez Diagnostiquer les problèmes de cluster et résolvez-les avant de continuer.

2. Si le plan de contrôle de votre cluster d'utilisateur n'est pas disponibilité élevée :

   Attention : En raison d'un problème connu avec le champ masterNode.replicas, pour mettre à jour un cluster d'utilisateur non HA de version 1.32 ou 1.33 vers un cluster avancé HA, votre cluster doit être de version supérieure à 1.32.600 ou 1.33.100, respectivement.

   1. Remplacer masterNode.replicas par 3.

   2. Ajoutez les adresses IP statiques des nœuds du plan de contrôle du cluster d'utilisateur à la section network.controlPlaneIPBlock.ips.

3. Préparez-vous pour le cluster avancé :

   gkectl prepare \
       --bundle-path BUNDLE_PATH \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --advanced-cluster
   

   Remplacez les éléments suivants :

   • BUNDLE_PATH : chemin d'accès au fichier de bundle. Ce fichier se trouve sur votre poste de travail administrateur, dans /var/lib/gke/bundles/. Exemple :

     /var/lib/gke/bundles/gke-onprem-vsphere-1.32.0-gke.1085-full.tgz
     

   • ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur

4. Définissez enableAdvancedCluster sur true dans votre fichier de configuration de cluster d'utilisateur.

5. Mettez à jour le cluster d'utilisateur vers le cluster avancé :

   gkectl update cluster \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --config USER_CLUSTER_CONFIG
   

   Remplacez les éléments suivants :

   • ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
   • USER_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'utilisateur

   La commande recréera tous les nœuds du cluster d'utilisateur. Avec la stratégie de déploiement "Recreate", les nœuds sont mis à jour un par un. Lors de la mise à jour du nœud, la VM est supprimée, puis recréée avec la nouvelle configuration.

Mettre à niveau

Attention : Si votre cluster utilise cos ou cos_cgv2 comme type d'image d'OS du plan de contrôle ou type d'image d'OS du pool de nœuds, assurez-vous que la version de votre cluster est au moins 1.32.0 avant de procéder à la mise à niveau. Sinon, assurez-vous que la version de votre cluster est au moins 1.31.100.

1. Diagnostiquez votre cluster pour vous assurer qu'il est en bon état :

   gkectl diagnose cluster \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --cluster-name USER_CLUSTER_NAME
   

   • Si la commande signale des erreurs ou des avertissements, consultez Diagnostiquer les problèmes de cluster et résolvez-les avant de continuer.

2. Si le plan de contrôle de votre cluster d'utilisateur n'est pas disponibilité élevée :

   1. Remplacer masterNode.replicas par 3.

   2. Ajoutez les adresses IP statiques des nœuds du plan de contrôle du cluster d'utilisateur à la section network.controlPlaneIPBlock.ips.

3. Préparez-vous pour le cluster avancé :

   gkectl prepare \
       --bundle-path BUNDLE_PATH \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --advanced-cluster
   

   Remplacez les éléments suivants :

   • BUNDLE_PATH : chemin d'accès au fichier de bundle. Ce fichier se trouve sur votre poste de travail administrateur, dans /var/lib/gke/bundles/. Exemple :

     /var/lib/gke/bundles/gke-onprem-vsphere-1.32.0-gke.1085-full.tgz
     

   • ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur

4. Définissez enableAdvancedCluster sur true dans votre fichier de configuration de cluster d'utilisateur.

5. Assurez-vous que le champ gkeOnPremVersion du fichier de configuration du cluster d'utilisateur correspond à la version cible de votre mise à niveau.

6. Mettez à niveau le cluster d'utilisateur vers le cluster avancé :

   gkectl upgrade cluster \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --config USER_CLUSTER_CONFIG
   

   Remplacez les éléments suivants :

   • ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
   • USER_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'utilisateur

   La commande recrée tous les nœuds du cluster d'utilisateur.

cert-manager fourni avec les clusters avancés

cert-manager est un composant obligatoire géré par le système dans les clusters avancés.

Si vous utilisez cert-manager sans clusters avancés, vérifiez les points suivants avant de passer aux clusters avancés :

• Votre fichier cert-manager ne contient aucune configuration personnalisée ni aucun indicateur de fonctionnalité.
• Votre version de cert-manager est identique à la version groupée ou antérieure d'une version.

Compatibilité d'Apigee hybrid

Le cert-manager groupé est entièrement compatible avec les charges de travail Apigee hybrid. Lorsque vous passez à un cluster avancé, le programme d'installation peut vous avertir que l'installation cert-manager existante sera remplacée. Ce comportement est normal et le système le gère automatiquement.

Pour faciliter la transition de vos charges de travail Apigee :

• Ne désinstallez pas manuellement votre cert-manager existant avant la mise à niveau.
• Rétablir les personnalisations : si vous gérez cert-manager à l'aide de GitOps ou si vous avez appliqué des configurations personnalisées au déploiement cert-manager, vous devez rétablir ces personnalisations ou suspendre la synchronisation avant la mise à niveau pour éviter les écarts de configuration et les éventuelles pauses de mise à niveau.

Fonctionnalités et limites

Voici ce que vous pouvez faire avec le cert-manager fourni :

• Créer et modifier des ressources Issuer et ClusterIssuer
• Créez et modifiez des ressources de certificat qui font référence à des émetteurs et à des types d'émetteurs standards.
• Créez et modifiez les ressources Kubernetes standards utilisées par cert-manager.
• Créez des secrets Kubernetes contenant des clés API et référencez-les dans vos émetteurs.
• Configurez vos émetteurs pour qu'ils utilisent des résolveurs HTTP-01 ou DNS-01 spécifiques.

Vous ne pouvez pas personnaliser les éléments suivants dans cert-manager groupé :

• Définissez les valeurs deployment ou helm.
• Ajoutez des arguments ou des options de ligne de commande au binaire cert-manager.
• Modifiez les limites de ressources ou les sélecteurs de nœuds pour les pods cert-manager.
• Modifier la logique d'installation du logiciel cert-manager.
• Activez les fonctionnalités expérimentales.
• Forcer les pods du plan de contrôle cert-manager à s'exécuter sur des nœuds d'infrastructure spécifiques.

Si vous avez des contraintes spécifiques qui vous empêchent d'utiliser le cert-manager fourni, contactez l'assistanceGoogle Cloud pour obtenir de l'aide concernant les options de configuration avancées.

Versions groupées

Le tableau suivant répertorie les versions cert-manager groupées pour chaque version de Google Distributed Cloud (logiciel uniquement) pour VMware.

Google Distributed Cloud (logiciel uniquement) pour VMware	Version groupée de cert-manager
1,32	1.17
1.33	1.18
1,34	1.19

Principales différences après le passage aux clusters avancés

La mise à niveau ou la mise à jour de votre cluster vers un cluster avancé introduit plusieurs différences clés par rapport aux clusters standards. Voici les principales modifications apportées aux clusters avancés :

• Emplacement des ressources : les ressources de cluster et de machine ne se trouvent plus dans les clusters d'utilisateur. Ces ressources se trouvent exclusivement dans le cluster d'administrateur.

• NodeExternalIP : NodeExternalIP n'est pas défini sur les nœuds.

• Installation de cert-manager : cert-manager est automatiquement installé sur les clusters avancés. Si vous avez installé cert-manager dans votre cluster, la mise à jour ou la mise à niveau vers un cluster avancé l'écrasent avec la version avancée du cluster.

Pour obtenir une présentation complète des différences entre les fonctionnalités, consultez le tableau comparatif des fonctionnalités.