Mettre à niveau Anthos clusters on VMware

Cette page explique comment mettre à niveau Anthos clusters on VMware (GKE On-Prem).

Le processus de mise à niveau a considérablement changé à partir de la version 1.7.

Présentation de la mise à niveau pour la version 1.7

Vous pouvez passer directement à n'importe quelle version de la même version mineure ou de la version mineure suivante. Par exemple, vous pouvez passer de la version 1.7.0 à la version 1.7.3, ou de la version 1.6.1 à la version 1.7.0.

Si vous passez à une version qui ne fait pas partie de la prochaine version mineure, vous devez effectuer une mise à niveau via une version de chaque version mineure entre votre version actuelle et la version souhaitée. Par exemple, il n'est pas possible de procéder à une mise à niveau directe pour passer de la version 1.5.2 à la version 1.7.0. Vous devez d'abord passer de la version 1.5.2 à la version 1.6.x, puis effectuer la mise à niveau vers la version 1.7.0.

Commencez par mettre à niveau le poste de travail administrateur, puis les clusters d'utilisateur et, enfin, le cluster d'administrateur. Vous n'avez pas besoin de mettre à jour le cluster d'administrateur immédiatement après la mise à niveau des clusters d'utilisateur si vous souhaitez conserver le cluster d'administrateur sur sa version actuelle.

  1. Téléchargez l'outil gkeadm. La version de gkeadm doit être identique à la version cible de la mise à niveau.
  2. Mettez à niveau votre poste de travail administrateur.
  3. Mettez à niveau vos clusters d'utilisateurs depuis votre poste de travail administrateur.
  4. Mettez à niveau votre cluster d'administrateur à partir de votre poste de travail administrateur.
  • Le cluster d'administrateur utilise la version 1.6.x, et les clusters d'utilisateur utilisent la version 1.6.x ou 1.7.
  • Ou bien le cluster d'administrateur et les clusters d'utilisateur utilisent tous les deux la version 1.7.

Supposons que votre poste de travail administrateur, votre cluster d'administrateur et vos clusters d'utilisateur utilisent actuellement la version 1.6.2 et que vous souhaitiez mettre à niveau votre cluster d'administrateur et vos clusters d'utilisateurs vers la version 1.7. Si vous suivez une procédure de mise à niveau semblable à celle présentée ci-dessous, en utilisant un cluster Canary à des fins de test avant de poursuivre, vous réduisez le risque d'interruption.

Voici un aperçu général du processus de mise à niveau recommandé. Avant de commencer, créez un cluster d'utilisateur Canary utilisant la version 1.6.2 si ce n'est pas déjà fait.

  1. Testez la version 1.7 dans un cluster Canary.
    • Mettez à niveau le poste de travail administrateur vers la version 1.7.
    • Exécutez la commande gkectl prepare, comme décrit par la suite, pour configurer la mise à niveau.
      • Mettez à niveau le cluster d'utilisateur Canary vers la version 1.7.
  2. Lorsque la version 1.7 vous paraît fiable, mettez à niveau tous les clusters d'utilisateurs de production vers la version 1.7.
  3. Mettez à niveau le cluster d'administrateur vers la version 1.7.

Localiser vos fichiers de configuration et d'informations pour préparer la mise à niveau

Avant de créer votre poste de travail administrateur, vous avez rempli un fichier de configuration généré par gkeadm create config pour ce poste de travail. Le nom par défaut de ce fichier est admin-ws-config.yaml.

De plus, gkeadm a créé un fichier d'informations pour vous. Le nom par défaut de ce fichier est identique à celui de votre poste de travail administrateur actuel.

Localisez le fichier de configuration de votre poste de travail administrateur et le fichier d'informations. Vous en aurez besoin pour suivre la procédure décrite dans ce guide. Si ces fichiers se trouvent dans votre répertoire actuel et qu'ils possèdent un nom par défaut, vous n'avez pas besoin de les spécifier lorsque vous exécutez les commandes de mise à niveau. Si ces fichiers se trouvent dans un autre répertoire ou si vous avez modifié les noms de fichiers, spécifiez-les à l'aide des options --config et --info-file.

Mettre à niveau le poste de travail administrateur

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

Mettre à niveau la configuration de votre poste de travail administrateur

gkeadm upgrade admin-workstation --config [AW_CONFIG_FILE] --info-file [INFO_FILE]

