Mettre à niveau les clusters

Cette page explique comment mettre à niveau vos clusters d'administrateur et d'utilisateur depuis une version de correctif GKE On-Prem vers la version suivante du correctif. Pour en savoir plus sur les versions disponibles, consultez la page Versions.

Voir également :

Présentation

GKE On-Prem est compatible avec la mise à niveau séquentielle. Par exemple, supposons que les versions suivantes soient les seules qui existent :

  • 1.0.10
  • 1.0.X, où X succède à .10
  • 1.0.Y, où Y succède à X

Dans ce cas, la version 1.0.Y est la dernière. Pour mettre à niveau un cluster version 1.0.10 vers la version 1.0.Y, procédez comme suit :

  1. Mettez à niveau le cluster version 1.0.10 vers la version 1.0.X.
  2. Ensuite, mettez à niveau le cluster de la version 1.0.X vers la version 1.0.Y.

Avant de commencer

  1. Connectez-vous en SSH au poste de travail administrateur :

    ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]

  2. Autorisez gcloud à accéder à Google Cloud :

    gcloud auth login

  3. Activez votre compte de service d'accès :

    gcloud auth activate-service-account --project [PROJECT_ID] \
--key-file [ACCESS_KEY_FILE]

    où :

    • [PROJECT_ID] est l'ID de votre projet.
    • [ACCESS_KEY_FILE] est le chemin d'accès au fichier de clé JSON de votre compte de service d'accès, tel que /home/ubuntu/access.json.

Mettre à niveau vers la version 1.0.2

Dans la version 1.0.2-gke.3, les champs OIDC obligatoires suivants (usercluster.oidc) ont été ajoutés. Ces champs permettent de se connecter à un cluster depuis la console Google Cloud:

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

Si vous ne souhaitez pas vous connecter à un cluster depuis la console Google Cloud, mais que vous souhaitez utiliser OIDC, vous pouvez transmettre des valeurs d'espace réservé pour les champs suivants :

oidc:
  kubectlredirecturl: "redirect.invalid"
  clientsecret: "secret"
  usehttpproxy: "false"

Déterminer votre scénario de mise à niveau du cluster

Avant de mettre à niveau votre cluster, choisissez le scénario qui correspond à la version vers laquelle vous effectuez la mise à niveau :

Scénario Action requise Remarques
La version ne comporte aucune mise à jour de sécurité.
  1. Téléchargez la dernière version de gkectl.
  2. Téléchargez le dernier groupe.
  3. Suivez les instructions figurant sur cette page.
La version comporte des mises à jour de sécurité.
  1. Téléchargez l'OVA de la dernière version du poste de travail administrateur.
  2. Mettez à niveau votre poste de travail administrateur.
  3. Suivez les instructions figurant sur cette page.
 Vous ne devez mettre à niveau votre poste de travail administrateur que si la nouvelle version comporte des mises à jour de sécurité. Lorsque vous mettez à niveau votre poste de travail administrateur, celui-ci inclut la dernière version de gkectl et du groupe.

Déterminer la version de la plate-forme

Pour mettre à niveau vos clusters, vous devez déterminer la version de la plate-forme pour vos clusters :

À partir de la documentation

Consultez la page Versions.

À partir du groupe

Exécutez la commande suivante pour extraire le groupe dans un répertoire temporaire :

tar -xvzf /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION].tgz -C [TEMP_DIR]

Examinez les fichiers YAML extraits pour avoir une idée générale du contenu du groupe.

Ouvrez gke-onprem-vsphere-[VERSION]-images.yaml en particulier. Examinez le champ osimages. Vous pouvez voir la version de la plate-forme GKE dans le nom du fichier image de l'OS. Par exemple, dans l'image de l'OS suivante, vous pouvez constater que la version de la plate-forme GKE est 1.12.7-gke.19.

osImages:
  admin: "gs://gke-on-prem-os-ubuntu-release/gke-on-prem-osimage-1.12.7-gke.19-20190516-905ef43658.ova"

Modifier le fichier de configuration

Sur la VM de votre poste de travail administrateur, modifiez votre fichier de configuration. Définissez les valeurs de gkeplatformversion et bundlepath. Exemple :

gkeplatformversion: 1.12.7-gke.19
bundlepath: /var/lib/gke/bundles/gke-onprem-vsphere-1.0.10.tgz

Exécuter gkectl prepare

Exécutez la commande suivante :

gkectl prepare --config [CONFIG_FILE]

