Cette page explique comment mettre à niveau Anthos clusters on VMware (GKE On-Prem). Si votre cluster d'utilisateur est géré par l'API Anthos On-Prem et que vous souhaitez utiliser la console Google Cloud ou Google Cloud CLI pour mettre à niveau le cluster, suivez la procédure de prévisualisation pour découvrir comment mettre à niveau un cluster d'utilisateur à l'aide de clients API Anthos On-Prem.
Présentation du processus de mise à niveau
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.13.0 à la version 1.13.1 ou de la version 1.12.1 à la version 1.13.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, si vous passez de la version 1.11.2 à la version 1.13.0, vous ne pouvez pas procéder à une mise à niveau directe. Vous devez d'abord passer de la version 1.11.2 à la version 1.12.x, puis de la version 1.13.0.
Cet article explique comment passer de la version 1.12.x à la version 1.13.y.
Consultez les bonnes pratiques de mise à niveau des clusters avant de commencer votre processus de mise à niveau.
Voici le workflow général de mise à niveau.
Mettez à niveau votre poste de travail administrateur vers la version cible de la mise à niveau.
Mettez à niveau vos clusters d'utilisateurs depuis votre poste de travail administrateur.
Une fois tous les clusters d'utilisateur mis à niveau, vous pouvez le mettre à niveau depuis le poste de travail administrateur. Cette étape est facultative, sauf si vous avez besoin des fonctionnalités disponibles dans la mise à niveau.
Mise à niveau asynchrone des clusters d'utilisateur
Pour la mise à niveau d'un cluster d'utilisateur, il existe deux variantes de la commande gkectl upgrade cluster:
- Asynchrone (recommandé)
- Synchrone
Avec la variante asynchrone, la commande lance la mise à niveau, puis se termine. Vous n'avez pas besoin de surveiller le résultat de la commande pendant toute la durée de la mise à niveau. Au lieu de cela, vous pouvez vérifier régulièrement la progression de la mise à niveau en exécutant gkectl list cluster et gkectl describe cluster.
Pour utiliser la variante asynchrone, incluez l'indicateur --async dans la commande.
Pour en savoir plus, consultez Mettre à niveau un cluster d'utilisateur.
Rotation des certificats lors de la mise à niveau
Lors d'une mise à niveau, les certificats feuilles sont alternés, mais pas les certificats CA. Vous devez effectuer une rotation manuelle de vos certificats CA au moins une fois tous les cinq ans. Pour en savoir plus, consultez Alterner les autorités de certification du cluster d'utilisateur et Alterner les certificats CA de cluster d'administrateur.
Préparer la mise à niveau
Avant de commencer une mise à niveau, prenez un instantané de votre cluster. L'instantané permet de résoudre les problèmes rencontrés lors de la mise à niveau.
Avant de créer votre poste de travail administrateur, vous avez rempli un fichier de configuration du poste de travail administrateur, généré par gkeadm create config. Le nom par défaut de ce fichier est admin-ws-config.yaml.
De plus, votre poste de travail dispose d'un fichier d'informations. 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 de mise à niveau. 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.
Si votre fichier d'informations de sortie est manquant, vous pouvez le recréer. Consultez Recréer un fichier d'informations en cas d'absence.
Mettre à niveau votre poste de travail administrateur.
Téléchargez
gkeadm:gkeadm upgrade gkeadm --target-version TARGET_VERSION
Remplacez TARGET_VERSION par la version cible de la mise à niveau.
Mettez à niveau votre poste de travail administrateur:
gkeadm upgrade admin-workstation --config AW_CONFIG_FILE --info-file INFO_FILE
Remplacez les éléments suivants :
AW_CONFIG_FILE : 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 : 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 :
Sauvegarde tous les fichiers du répertoire d'accueil de votre poste de travail administrateur actuel. Exemples :
- Le fichier de configuration de votre cluster d'administrateur. Le nom par défaut est
admin-cluster.yaml. - Le fichier de configuration de votre cluster d'utilisateur. Le nom par défaut est
user-cluster.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 et logging-monitoring ;
- Le fichier de configuration de votre cluster d'administrateur. Le nom par défaut est
Crée un poste de travail administrateur et copie tous les fichiers sauvegardés sur le nouveau poste de travail administrateur.
Supprime l'ancien poste de travail administrateur.
Vérifier que suffisamment d'adresses IP sont disponibles
Avant de mettre à niveau vos clusters, assurez-vous d'avoir alloué suffisamment d'adresses IP. Vous pouvez allouer des adresses IP supplémentaires si nécessaire. Consultez la section Gérer les adresses IP des nœuds pour déterminer le nombre d'adresses IP dont vous avez besoin.
Mettre à niveau un cluster d'utilisateur
Ligne de commande
Vous pouvez effectuer la mise à niveau des clusters d'utilisateur de deux façons:
- Asynchrone
- Synchrone
Mise à niveau asynchrone
Exécutez gkectl prepare pour importer des images d'OS dans vSphere:
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Dans le fichier de configuration du cluster d'utilisateur, définissez gkeOnPremVersion sur la version cible de la mise à niveau.
Sur votre poste de travail administrateur, lancez une mise à niveau asynchrone:
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG \ --async
La commande précédente est terminée et vous pouvez continuer à utiliser votre cluster d'utilisateur pendant la mise à niveau.
Pour connaître l'état de la migration:
gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG
La sortie affiche une valeur pour le cluster STATE. Si le cluster est toujours en cours de mise à niveau, la valeur de STATE est UPGRADING. Exemple :
NAMESPACE NAME READY STATE AGE VERSION my-uc-gkeonprem-mgmt my-uc False UPGRADING 9h 1.13.0-gke.1
Les valeurs possibles pour STATE sont PROVISIONING, UPGRADING, DELETING, UPDATING, RUNNING, RECONCILING, ERROR et UNKNOWN.
Pour en savoir plus sur la progression de la mise à niveau et sur les événements du cluster:
gkectl describe cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --cluster USER_CLUSTER_NAME -v 5
La sortie affiche la ressource personnalisée OnPremUserCluster pour le cluster d'utilisateur spécifié, qui inclut l'état du cluster, les conditions et les événements.
Nous enregistrons les événements pour le début et la fin de chaque phase de mise à niveau critique, y compris:
- Mettre à niveau le plan de contrôle
- Mise à niveau du nœud maître
- Mise à niveau des modules complémentaires
- Mise à niveau des pools de nœuds
Exemple de résultat :
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal NodePoolsUpgradeStarted 22m onprem-user-cluster-controller Creating or updating node pools: pool-2: Creating or updating node pool Normal AddonsUpgradeStarted 22m onprem-user-cluster-controller Creating or updating addon workloads Normal ControlPlaneUpgradeStarted 25m onprem-user-cluster-controller Creating or updating cluster control plane workloads: deploying user-kube-apiserver-base, ...: 14/15 pods are ready Normal ControlPlaneUpgradeFinished 23m onprem-user-cluster-controller Control plane is running
Une fois la mise à niveau terminée, gkectl list cluster affiche STATUS de RUNNING:
NAMESPACE NAME READY STATE AGE VERSION my-uc-gkeonprem-mgmt my-uc True RUNNING 9h 1.13.0-gke.1
En outre, une fois la mise à niveau terminée, gkectl describe cluster affiche un champ LastGKEOnPremVersion sous Status. Exemple :
Status: Cluster State: RUNNING LastGKEOnOremVersion: 1.12.0-gke.0
Résoudre les problèmes de mise à niveau asynchrone
Pour une mise à niveau asynchrone, le délai avant expiration est basé sur le nombre de nœuds du cluster. Si la mise à niveau dépasse le délai d'expiration, l'état du cluster passe de UPGRADING à ERROR, et un événement indique que le délai de l'opération a expiré. Notez que l'état ERROR signifie ici que la mise à niveau prend plus de temps que prévu, mais qu'elle n'a pas été arrêtée. Le contrôleur poursuit le rapprochement et relance l'opération.
Un délai avant expiration est généralement dû à un interblocage causé par un PodDisruptionBudget (PDB). Dans ce cas, les pods ne peuvent pas être évincés des anciens nœuds, et ces derniers ne peuvent pas être drainés. Si l'éviction des pods prend plus de 10 minutes, nous écrivons un événement dans l'objet OnPremUserCluster. Vous pouvez capturer l'événement en exécutant gkectl describe cluster. Vous pourrez ensuite ajuster le PDB pour permettre le drainage du nœud. La mise à niveau peut ensuite se terminer et se terminer.
Exemple d'événement :
Warning PodEvictionTooLong 96s (x2 over 4m7s) onprem-user-cluster-controller Waiting too long(>10m0.00000003s) for (kube-system/coredns-856d6dbfdf-dl6nz) eviction.
De plus, lorsqu'une mise à niveau est bloquée ou échoue, vous pouvez exécuter gkectl diagnose pour rechercher les problèmes courants de cluster. En fonction du résultat, vous pouvez décider d'effectuer une correction manuelle ou contacter l'équipe d'assistance Anthos pour obtenir de l'aide.
Mise à niveau synchrone
La commande gkectl upgrade exécute des vérifications préliminaires. Si les vérifications préliminaires échouent, la commande est bloquée. Vous devez corriger les défaillances ou utiliser l'indicateur --skip-preflight-check-blocking. Vous ne devez ignorer les vérifications préliminaires que si vous êtes sûr qu'il n'y a pas de défaillances critiques.
Procédez comme suit sur votre poste de travail administrateur :
Exécutez
gkectl preparepour importer des images d'OS dans vSphere:gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Dans le fichier de configuration du cluster d'utilisateur, définissez
gkeOnPremVersionsur la version cible de la mise à niveau.Mettez à niveau le cluster :
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE
Console
Procédez comme suit si vous souhaitez mettre à niveau un cluster d'utilisateur géré par l'API Anthos On-Prem à l'aide de la console, mais que vous ne souhaitez pas suivre la procédure de mise à niveau de l'aperçu.
Sur votre poste de travail administrateur, exécutez la commande suivante :
gkectl prepare \ --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --upgrade-platformRemplacez les éléments suivants :
- ADMIN_CLUSTER_KUBECONFIG est le chemin d'accès au fichier kubeconfig du cluster d'administrateur.
Cette commande télécharge et installe des bundles sur le cluster d'administrateur, et déploie la nouvelle version des composants qui gèrent le cluster d'utilisateur. Cette commande vous permet de mettre à niveau le cluster d'utilisateur dans la console.
Dans la console Google Cloud, accédez à la page Clusters d'Anthos.
Sélectionnez le projet Google Cloud dans lequel se trouve le cluster d'utilisateur.
Dans la liste des clusters, cliquez sur le cluster que vous souhaitez mettre à niveau.
Dans le panneau Détails, si le type est VM Anthos (VMware), procédez comme suit pour mettre à niveau le cluster à l'aide de la console Google Cloud :
Dans le panneau Détails, cliquez sur Plus de détails.
Dans la section Paramètres de base du cluster, cliquez sur Mettre à niveau.
Dans la liste Versions de Clusters Anthos sur VMware, sélectionnez la version vers laquelle vous souhaitez effectuer la mise à niveau.
Cliquez sur Mettre à jour.
Si le type est externe, cela signifie que le cluster a été créé avec
gkectl. Dans ce cas, suivez les étapes décrites dans l'onglet Ligne de commande pour mettre à niveau le cluster.
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 le cluster d'administrateur
Avant de commencer :
Déterminez si vos certificats sont à jour et renouvelez-les si nécessaire.
Si vous passez à la version 1.13 ou à une version ultérieure, vous devez d'abord enregistrer le cluster d'administrateur en remplissant la section
gkeConnectdans le fichier de configuration du cluster d'administrateur. Exécutez la commande "update" avec les modifications du fichier de configuration.
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é.
Assurez-vous que le champ
bundlepathdu 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 avec les modifications apportées au fichier de configuration pour apporter d'autres modifications au cluster.
Exécutez la commande suivante :
gkectl upgrade admin \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config ADMIN_CLUSTER_CONFIG_FILE \ FLAGSRemplacez les éléments suivants :
ADMIN_CLUSTER_KUBECONFIG : fichier kubeconfig du cluster d'administrateur.
ADMIN_CLUSTER_CONFIG_FILE : fichier de configuration du cluster d'administrateur Clusters Anthos sur VMware de votre nouveau poste de travail administrateur.
FLAGS : ensemble facultatif d'options Par exemple, vous pouvez inclure l'option
--skip-validation-infrapour ignorer la vérification de votre infrastructure vSphere.
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
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 :
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 clusterpour le cluster d'administrateur.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.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 :
- Télécharge la version de rollback de
gkeadm. - Sauvegarde le répertoire d'accueil du poste de travail administrateur actuel.
- Crée un poste de travail administrateur en utilisant la version de rollback de
gkeadm. - 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.
Pour vérifier la version actuelle de
gkectlet les versions de cluster, exécutez cette commande. Utilisez l'indicateur--details/-dpour 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.
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
gkectlest 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
gkectlest antérieure à TARGET_VERSION, mettez à niveau le poste de travail administrateur vers le fichier TARGET_VERSION.
Une fois que vous avez déterminé que vos versions de
gkectlet 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
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.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 :
- Continuez à utiliser la version actuelle pour la production.
- Testez la version du correctif dans un cluster hors production lorsqu'elle est publiée.
- Mettez à niveau tous les clusters d'utilisateur de production vers la version de correctif lorsqu'elle vous paraît fiable.
- 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 :
- Mettez à niveau les clusters d'utilisateur en production vers la version 1.12.x.
- Conservez la version antérieure du cluster d'administrateur et continuez de recevoir des correctifs de sécurité.
- 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.
- 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
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).
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.
À propos des temps d'arrêt pendant les mises à jour
| 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. |
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.