où :

  • [AW_CONFIG_FILE] est le chemin d'accès au fichier de configuration de votre poste de travail administrateur. Vous pouvez omettre cette option si le fichier se trouve dans votre répertoire actuel sous le nom admin-ws-config.yaml.

  • [INFO_FILE] est le chemin d'accès au fichier d'informations. Vous pouvez omettre cette option si le fichier se trouve dans votre répertoire actuel. Le nom par défaut de ce fichier est identique à celui de votre poste de travail administrateur actuel.

La commande précédente exécute les tâches suivantes :

  • Elle sauvegarde tous les fichiers du répertoire d'accueil de votre poste de travail administrateur actuel. y compris :

    • Votre fichier de configuration Anthos clusters on VMware. Le nom par défaut de ce fichier est config.yaml.

    • Les fichiers kubeconfig du cluster d'administrateur et des clusters d'utilisateur.

    • le certificat racine du serveur vCenter. Notez que ce fichier doit disposer des autorisations de propriétaire en lecture et en écriture ;

    • Le fichier de clé JSON pour votre compte de service d'accès au composant. Notez que ce fichier doit disposer des autorisations de propriétaire en lecture et en écriture ;

    • les fichiers de clé JSON des comptes de service connect-register, connect-agent et logging-monitoring.

  • Elle crée un poste de travail administrateur et copie tous les fichiers sauvegardés sur le nouveau poste de travail administrateur.

  • Elle supprime l'ancien poste de travail administrateur.

Vérifier que suffisamment d'adresses IP sont disponibles

Suivez les étapes décrites dans cette section sur votre nouveau poste de travail administrateur.

Avant de procéder à la mise à niveau, assurez-vous que vous disposez de suffisamment d'adresses IP pour vos clusters. Vous pouvez mettre de côté des adresses IP supplémentaires selon les besoins, comme décrit pour chacune des adresses IP DHCP et statiques.

DHCP

Lorsque vous mettez à niveau le cluster administrateur, Anthos clusters on VMware crée un nœud temporaire dans le cluster administrateur. Lorsque vous mettez à niveau un cluster d'utilisateur, Anthos Clusters on VMware crée un nœud temporaire dans ce cluster d'utilisateur. Le nœud temporaire a pour but de garantir une disponibilité ininterrompue. Avant de mettre à niveau un cluster, assurez-vous que votre serveur DHCP peut fournir suffisamment d'adresses IP pour le nœud temporaire. Pour en savoir plus, consultez la section Adresses IP requises pour les clusters d'administrateur et d'utilisateur.

IP statiques

Lorsque vous mettez à niveau le cluster administrateur, Anthos clusters on VMware crée un nœud temporaire dans le cluster administrateur. Lorsque vous mettez à niveau un cluster d'utilisateur, Anthos Clusters on VMware crée un nœud temporaire dans ce cluster d'utilisateur. Le nœud temporaire a pour but de garantir une disponibilité ininterrompue. Avant de mettre à jour un cluster, vérifiez que vous avez réservé suffisamment d'adresses IP. Pour chaque cluster, vous devez réserver au moins une adresse IP supplémentaire par rapport au nombre de nœuds du cluster. Pour en savoir plus, consultez la section Configurer des adresses IP statiques.

Déterminez le nombre de nœuds dans votre cluster d'administrateur :

kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get nodes

où [ADMIN_CLUSTER_KUBECONFIG] est le chemin d'accès au fichier kubeconfig de votre cluster d'administrateur.

Ensuite, affichez les adresses réservées pour votre cluster d'administrateur :

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -o yaml

Dans le résultat, dans le champ reservedAddresses, vous pouvez voir le nombre d'adresses IP réservées pour les nœuds du cluster d'administrateur. Par exemple, le résultat suivant indique que cinq adresses IP sont réservées aux nœuds du cluster d'administrateur :

...
reservedAddresses:
- gateway: 21.0.135.254
  hostname: admin-node-1
  ip: 21.0.133.41
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-2
  ip: 21.0.133.50
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-3
  ip: 21.0.133.56
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-4
  ip: 21.0.133.47
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-5
  ip: 21.0.133.44
  netmask: 21

Le nombre d'adresses IP réservées doit être supérieur (au minimum +1) au nombre de nœuds du cluster d'administrateur.

Pour la version 1.7, vous devez ajouter des adresses IP au cluster d'administrateur :

Commencez par modifier le fichier de bloc d'adresses IP, comme illustré dans cet exemple.

blocks:
- netmask: "255.255.252.0"
  ips:
  - ip: 172.16.20.10
    hostname: admin-host1
  - ip: 172.16.20.11
    hostname: admin-host2
  # Newly-added IPs.
  - ip: 172.16.20.12
    hostname: admin-host3

Exécutez ensuite cette commande pour mettre à jour la configuration.

gkectl update admin --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [ADMIN_CONFIG_FILE]

  • [ADMIN_CLUSTER_KUBECONFIG] est le chemin d'accès au fichier kubeconfig.

  • [ADMIN_CONFIG_FILE] est le chemin d'accès au fichier de configuration d'administrateur. Vous pouvez omettre cette option si le fichier se trouve dans votre répertoire actuel sous le nom admin-config.yaml.

Vous ne pouvez pas supprimer d'adresses IP, mais uniquement les ajouter.

Pour les versions antérieures à la version 1.7, vous pouvez ajouter une adresse supplémentaire en modifiant directement l'objet Cluster.

Ouvrez l'objet Cluster pour le modifier :

kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

Sous reservedAddresses, ajoutez un bloc supplémentaire comportant gateway, hostname, ip et netmask.

Important : À partir de la version 1.5.0, la même procédure ne fonctionne pas pour les clusters d'utilisateur, et vous devez utiliser gkectl update cluster pour chacun d'eux.

Pour déterminer le nombre de nœuds dans un cluster d'utilisateur :

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes

où [USER_CLUSTER_KUBECONFIG] est le chemin d'accès au fichier kubeconfig de votre cluster d'utilisateur.

Pour afficher les adresses réservées pour un cluster d'utilisateur :

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
-n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME] -o yaml

où :

  • [ADMIN_CLUSTER_KUBECONFIG] est le chemin d'accès au fichier kubeconfig de votre cluster d'administrateur.

  • [USER_CLUSTER_NAME] est le nom du cluster d'utilisateur.

Le nombre d'adresses IP réservées doit être supérieur (au minimum +1) au nombre de nœuds du cluster d'utilisateur. Si ce n'est pas le cas, vous pouvez ouvrir le fichier de blocage d'adresses IP du cluster d'utilisateur pour le modifier :

  • Si des adresses réservées à un cluster d'utilisateur sont incluses dans le fichier de bloc d'adresses IP, ajoutez-les au bloc correspondant en fonction de netmask et gateway.

  • Ajoutez autant d'adresses IP statiques supplémentaires que nécessaire dans le bloc correspondant puis exécutez la commande gkectl update cluster.

(Facultatif) Désactiver les nouvelles fonctionnalités vSphere

Une nouvelle version d'Anthos clusters on VMware peut inclure de nouvelles fonctionnalités ou la compatibilité avec des fonctionnalités spécifiques de VMware vSphere. Parfois, la mise à niveau vers une version d'Anthos clusters on VMware active automatiquement ces fonctionnalités. Pour en savoir plus sur les nouvelles fonctionnalités, consultez les notes de version d'Anthos clusters on VMware. De nouvelles fonctionnalités sont parfois introduites dans le fichier de configuration Anthos clusters on VMware.

Si vous devez désactiver une nouvelle fonctionnalité qui a été automatiquement activée dans une nouvelle version de Anthos clusters on VMware et qui est pilotée par le fichier de configuration, effectuez la procédure ci-après avant de mettre à niveau votre cluster :

  1. Depuis votre poste de travail administrateur mis à niveau, créez un fichier de configuration ayant un nom différent de celui de votre fichier de configuration actuel :

    gkectl create-config --config [CONFIG_NAME]

  2. Ouvrez le nouveau fichier de configuration et notez le champ de la fonctionnalité. Fermez le fichier.

  3. Ouvrez le fichier de configuration actuel et ajoutez le champ de la nouvelle fonctionnalité. Définissez la valeur du champ sur false ou une valeur équivalente.

  4. Enregistrez le fichier de configuration.

Consultez les notes de version avant de mettre à niveau vos clusters. Vous ne pouvez pas modifier de manière déclarative la configuration d'un cluster existant après sa mise à niveau.

Installer le bundle pour la mise à niveau

Pour rendre une version disponible pour la création ou la mise à niveau du cluster, vous devez installer le bundle correspondant. Procédez comme suit pour installer un bundle pour TARGET_VERSION, qui correspond au numéro de la version vers laquelle vous souhaitez effectuer la mise à niveau.

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

Voici un exemple de résultat : 

gkectl version: 1.7.2-gke.2 (git-5b8ef94a3)onprem user cluster controller version: 1.6.2-gke.0
current admin cluster version: 1.6.2-gke.0
current user cluster versions (VERSION: CLUSTER_NAMES):
- 1.6.2-gke.0: user-cluster1
available admin cluster versions:
- 1.6.2-gke.0
available user cluster versions:
- 1.6.2-gke.0
- 1.7.2-gke.2
Info: The admin workstation and gkectl is NOT ready to upgrade to "1.8" yet, because there are "1.6" clusters.
Info: The admin cluster can't be upgraded to "1.7", because there are still "1.6" user clusters.

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

  • Si la version de gkectl est antérieure à la version 1.7, le nouveau processus de mise à niveau n'est pas directement disponible. Suivez la procédure de mise à niveau d'origine pour mettre à niveau tous vos clusters vers la version 1.6, puis mettez à niveau votre poste de travail administrateur vers la version 1.7 pour commencer à utiliser le nouveau processus de mise à niveau.

  • Si la version actuelle du cluster d'administrateur est antérieure à la version cible TARGET_VERSION avec un écart de plus d'une version mineure, mettez tous les clusters à niveau de sorte qu'ils soient en version antérieure à TARGET_VERSION avec un écart d'une version mineure seulement.

  • Si la version de gkectl est antérieure à la version cible TARGET_VERSION, mettez à niveau le poste de travail administrateur vers la version cible TARGET_VERSION en suivant les instructions indiquées.

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. 

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

Installez le bundle. 

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

où :

  • [ADMIN_CLUSTER_KUBECONFIG] est le chemin d'accès au fichier kubeconfig. Vous pouvez omettre cette option si le fichier se trouve dans votre répertoire actuel sous le nom kubeconfig.

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.

Mettre à niveau un cluster d'utilisateur

Suivez les étapes décrites dans cette section sur votre poste de travail administrateur.

gkectl upgrade cluster \
    --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    --config [USER_CLUSTER_CONFIG_FILE] \
    [FLAGS]

où :

  • [ADMIN_CLUSTER_KUBECONFIG] est le fichier kubeconfig du cluster d'administrateur.

  • [USER_CLUSTER_CONFIG_FILE] est le fichier de configuration de cluster d'utilisateur Anthos clusters on VMware de votre nouveau poste de travail administrateur.

  • [FLAGS] est un ensemble facultatif d'options. Par exemple, vous pouvez inclure l'option --skip-validation-infra pour ignorer la vérification de votre infrastructure vSphere.

Reprendre une mise à niveau

Si une mise à niveau du cluster d'utilisateur est interrompue, vous pouvez reprendre la mise à niveau du cluster d'utilisateur en exécutant la même commande de mise à niveau avec l'option --skip-validation-all :

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

Mettre à niveau votre cluster d'administrateur

Suivez les étapes décrites dans cette section sur votre nouveau poste de travail administrateur. 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é.

La version cible de votre mise à niveau ne doit pas être supérieure à la version de gkectl, avec un écart maximum d'une version mineure par rapport à votre version de gkectl. Ainsi, si votre gkectl est en version 1.7, la version cible de votre mise à niveau peut aller de la version 1.6.x à 1.7. Le cluster d'administrateur ne peut être mis à niveau que vers une version mineure, lorsque tous les clusters d'utilisateur ont été mis à niveau vers cette version mineure. Par exemple, si vous essayez de mettre à niveau le cluster d'administrateur vers la version 1.7 alors qu'il existe toujours des clusters d'utilisateur en version 1.6.2, vous obtenez un message d'erreur :

admin cluster can't be upgraded to
"1.7.0-gke.0" yet, because there are still user clusters at "1.6.2-gke.0".

Exécutez la commande suivante :

gkectl upgrade admin \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [ADMIN_CLUSTER_CONFIG_FILE] \
[FLAGS]

où :

  • [ADMIN_CLUSTER_KUBECONFIG] est le fichier kubeconfig du cluster d'administrateur.

  • [ADMIN_CLUSTER_CONFIG_FILE] est le fichier de configuration de cluster d'administrateur Anthos clusters on VMware de votre nouveau poste de travail administrateur.

  • [FLAGS] est un ensemble facultatif d'options. Par exemple, vous pouvez inclure l'option --skip-validation-infra pour ignorer la vérification de votre infrastructure vSphere. Utilisez l'option --force-upgrade-admin pour rétablir l'ancien flux de mise à niveau où sont d'abord mis à jour le cluster d'administrateur, puis les clusters d'utilisateur.

Si vous avez téléchargé un bundle complet et que vous avez exécuté les commandes gkectl prepare et gkectl upgrade admin, vous devez maintenant supprimer le bundle complet pour économiser de l'espace disque sur le poste de travail administrateur. Utilisez cette commande :

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

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