La commande gkectl prepare exécute les tâches suivantes :

  • Si nécessaire, copiez une nouvelle image d'OS de nœud dans votre environnement vSphere et marquez-la comme modèle.

  • Transférez les images Docker mises à jour, spécifiées dans le nouveau groupe, vers votre registre Docker privé, si vous en avez configuré un.

Mettre à niveau vos clusters

Pour mettre à niveau un cluster d'utilisateur, la version de votre cluster d'administrateur doit être au moins aussi récente que la version cible de la mise à niveau. Si la version de votre cluster d'administrateur n'est pas aussi récente, mettez d'abord ce cluster à niveau.

Cluster d'administrateur

Exécutez la commande suivante :

gkectl upgrade admin \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE]

où [ADMIN_CLUSTER_KUBECONFIG] est le fichier kubeconfig du cluster d'administrateur et [CONFIG_FILE] est le fichier de configuration GKE On-Prem que vous utilisez pour effectuer la mise à niveau.

Cluster d'utilisateur

Exécutez la commande suivante :

gkectl upgrade cluster \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE] \
--cluster-name [CLUSTER_NAME]

où [ADMIN_CLUSTER_KUBECONFIG] est le fichier kubeconfig du cluster d'administrateur, [CLUSTER_NAME] est le nom du cluster d'utilisateur que vous mettez à niveau et [CONFIG_FILE] est le fichier de configuration GKE On-Prem que vous utilisez pour effectuer la mise à niveau.

À 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 de cluster d'utilisateur, GKE On-Prem 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

  • 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).

Dépannage

Pour en savoir plus, consultez la section Dépannage.

Nouveaux nœuds créés, mais non opérationnels

Symptômes

Les nouveaux nœuds ne s'enregistrent pas eux-mêmes dans le plan de contrôle du cluster d'utilisateur lors de l'utilisation du mode d'équilibrage de charge manuel.

Causes possibles :

La validation Ingress dans les nœuds est peut-être activée, ce qui bloque le processus de démarrage des nœuds.

Solution

Pour désactiver la validation, exécutez la commande suivante :

kubectl patch machinedeployment [MACHINE_DEPLOYMENT_NAME] -p '{"spec":{"template":{"spec":{"providerSpec":{"value":{"machineVariables":{"net_validation_ports": null}}}}}}}' --type=merge

Diagnostiquer des problèmes de cluster à l'aide de gkectl

Utilisez les commandes gkectl diagnose pour identifier les problèmes de cluster et partager des informations de cluster avec Google. Consultez la page Diagnostiquer les problèmes de cluster.

Comportement de journalisation par défaut

Pour gkectl et gkeadm, l'utilisation des paramètres de journalisation par défaut est suffisante :

  • Par défaut, les entrées de journal sont enregistrées comme suit :

    • Pour gkectl, le fichier journal par défaut est /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log, et le fichier est lié symboliquement au fichier logs/gkectl-$(date).log dans le répertoire local où vous exécutez gkectl.
    • Pour gkeadm, le fichier journal par défaut est logs/gkeadm-$(date).log dans le répertoire local où vous exécutez gkeadm.
  • Toutes les entrées de journal sont enregistrées dans le fichier journal, même si elles ne sont pas affichées sur le terminal (lorsque --alsologtostderr a la valeur false).
  • Le niveau de verbosité -v5 (par défaut) couvre toutes les entrées de journal requises par l'équipe d'assistance.
  • Le fichier journal contient également la commande exécutée et le message d'échec.

Nous vous recommandons d'envoyer le fichier journal à l'équipe d'assistance lorsque vous avez besoin d'aide.

Spécifier un emplacement autre que celui par défaut pour le fichier journal

Pour spécifier un emplacement autre que celui par défaut pour le fichier journal gkectl, utilisez l'option --log_file. Le fichier journal que vous spécifiez ne sera pas lié symboliquement au répertoire local.

Pour spécifier un emplacement autre que celui par défaut pour le fichier journal gkeadm, utilisez l'option --log_file.

Localiser des journaux de l'API Cluster dans le cluster d'administrateur

Si une VM ne démarre pas après le démarrage du plan de contrôle d'administrateur, vous pouvez essayer de la déboguer en inspectant les journaux des contrôleurs de l'API Cluster dans le cluster d'administrateur :

  1. Recherchez le nom du pod des contrôleurs d'API Cluster dans l'espace de noms kube-system, où [ADMIN_CLUSTER_KUBECONFIG] est le chemin d'accès au fichier kubeconfig du cluster d'administrateur :

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers

  2. Ouvrez les journaux du pod, où [POD_NAME] correspond au nom du pod. Vous pouvez éventuellement utiliser grep ou un outil similaire pour rechercher les erreurs :

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager