Mettre à niveau un cluster

Ce document explique comment mettre à niveau des clusters dans Google Distributed Cloud (logiciel uniquement) pour VMware. Ce document explique comment mettre à niveau votre poste de travail administrateur, vos clusters d'utilisateurs et vos clusters d'administrateur. La procédure de mise à niveau d'un cluster d'utilisateur montre comment mettre à niveau le plan de contrôle et tous les pools de nœuds. Si vous souhaitez mettre à niveau le plan de contrôle et les pools de nœuds du cluster d'utilisateur séparément, consultez la section Mettre à niveau les pools de nœuds.

Cette page s'adresse aux administrateurs et opérateurs informatiques qui gèrent le cycle de vie de l'infrastructure technologique sous-jacente. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Avant de continuer, nous vous recommandons de consulter la documentation suivante :

• Présentation de la mise à niveau
  Ce document décrit, entre autres, l'écart de version compatible et les règles de version pour les mises à niveau, qui ont changé pour la version 1.28 et les versions ultérieures.

• Bonnes pratiques de mise à niveau
  Ce document fournit des checklists et des bonnes pratiques pour mettre à niveau des clusters.

Différences entre les clusters avancés

Lorsque les clusters avancés sont activés, il existe des différences avec les mises à niveau, en particulier dans la version preview des clusters avancés de la version 1.31. Pour voir les différences de mise à niveau, recherchez le mot advanced dans ce document. Pour obtenir un tableau de toutes les différences, consultez la section Différences lors de l'exécution de clusters avancés.

Conditions requises

Cette section fournit des informations sur les exigences liées aux versions et sur les exigences concernant l'utilisation des clients de l'API GKE On-Prem (la console Google Cloud , la Google Cloud CLI et Terraform) pour les mises à niveau.

Règles de version

Les règles de mise à niveau dépendent de la version mineure du cluster.

• Pour les versions 1.30 et antérieures, la version mineure du cluster d'utilisateur doit être supérieure ou égale à celle du cluster d'administrateur. La version du correctif n'a pas d'importance. Par exemple, si un cluster d'utilisateur est en version 1.30.1, le cluster d'administrateur peut être mis à niveau vers une version de correctif ultérieure, telle que 1.30.3.

• Pour les versions 1.31 et ultérieures, la version du cluster d'administrateur, y compris la version du correctif, doit être supérieure ou égale à celle du cluster d'utilisateur. Par exemple, si un cluster d'administrateur est en version 1.31.1, la version la plus récente à laquelle le cluster d'utilisateur peut être mis à niveau est la version 1.31.1.

Lorsque vous souhaitez mettre à niveau vos clusters vers la version 1.31, vous devez d'abord passer tous vos clusters à la version 1.30. Une fois tous les clusters à la version 1.30, mettez à niveau le cluster d'administrateur vers la version 1.31. Vous pouvez ensuite mettre à niveau les clusters d'utilisateur vers la même version de correctif 1.31 que le cluster d'administrateur.

Règles de version pour gkectl