Vous ne devez pas interrompre une mise à niveau du cluster d'administrateur. Actuellement, il n'est pas toujours possible de reprendre les mises à niveau du cluster d'administrateur. Si une mise à niveau du cluster d'administrateur est interrompue pour quelque raison que ce soit, contactez l'Assistance Google pour obtenir de l'aide.

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.6.2 et que vous suivez le processus de mise à niveau recommandé.

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

Supposons que vous rencontriez un problème avec la version 1.7 lors du test du cluster Canary ou 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 1.7.x. Vous pouvez procéder comme suit :

  1. Continuer à utiliser la version 1.6.2 pour la production.
  2. Tester la version de correctif 1.7.x dans un cluster Canary lorsqu'elle est déployée. 1 ; Mettre à niveau tous les clusters d'utilisateur de production vers la version 1.7.x lorsqu'elle vous paraît fiable.
  3. Mettre à niveau le cluster d'administrateur vers la version 1.7.x.

Gérer une version de correctif 1.6.x lors des tests en version 1.7

Supposons que vous êtes en train de tester ou de migrer vers la version 1.7, mais que vous doutez encore de sa fiabilité et que votre cluster d'administrateur utilise toujours la version 1.6.2. Vous constatez qu'une version de correctif 1.6.x importante a été publiée. Vous pouvez toujours profiter de cette version de correctif 1.6.x tout en continuant à tester la version 1.7. Suivez ce processus de mise à niveau :

  1. Installez le bundle 1.6.x-gke.0.
  2. Mettez à niveau tous les clusters d'utilisateur de production 1.6.2 vers la version 1.6.x.
  3. Mettez à niveau le cluster d'administrateur vers la version 1.6.x.

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. Par exemple, vous pouvez utiliser le pool de nœuds Container-Optimized OS publié dans la version 1.7. Votre processus de mise à niveau peut se présenter comme suit :

  1. Mettre à niveau les clusters d'utilisateur de production vers la version 1.7.
  2. Conserver le cluster d'administrateur en version 1.6 et continuer de recevoir des correctifs de sécurité.
  3. Tester la mise à niveau du cluster d'administrateur de la version 1.6 vers la version 1.7 dans un environnement de test, et signaler les éventuels problèmes.
  4. Si votre problème est résolu par une version de correctif 1.7, vous pouvez choisir de mettre à niveau le cluster d'administrateur de production de la version 1.6 vers cette version de correctif 1.7 si vous le souhaitez.

Problèmes connus

Les problèmes connus suivants affectent la mise à niveau des clusters.

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.

Version 1.7.0 : modifications apportées aux mises à jour d'Anthos Config Management

Dans les versions antérieures à 1.7.0, Anthos Clusters on VMware comprenait les images requises pour installer et mettre à niveau Anthos Config Management. À partir de la version 1.7.0, le logiciel Anthos Config Management n'est plus inclus dans le bundle Anthos Clusters on VMware. Vous devez l'ajouter séparément. Si vous utilisiez Anthos Config Management sur vos clusters, le logiciel n'est pas mis à jour tant que vous n'avez pas pris les mesures nécessaires.

Pour en savoir plus sur l'installation d'Anthos Config Management, consultez l'article Installer Anthos Config Management.

Version 1.1.0-gke.6, 1.2.0-gke.6 : champ stackdriver.proxyconfigsecretname supprimé

Le champ stackdriver.proxyconfigsecretname a été supprimé dans la version 1.1.0-gke.6. Les vérifications préliminaires d'Anthos clusters on VMware renvoient une erreur si le champ est présent dans le fichier de configuration.

Pour contourner ce problème, avant de procéder à la mise à niveau vers la version 1.2.0-gke.6, supprimez le champ proxyconfigsecretname de votre fichier de configuration.

Stackdriver fait référence à une ancienne version

Avant la version 1.2.0-gke.6, un problème connu empêchait Stackdriver de mettre à jour sa configuration après les mises à niveau du cluster. Stackdriver fait toujours référence à une ancienne version, ce qui empêche Stackdriver de recevoir les dernières fonctionnalités de son pipeline de télémétrie. Ce problème peut compliquer le dépannage des clusters pour l'assistance Google.

Après avoir mis à niveau les clusters vers la version 1.2.0-gke.6, exécutez la commande suivante sur les clusters d'administrateur et d'utilisateur :