La version de gkectl que vous pouvez utiliser pour la mise à niveau dépend de la version du cluster cible (c'est-à-dire la version du cluster vers laquelle vous effectuez la mise à niveau). En règle générale, vous utilisez la même version d'gkectl que la version cible du cluster. Les règles suivantes sont appliquées lors de la mise à niveau:

• La version gkectl ne peut pas être une version mineure inférieure à la version mineure cible du cluster. Par exemple, si vous mettez à niveau un cluster 1.29 vers la version 1.30, vous ne pouvez pas utiliser gkectl 1.29, car cette version est inférieure à la version cible du cluster. Les versions de correctif n'ont pas d'importance. Par exemple, vous pouvez utiliser la version gkectl 1.29.0-gke.1456 pour passer à une version de correctif supérieure, telle que 1.29.1000-gke.94.

• La version gkectl ne peut pas être supérieure de plus de deux versions mineures à la version actuelle du cluster. Par exemple, si vous mettez à niveau un cluster de version 1.28 vers la version 1.29, la version gkectl peut être 1.29 ou 1.30. Toutefois, vous ne pouvez pas utiliser la version 1.31 de gkectl, car elle est trois versions mineures plus récente que la version du cluster.

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

Examiner les règles de pare-feu

Dans les versions 1.29 et ultérieures, les vérifications préliminaires côté serveur sont activées par défaut. Les vérifications préliminaires côté serveur nécessitent des règles de pare-feu supplémentaires. Dans la section Règles de pare-feu pour les clusters d'administrateur, recherchez "Vérifications préaliminaires" et assurez-vous que toutes les règles de pare-feu requises sont configurées.

Avec les vérifications préliminaires côté serveur, lorsque vous mettez à niveau un cluster d'utilisateur à l'aide de gkectl, les vérifications préliminaires sont exécutées sur le cluster d'administrateur au lieu d'être exécutées localement sur le poste de travail de l'administrateur. Des vérifications préliminaires côté serveur sont également exécutées sur le cluster d'administration lorsque vous utilisez la Google Cloud console, la Google Cloud CLI ou Terraform pour mettre à niveau un cluster.

Lorsque vous mettez à niveau un cluster d'administration, Google Distributed Cloud déploie un cluster Kubernetes in Docker (kind) pour héberger temporairement les contrôleurs Kubernetes nécessaires à la mise à niveau du cluster d'administration. Ce cluster temporaire est appelé cluster d'amorçage. Des vérifications préliminaires côté serveur sont exécutées sur le cluster d'amorçage lorsque vous mettez à niveau un cluster d'administration.

Activer Dataplane V2

Dataplane V2 doit être activé sur tous les clusters d'utilisateurs à partir de la version 1.31. Avant de mettre à niveau un cluster d'utilisateur vers la version 1.31, procédez comme suit. Si vous avez des questions concernant la suppression temporaire de la spécification NetworkPolicy, contactez l'assistance Google.

Définissez enableDataplaneV2 sur true dans le fichier de configuration de votre cluster d'utilisateur.

Si votre cluster utilise un NetworkPolicy, supprimez temporairement sa spécification du cluster, comme suit:

1. Vérifiez si des NetworkPolicy non système sont appliqués à votre cluster:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy -A -o wide | grep -v kube-system
   

2. Si la sortie de l'étape précédente n'était pas vide, enregistrez chaque spécification NetworkPolicy dans un fichier afin de pouvoir réappliquer la spécification après la mise à niveau du cluster.

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE -o yaml > NETWORK_POLICY_NAME.yaml
   

   Remplacez les éléments suivants :

   • NETWORK_POLICY_NAME: nom de l'NetworkPolicy que vous enregistrez.
   • NETWORK_POLICY_NAMESPACE: espace de noms du NetworkPolicy.

3. Supprimez NetworkPolicy à l'aide de la commande suivante:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE
   

4. Poursuivez la mise à niveau.

5. Une fois la mise à niveau terminée, si vous avez supprimé des spécifications NetworkPolicy autres que système, réappliquez-les à l'aide de la commande suivante:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml
   

Exigences relatives à l'API Google et à IAM

Pour mettre à niveau un cluster vers la version 1.28 ou une version ultérieure, vous devez activer kubernetesmetadata.googleapis.com et attribuer le rôle IAM kubernetesmetadata.publisher au compte de service de surveillance de la journalisation. Ces modifications sont nécessaires pour utiliser Cloud Monitoring.

1. Activer kubernetesmetadata.googleapis.com :

   gcloud services enable --project PROJECT_ID  \
       kubernetesmetadata.googleapis.com
   

   Remplacez PROJECT_ID par l'ID du projet hôte de parc dont le cluster d'utilisateurs fait partie. Il s'agit du projet que vous avez spécifié lors de la création du cluster. Si vous avez créé le cluster à l'aide de gkectl, il s'agit de l'ID de projet dans le champ gkeConnect.projectID du fichier de configuration du cluster.

2. Si votre organisation a configuré une liste d'autorisation qui permet au trafic provenant des API Google et d'autres adresses de transiter par votre serveur proxy, ajoutez kubernetesmetadata.googleapis.com à la liste d'autorisation.

3. Attribuez le rôle kubernetesmetadata.publisher au compte de service de surveillance de la journalisation:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member "serviceAccount:SERVICE_ACCOUNT_EMAIL" \
       --role "roles/kubernetesmetadata.publisher"
   

   Remplacez SERVICE_ACCOUNT_EMAIL par l'adresse e-mail de votre compte de service logging-monitoring.

Exigences IAM pour la mise à niveau des clusters d'utilisateur

Ignorez cette section si vous prévoyez d'utiliser gkectl pour la mise à niveau du cluster d'utilisateur.

Si vous souhaitez utiliser la Google Cloud console, Google Cloud CLI ou Terraform pour mettre à niveau un cluster d'utilisateur et que vous n'êtes pas propriétaire du projet, vous devez être titulaire du rôle roles/gkeonprem.admin de Identity and Access Management sur le Google Cloud projet dans lequel le cluster a été créé. Pour en savoir plus sur les autorisations incluses dans ce rôle, consultez la section Rôles GKE On-Prem dans la documentation IAM.

Pour utiliser la console pour mettre à niveau le cluster, vous devez également disposer des éléments suivants:

• roles/container.viewer. Ce rôle permet aux utilisateurs d'afficher la page "Clusters GKE" et les autres ressources de conteneur dans la console. Pour en savoir plus sur les autorisations incluses dans ce rôle ou pour attribuer un rôle avec des autorisations de lecture/écriture, consultez la section Rôles Kubernetes Engine dans la documentation IAM.

• roles/gkehub.viewer. Ce rôle permet aux utilisateurs d'afficher les clusters dans la console. Pour en savoir plus sur les autorisations incluses dans ce rôle ou pour accorder un rôle avec des autorisations de lecture/écriture, consultez la section Rôles GKE Hub dans la documentation IAM.

Limites des clusters avancés

Notez les restrictions suivantes si les clusters avancés sont activés:

• Vous devez utiliser gkectl pour mettre à niveau des clusters. Les clients de l'API GKE On-Prem (console, gcloud CLI et Terraform) ne sont pas compatibles.

• Seules les mises à niveau synchrones sont acceptées.

Apportez des modifications de configuration avant ou après une mise à niveau

Si vous devez apporter des modifications de configuration à vos clusters, effectuez la mise à jour du cluster avant ou après la mise à niveau. La seule modification apportée à la configuration du cluster pour une mise à niveau doit concerner la version. En fonction de la version et du type du cluster, les autres modifications de configuration sont ignorées de manière silencieuse ou entraînent l'échec de la mise à niveau. Pour en savoir plus, consultez la section Supprimer les modifications non compatibles pour débloquer la mise à niveau.

Vérifier les versions disponibles pour les mises à niveau de cluster

Exécutez la commande suivante pour afficher les versions disponibles pour la mise à niveau :

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG

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

La sortie affiche la version actuelle et les versions disponibles pour la mise à niveau.

Si vous prévoyez d'utiliser la console, gcloud CLI ou Terraform pour la mise à niveau, la version sera disponible dans l'API GKE On-Prem dans toutes les régions Google Cloud environ sept à 14 jours après sa publication. La console ne liste que les versions disponibles pour la mise à niveau du cluster d'utilisateur. Pour mettre à niveau un cluster d'utilisateur à l'aide de gcloud CLI ou de Terraform, vous devez exécuter gcloud container vmware clusters query-version-config afin d'obtenir les versions disponibles pour la mise à niveau.

Mettre à niveau votre poste de travail administrateur.

La façon dont vous mettez à niveau votre poste de travail administrateur dépend de la façon dont vous l'avez créé : gkeadm ou géré par l'utilisateur.

Mettre à niveau le cluster d'administrateur

La procédure de mise à niveau du cluster d'administration varie légèrement selon la version mineure vers laquelle vous effectuez la mise à niveau (version cible):

gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Avant de commencer :

1. Si vous passez à la version 1.13 ou ultérieure, vous devez d'abord enregistrer le cluster d'administrateur en remplissant la section gkeConnect du fichier de configuration du cluster d'administrateur. Exécutez la commande gkectl update cluster (mettre à jour le cluster) avec les modifications apportées au fichier de configuration.

2. Assurez-vous que gkectl et vos clusters sont au niveau de version approprié pour une mise à niveau et que vous avez téléchargé le bundle approprié. L'écart de version entre vos clusters d'administrateur et d'utilisateur dépend de la version de Google Distributed Cloud. Pour vous assurer que vous pouvez mettre à niveau votre cluster d'administrateur, consultez la section Différence de version entre le cluster d'administrateur et le cluster d'utilisateur.

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

   Si vous apportez d'autres modifications aux champs du fichier de configuration du cluster d'administrateur, ces modifications sont ignorées lors de la mise à niveau. Pour que ces modifications prennent effet, vous devez d'abord mettre à niveau le cluster, puis exécuter une commande de mise à jour de cluster avec les modifications apportées au fichier de configuration pour apporter d'autres modifications au cluster.

Procéder à la mise à niveau

Suivez les étapes décrites dans cette section sur votre poste de travail administrateur. Il existe deux variantes de la commande gkectl upgrade admin :

• Asynchrone:
  Avec la variante asynchrone, la commande lance la mise à niveau, puis la termine. Vous n'avez pas besoin de surveiller la sortie de la commande pendant toute la durée de la mise à niveau. Vous pouvez plutôt vérifier régulièrement la progression de la mise à niveau en exécutant gkectl list admin et gkectl describe admin. Pour utiliser la variante asynchrone, incluez l'option --async dans la commande.

  Conditions requises pour la mise à niveau asynchrone:

  • Compatible uniquement avec les clusters d'administrateurs haute disponibilité en version 1.29 ou ultérieure.
  • Controlplane V2 doit être activé sur tous les clusters d'utilisateur.
  • Version 1.31: non compatible avec les clusters avancés.
  • Version 1.32 et ultérieure: disponible sur les clusters avancés.

• Synchrone :
  Avec la variante synchrone, la commande gkectl upgrade admin génère des messages d'état au poste de travail administrateur à mesure que la mise à niveau progresse.

Mettre à niveau un cluster d'utilisateur

Vous pouvez utiliser gkectl, la console, gcloud CLI ou Terraform pour mettre à niveau un cluster d'utilisateur. Pour choisir l'outil à utiliser, consultez la section Choisir un outil pour mettre à niveau les clusters d'utilisateurs.

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

Warning  PodEvictionTooLong  96s (x2 over 4m7s)  onprem-user-cluster-controller
Waiting too long(>10m0.00000003s) for (kube-system/coredns-856d6dbfdf-dl6nz) eviction.

gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE \
    --skip-validation-all

Supprimer le bundle complet

Si vous avez téléchargé un bundle complet et que vous avez exécuté gkectl prepare et mis à niveau le cluster d'administration et tous les clusters d'utilisateurs, vous devez supprimer le bundle complet pour économiser de l'espace disque sur le poste de travail administrateur. Exécutez la commande suivante pour supprimer le bundle complet:

rm /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION-full.tgz

Reprendre une mise à niveau d'un cluster d'administrateur

Si une mise à niveau d'un cluster d'administrateur est interrompue ou échoue, elle peut être réactivée si le point de contrôle du cluster d'administrateur contient l'état requis pour restaurer l'état avant l'interruption.

Avertissement: Ne corrigez pas l'administrateur principal avec gkectl repair admin-master après l'échec d'une tentative de mise à niveau. Cela entraînera une dégradation de l'état du cluster d'administrateur.

Procédez comme suit :

1. Vérifiez si le plan de contrôle administrateur est opérationnel avant de commencer la tentative de mise à niveau initiale. Consultez la page Diagnostiquer les problèmes de cluster. Comme indiqué dans cette rubrique, exécutez la commande gkectl diagnose cluster pour le cluster d'administrateur.

2. Si le plan de contrôle administrateur n'est pas opérationnel avant la tentative de mise à niveau initiale, réparez le plan de contrôle administrateur à l'aide de la commande gkectl repair admin-master.

3. Lorsque vous exécutez à nouveau la commande de mise à niveau après une mise à niveau interrompue ou en échec, utilisez le même groupe et la même version cible que lors de la tentative de mise à niveau précédente.

Lorsque vous exécutez à nouveau la commande de mise à niveau, la mise à niveau réactivée recrée l'état du cluster d'administrateur à partir du point de contrôle et réexécute l'intégralité de la mise à niveau. À partir de la version 1.12.0, si le plan de contrôle d'administrateur n'est pas opérationnel, le processus de mise à niveau sera directement mis à niveau vers la version cible sans tenter de restaurer le cluster d'administrateur dans la version source avant de procéder à la mise à niveau.

La mise à niveau reprend à partir du moment où elle a échoué ou si le point de contrôle du cluster d'administrateur est disponible. Si le point de contrôle n'est pas disponible, la mise à niveau s'appuiera sur le plan de contrôle administrateur. Par conséquent, le plan de contrôle administrateur doit être opérationnel pour poursuivre la mise à niveau. Après une mise à niveau réussie, le point de contrôle est régénéré.

Si gkectl se ferme de manière inattendue lors de la mise à niveau d'un cluster d'administrateur, le cluster de genre n'est pas nettoyé. Avant de relancer la commande de mise à niveau pour reprendre la mise à niveau, supprimez le cluster de genre :

docker stop gkectl-control-plane && docker rm gkectl-control-plane

Après avoir supprimé le cluster de genre, exécutez à nouveau la commande de mise à niveau.

Effectuer un rollback sur un poste de travail administrateur après une mise à niveau

Vous pouvez restaurer la version utilisée avant la mise à niveau sur le poste de travail administrateur.

Lors de la mise à niveau, gkeadm enregistre la version avant sa mise à niveau dans le fichier d'informations de sortie. Lors du rollback, gkeadm utilise la version répertoriée pour télécharger l'ancien fichier.

Pour restaurer la version précédente sur votre poste de travail administrateur, procédez comme suit :

gkeadm rollback admin-workstation --config=AW_CONFIG_FILE

Vous pouvez omettre --config=AW_CONFIG_FILE si le fichier de configuration de votre poste de travail administrateur est le fichier par défaut admin-ws-config.yaml. Sinon, remplacez AW_CONFIG_FILE par le chemin d'accès au fichier de configuration du poste de travail administrateur.

La commande de rollback effectue les étapes suivantes :

1. Télécharge la version de rollback de gkeadm.
2. Sauvegarde le répertoire d'accueil du poste de travail administrateur actuel.
3. Crée un poste de travail administrateur en utilisant la version de rollback de gkeadm.
4. Supprime le poste de travail administrateur d'origine.

Installer le bundle avec une version différente pour la mise à niveau

Si vous mettez à niveau votre poste de travail, un bundle avec une version correspondante est installé ici pour mettre à niveau vos clusters. Si vous souhaitez une autre version, suivez la procédure ci-dessous pour installer un bundle pour TARGET_VERSION, qui correspond à la version vers laquelle vous souhaitez effectuer la mise à niveau.

1. Pour vérifier la version actuelle de gkectl et les versions de cluster, exécutez cette commande. Utilisez l'indicateur --details/-d pour obtenir des informations plus détaillées.

   gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
   

   La sortie fournit des informations sur les versions de votre cluster.

2. En fonction du résultat obtenu, recherchez les problèmes suivants et corrigez-les si nécessaire.

   • Si la version actuelle du cluster d'administrateur est antérieure à une version mineure antérieure à la version TARGET_VERSION, mettez à niveau tous vos clusters de sorte qu'ils soient en version mineure antérieure à la version TARGET_VERSION.

   • Si la version de gkectl est antérieure à la version 1.11 et que vous souhaitez passer à la version 1.12.x, vous devrez effectuer plusieurs mises à niveau. Mettez à niveau une version mineure à la fois jusqu'à la version 1.11.x, puis suivez les instructions de cette rubrique.

   • Si la version de gkectl est antérieure à TARGET_VERSION, mettez à niveau le poste de travail administrateur vers le fichier TARGET_VERSION.

3. Une fois que vous avez déterminé que vos versions de gkectl et de cluster sont adaptées à une mise à niveau, téléchargez le bundle.

   Vérifiez si le fichier tarball du bundle existe déjà sur le poste de travail administrateur.

   stat /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz

   Si le bundle ne se trouve pas sur le poste de travail administrateur, téléchargez-le.

   gcloud storage cp gs://gke-on-prem-release/gke-onprem-bundle/TARGET_VERSION/gke-onprem-vsphere-TARGET_VERSION.tgz /var/lib/gke/bundles/
   

4. Installez le bundle.

   gkectl prepare --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

   Remplacez ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès de votre fichier kubeconfig. Vous pouvez omettre cette option si le fichier se trouve dans votre répertoire actuel sous le nom kubeconfig.

5. Répertoriez les versions de cluster disponibles et assurez-vous que la version cible est incluse dans les versions de cluster d'utilisateur disponibles.

   gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

Vous pouvez maintenant créer un cluster d'utilisateur dans la version cible, ou mettre à niveau un cluster d'utilisateur vers la version cible.

Résoudre les problèmes liés au processus de mise à niveau

Si vous rencontrez un problème après avoir suivi la procédure de mise à niveau recommandée, suivez les recommandations ci-dessous pour le résoudre. Ces suggestions supposent que vous avez commencé avec une configuration en version 1.11.x et que vous suivez le processus de mise à niveau recommandé.

Consultez la page Résoudre les problèmes liés à la création et à la mise à niveau d'un cluster.

Résoudre un problème lié à la mise à niveau d'un cluster d'utilisateur

Supposons que vous rencontriez un problème avec la version de mise à niveau lors de la mise à niveau d'un cluster d'utilisateur. Vous déterminez auprès de l'Assistance Google que le problème sera résolu dans une prochaine version de correctif. Vous pouvez procéder comme suit :

1. Continuez à utiliser la version actuelle pour la production.
2. Testez la version du correctif dans un cluster hors production lorsqu'elle est publiée.
3. Mettez à niveau tous les clusters d'utilisateur de production vers la version de correctif lorsqu'elle vous paraît fiable.
4. Mettez à niveau le cluster d'administrateur vers la version disponible.

Résoudre un problème lié à la mise à niveau d'un cluster d'administrateur

Si vous rencontrez un problème lors de la mise à niveau du cluster d'administrateur, vous devez contacter l'Assistance Google pour résoudre ce problème.

En attendant, le nouveau processus de mise à niveau vous permet tout de même de profiter des nouvelles fonctionnalités de cluster d'utilisateur sans être bloqué par la mise à niveau du cluster d'administrateur, ce qui vous permet de réduire la fréquence de mise à niveau du cluster d'administrateur si vous le souhaitez. Votre processus de mise à niveau peut se présenter comme suit :

1. Mettez à niveau les clusters d'utilisateur en production vers la version 1.12.x.
2. Conservez la version antérieure du cluster d'administrateur et continuez de recevoir des correctifs de sécurité.
3. Testez la mise à niveau du cluster d'administrateur de la version 1.11.x vers la version 1.12.x dans un environnement de test et signalez les éventuels problèmes.
4. Si votre problème est résolu par une version de correctif 1.12.x, vous pouvez choisir de mettre à niveau le cluster d'administrateur de production vers cette version de correctif si vous le souhaitez.

Problèmes connus concernant les versions récentes

Les problèmes connus suivants peuvent affecter les mises à niveau si vous effectuez la mise à niveau à partir de la version 1.7. ou ultérieure.

Consultez également la page Problèmes connus.

La mise à niveau du poste de travail administrateur peut échouer si le disque de données est presque plein.

Si vous mettez à niveau le poste de travail administrateur avec la commande gkectl upgrade admin-workstation, la mise à niveau peut échouer si le disque de données est presque plein car le système tente de sauvegarder localement le poste de travail administrateur actuel lors de la mise à niveau vers un nouveau poste de travail administrateur. Si vous ne parvenez pas à libérer suffisamment d'espace sur le disque de données, exécutez la commande gkectl upgrade admin-workstation avec l'option supplémentaire --backup-to-local=false pour empêcher la sauvegarde locale du poste de travail administrateur actuel.

Perturbation des charges de travail comportant des PodDisruptionBudgets

La mise à niveau de clusters peut entraîner des perturbations ou des temps d'arrêt pour les charges de travail qui utilisent des PodDisruptionBudgets (PDB).

Les nœuds ne parviennent pas à terminer leur processus de mise à niveau

Si des objets PodDisruptionBudget sont configurés pour ne pas autoriser d'autres interruptions, les mises à niveau de nœuds peuvent échouer à passer à la version du plan de contrôle après plusieurs tentatives. Pour éviter cet échec, nous vous recommandons d'effectuer un scaling à la hausse de Deployment ou HorizontalPodAutoscaler afin de permettre au nœud de se drainer tout en respectant la configuration PodDisruptionBudget.

Pour afficher tous les objets PodDisruptionBudget qui n'autorisent aucune interruption, procédez comme suit :

kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

Annexe

À propos des règles VMware DRS activées dans la version 1.1.0-gke.6

Depuis la version 1.1.0-gke.6, Google Distributed Cloud crée automatiquement des règles anti-affinité VMware Distributed Resource Scheduler (DRS) pour les nœuds de votre cluster d'utilisateur, ce qui les répartit sur au moins trois hôtes physiques dans votre centre de données. Depuis la version 1.1.0-gke.6, cette fonctionnalité est automatiquement activée pour les nouveaux clusters et pour les clusters existants.

Avant de procéder à la mise à niveau, assurez-vous que votre environnement vSphere remplit les conditions suivantes :

• La fonctionnalité VMware DRS est activée. VMware DRS nécessite l'édition de licence vSphere Enterprise Plus. Pour en savoir plus sur l'activation de DRS, consultez la page Enabling VMware DRS in a cluster (Activer VMware DRS dans un cluster).

• Le nom d'utilisateur vSphere fourni dans votre fichier de configuration des identifiants dispose de l'autorisation Host.Inventory.EditCluster.

• Au moins trois hôtes physiques sont disponibles.

Si votre environnement vSphere ne remplit pas les conditions précédentes, vous pouvez toujours mettre à niveau un cluster d'utilisateur de la version 1.3.x à la version 1.4.x, mais vous devez désactiver les groupes d'anti-affinité. Pour en savoir plus, consultez ce problème connu dans les notes de version de Google Distributed Cloud.

À propos des temps d'arrêt pendant les mises à niveau

Recréer un fichier d'informations s'il est manquant

Si le fichier d'informations de sortie de votre poste de travail administrateur est manquant, vous devez le recréer pour pouvoir continuer la mise à niveau. Ce fichier a été créé lors de la création initiale de votre poste de travail. Si vous avez depuis effectué une mise à niveau, il a été mis à jour avec de nouvelles informations.

Le fichier d'informations de sortie a le format suivant :

Admin workstation version: GKEADM_VERSION
Created using gkeadm version: GKEADM_VERSION
VM name: ADMIN_WS_NAME
IP: ADMIN_WS_IP
SSH key used: FULL_PATH_TO_ADMIN_WS_SSH_KEY
To access your admin workstation:
ssh -i FULL-PATH-TO-ADMIN-WS-SSH-KEY ubuntu@ADMIN-WS-IP

Voici un exemple de fichier d'informations de sortie :

Admin workstation version: v1.10.3-gke.49
Created using gkeadm version: v1.10.3-gke.49
VM name: admin-ws-janedoe
IP: 172.16.91.21
SSH key used: /usr/local/google/home/janedoe/.ssh/gke-admin-workstation
Upgraded from (rollback version): v1.10.0-gke.194
To access your admin workstation:
ssh -i /usr/local/google/home/janedoe/.ssh/gke-admin-workstation ubuntu@172.16.91.21

Créez le fichier dans un éditeur en remplaçant les paramètres appropriés. Enregistrez le fichier avec un nom de fichier identique au nom de la VM dans le répertoire à partir duquel gkeadm est exécuté. Par exemple, si le nom de la VM est admin-ws-janedoe, enregistrez le fichier sous le nom admin-ws-janedoe.

Étape suivante

• Documentation de référence sur gcloud CLI

  • gcloud container vmware clusters
  • gcloud container vmware node-pools
  • gcloud container vmware admin-clusters

• Documentation de référence Terraform

  • google_gkeonprem_vmware_cluster
  • google_gkeonprem_vmware_node_pool