kubectl --kubeconfig=[KUBECONFIG] \
-n kube-system --type=json patch stackdrivers stackdriver \
-p '[{"op":"remove","path":"/spec/version"}]'

où [KUBECONFIG] est le chemin d'accès au fichier kubeconfig du cluster.

Perturbation des charges de travail comportant des PodDisruptionBudgets

Actuellement, 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).

Version 1.2.0-gke.6 : Prometheus et Grafana désactivés après la mise à niveau

Lors de la mise à niveau des clusters d'utilisateur, Prometheus et Grafana sont automatiquement désactivés. Cependant, les données de configuration et de métriques sont conservées. Dans les clusters d'administrateur, Prometheus et Grafana restent activés.

Pour obtenir des instructions, reportez-vous aux notes de version d'Anthos clusters on VMware.

Version 1.1.2-gke.0 : les nœuds de cluster d'utilisateur supprimés ne sont pas retirés du datastore vSAN

Pour obtenir des instructions, reportez-vous aux notes de version d'Anthos clusters on VMware.

Version 1.1.1-gke.2 : le disque de données du dossier de datastore vSAN peut être supprimé

Si vous utilisez un datastore vSAN, vous devez créer un dossier dans lequel enregistrer le VMDK. Un problème connu nécessite que vous fournissiez le chemin UUID (Universally Unique Identifier) du dossier, et non le chemin du fichier, à vcenter.datadisk. Cette incohérence peut entraîner l'échec des mises à niveau.

Pour obtenir des instructions, reportez-vous aux notes de version d'Anthos clusters on VMware.

Mise à niveau vers la version 1.1.0-gke.6 depuis la version 1.0.2-gke.3 : problème OIDC

Les clusters des versions 1.0.11, 1.0.1-gke.5 et 1.0.2-gke.3 pour lesquels OpenID Connect (OIDC) est configuré ne peuvent pas être mis à niveau vers la version 1.1.0-gke.6. Ce problème est résolu dans la version 1.1.1-gke.2.

Si vous avez configuré un cluster de version 1.0.11, 1.0.1-gke.5 ou 1.0.2-gke.3 avec OIDC lors de l'installation, vous ne pouvez pas le mettre à niveau. À la place, vous devez créer d'autres clusters.

Mise à niveau vers la version 1.0.2-gke.3 depuis la version 1.0.11

La version 1.0.2-gke.3 introduit les champs OIDC suivants (usercluster.oidc). Ces champs permettent de se connecter à un cluster à partir de la console Google Cloud :

  • usercluster.oidc.kubectlredirecturl
  • usercluster.oidc.clientsecret
  • usercluster.oidc.usehttpproxy

Si vous souhaitez utiliser OIDC, le champ clientsecret est obligatoire, même si vous ne souhaitez pas vous connecter à un cluster depuis la console Google Cloud. Pour utiliser OIDC, vous devrez peut-être fournir une valeur d'espace réservé pour clientsecret :

oidc:
  clientsecret: "secret"

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, Anthos clusters on VMware crée automatiquement des règles anti-affinité VMware Distributed Resource Scheduler (DRS) pour les nœuds de votre cluster d'utilisateur. Ceux-ci sont ainsi répartis 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 d'Anthos clusters on VMware.

Temps d'arrêt

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

Ressource Description
Cluster d'administrateur

En cas de panne d'un cluster d'administrateur, les plans de contrôle et les charges de travail des clusters d'utilisateur continuent de s'exécuter, sauf s'ils sont affectés par une panne ayant provoqué le temps d'arrêt.
Plan de contrôle du cluster d'utilisateur

En règle générale, les plans de contrôle des clusters d'utilisateur ne font pas l'objet de temps d'arrêt significatifs. Cependant, les connexions de longue durée au serveur d'API Kubernetes peuvent être interrompues et doivent être rétablies. Dans ce cas, l'appelant de l'API doit effectuer de nouvelles tentatives jusqu'à ce qu'il établisse une connexion. Dans le pire des cas, le temps d'arrêt peut durer jusqu'à une minute pendant une mise à niveau.
Nœuds de cluster d'utilisateur

Si une mise à niveau nécessite une modification des nœuds du cluster d'utilisateur, Anthos clusters on VMware recrée les nœuds de manière progressive et replanifie les pods exécutés sur ces nœuds. Vous pouvez éviter l'impact sur vos charges de travail en configurant des règles PodDisruptionBudgets et d'anti-affinité appropriées.

Problèmes connus

Consultez la page Problèmes connus.

Dépannage

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