Mettre à jour GKE On-Prem

Cet article explique comment mettre à niveau GKE On-Prem.

Pour mettre à niveau GKE On-Prem, vous devez mettre à niveau votre poste de travail administrateur. Ensuite, vous devez mettre à niveau vos clusters.

Avant de commencer

• Veillez à suivre ces instructions depuis votre poste de travail local ou votre ordinateur portable. Ne suivez pas ces instructions depuis votre poste de travail administrateur existant.
• Vérifiez la version actuelle de vos clusters.
• Consultez les notes de version.
• Examinez les versions

Lisez également les points suivants :

À 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. Remarque : Si les nœuds du cluster d'utilisateur ne parviennent pas à accéder au plan de contrôle d'utilisateur lors de la mise à niveau, les nouvelles charges de travail ne sont pas planifiées dans le cluster. Les charges de travail existantes ne sont pas affectées.
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.

Mise à niveau séquentielle

GKE On-Prem est compatible avec la mise à niveau séquentielle. Pour mettre à niveau un cluster vers une nouvelle version, il doit déjà être de la dernière version précédente.

Vous ne pouvez pas mettre à niveau vos clusters directement vers la dernière version s'ils sont en retard de plusieurs versions. Le cas échéant, vous devez mettre à niveau le cluster de manière séquentielle.

Exemple

Supposons que les versions suivantes soient disponibles, et que votre poste de travail administrateur et vos clusters exécutent la version la plus ancienne :

• 1.0.1 (version la plus ancienne)
• 1.0.2
• 1.1 (dernière version)

Dans ce cas, la version 1.1 est la dernière. Pour passer de la version 1.0.1 à la version 1.1, procédez comme suit :

1. Mettez à niveau votre poste de travail administrateur de la version 1.0.1 vers la version 1.0.2.
2. Mettez à niveau vos clusters de la version 1.0.1 vers la version 1.0.2.
3. Mettez à niveau votre poste de travail administrateur de la version 1.0.2 vers la version 1.1.
4. Mettez à niveau vos clusters de la version 1.0.2 vers la version 1.1.

Sauvegarder votre fichier de configuration GKE On-Prem et vos fichiers kubeconfig

Lorsque vous mettez à niveau votre poste de travail administrateur, Terraform supprime sa VM et la remplace par un poste de travail administrateur mis à niveau. Avant de mettre à niveau votre poste de travail administrateur, vous devez sauvegarder votre fichier de configuration GKE On-Prem et les fichiers kubeconfig de vos clusters. Ensuite, vous devez copier les fichiers sur votre poste de travail administrateur mis à niveau.

Mettre à niveau le poste de travail administrateur

Important : Vous utilisez Terraform pour mettre à niveau votre poste de travail administrateur. Veillez à effectuer une copie des fichiers du poste de travail administrateur. Terraform supprime la VM actuelle du poste de travail administrateur et la remplace par une nouvelle VM.

Lorsque vous mettez à niveau votre poste de travail administrateur, celui-ci inclut les entités suivantes, qui sont de la même version que le fichier OVA (Open Virtualization Appliance) du poste de travail administrateur :

• gkectl
• Groupe complet

Après avoir mis à niveau votre poste de travail administrateur, vous devez mettre à niveau vos clusters.

Télécharger le fichier OVA

À partir de la page Téléchargements, téléchargez le fichier OVA du poste de travail administrateur correspondant à la version vers laquelle vous souhaitez effectuer la mise à niveau.

Pour télécharger le dernier fichier OVA, exécutez la commande suivante :

gsutil cp gs://gke-on-prem-release/admin-appliance/1.1.2-gke.0/gke-on-prem-admin-appliance-vsphere-1.1.2-gke.0.{ova,ova.sig} ~/

Remarque:Pour vérifier ce fichier, consultez Vérifier le fichier OVA avec openssl.

Importer le fichier OVA dans vSphere et le marquer comme modèle de VM

Dans les sections suivantes, vous allez :

1. créer des variables déclarant les éléments de votre environnement vSphere et vCenter Server ;
2. importer l'OVA du poste de travail d'administrateur dans vSphere et le marquer comme modèle de VM.

Créer des variables pour govc

Avant d'importer le fichier OVA du poste de travail administrateur dans vSphere, vous devez fournir à govc certaines variables déclarant les éléments de votre environnement vSphere et vCenter Server.

Remarque : Vous pouvez trouver un grand nombre de ces valeurs en vous connectant à vCenter Server.

export GOVC_URL=https://[VCENTER_SERVER_ADDRESS]/sdk
export GOVC_USERNAME=[VCENTER_SERVER_USERNAME]
export GOVC_PASSWORD=[VCENTER_SERVER_PASSWORD]
export GOVC_DATASTORE=[VSPHERE_DATASTORE]
export GOVC_DATACENTER=[VSPHERE_DATACENTER]
export GOVC_INSECURE=true

Vous pouvez choisir d'utiliser le pool de ressources par défaut de vSphere ou créer le vôtre :

# If you want to use a resource pool you've configured yourself, export this variable:
export GOVC_RESOURCE_POOL=[VSPHERE_CLUSTER]/Resources/[VSPHERE_RESOURCE_POOL]

# If you want to use vSphere's default resource pool, export this variable instead:
export GOVC_RESOURCE_POOL=[VSPHERE_CLUSTER]/Resources

où :

• [VCENTER_SERVER_ADDRESS] est le nom d'hôte ou l'adresse IP de votre serveur vCenter ;
• [VCENTER_SERVER_USERNAME] est le nom d'utilisateur d'un compte détenant le rôle d'administrateur ou des droits équivalents dans le serveur vCenter ;
• [VCENTER_SERVER_PASSWORD] est le mot de passe du compte serveur vCenter ;
• [VSPHERE_DATASTORE] est le nom du datastore que vous avez configuré dans votre environnement vSphere ;
• [VSPHERE_DATACENTER] est le nom du centre de données que vous avez configuré dans votre environnement vSphere ;
• [VSPHERE_CLUSTER] est le nom du cluster que vous avez configuré dans votre environnement vSphere.
Pour utiliser un pool de ressources autre que celui par défaut,
• [VSPHERE_RESOURCE_POOL] est le nom du pool de ressources que vous avez configuré dans votre environnement vSphere.

Importer le fichier OVA dans vSphere : commutateur standard

Si vous utilisez un commutateur standard vSphere, importez le fichier OVA dans vSphere à l'aide de la commande suivante :

govc import.ova -options - ~/gke-on-prem-admin-appliance-vsphere-1.1.2-gke.0.ova <<EOF
{
  "DiskProvisioning": "thin",
  "MarkAsTemplate": true
}
EOF

Importer le fichier OVA dans vSphere : commutateur distribué

Si vous utilisez un commutateur distribué vSphere, importez le fichier OVA dans vSphere à l'aide de cette commande, où [YOUR_DISTRIBUTED_PORT_GROUP_NAME] est le nom de votre groupe de ports distribué :

govc import.ova -options - ~/gke-on-prem-admin-appliance-vsphere-1.1.2-gke.0.ova <<EOF
{
  "DiskProvisioning": "thin",
  "MarkAsTemplate": true,
  "NetworkMapping": [
      {
          "Name": "VM Network",
          "Network": "[YOUR_DISTRIBUTED_PORT_GROUP_NAME]"
      }
  ]
}
EOF

Définir la variable de modèle Terraform pour la nouvelle VM de poste de travail administrateur

Dans le fichier TFVARS de votre poste de travail administrateur, définissez vm_template sur la version vers laquelle vous souhaitez effectuer la mise à niveau. La valeur de vm_template ressemble à ceci, où [VERSION] correspond à la version de l'OVA :

gke-on-prem-admin-appliance-vsphere-[VERSION]

Utiliser Terraform pour mettre à niveau votre poste de travail administrateur

Pour mettre à niveau votre poste de travail administrateur, exécutez la commande ci-après. Cette commande supprime la VM actuelle du poste de travail administrateur et la remplace par une VM mise à niveau :

Remarque:Veillez à importer le fichier OVA dans vSphere avant d'exécuter cette commande.

terraform init && terraform apply -auto-approve -input=false

Se connecter au poste de travail administrateur

1. Se connecter en SSH au poste de travail administrateur :

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

2. Si vous utilisez un proxy, vous devez configurer Google Cloud CLI pour le proxy afin de pouvoir exécuter les commandes gcloud et gsutil. Pour obtenir des instructions, consultez la page Configurer gcloud CLI pour une utilisation derrière un proxy/pare-feu.

3. Connectez-vous à Google Cloud à l'aide des identifiants de votre compte :

   gcloud auth login

4. Enregistrez gcloud en tant qu'assistant d'identification Docker (en savoir plus sur cette commande) :

   gcloud auth configure-docker

5. Créez une clé privée pour votre compte de service sur liste d'autorisation :

   Copiez l'adresse e-mail du compte de service.

   gcloud iam service-accounts list

   Créez la clé privée du compte de service, où [KEY_FILE] est le nom que vous choisissez pour le fichier. Cette commande enregistre le fichier dans le répertoire de travail actuel :

   gcloud iam service-accounts keys create key.json \
   --project [PROJECT_ID] --iam-account [ALLOWLISTED_SERVICE_ACCOUNT_EMAIL]

   où :

   • [PROJECT_ID] est l'ID de votre projet.
   • [KEY_FILE] est un nom et un chemin dans lesquels enregistrer la clé privée du compte de service, telle que /home/ubuntu/key.json.
   • [ALLOWLISTED_SERVICE_ACCOUNT_EMAIL] est l'adresse e-mail du compte de service sur liste d'autorisation.

6. Activez votre compte de service sur liste d'autorisation :

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

Copier la configuration sauvegardée et les fichiers kubeconfig

Précédemment, vous avez sauvegardé votre fichier de configuration GKE On-Prem et les fichiers kubeconfig de vos clusters. Vous devez maintenant copier ces fichiers sur votre poste de travail administrateur mis à niveau.

Mettre à niveau les clusters

Après avoir mis à niveau votre poste de travail administrateur et vous y être connecté, procédez comme suit :

Vérifier que suffisamment d'adresses IP sont disponibles

Avant de procéder à la mise à niveau, assurez-vous que vous disposez de suffisamment d'adresses IP pour vos clusters.

DHCP

Si les adresses IP du cluster sont attribuées par un serveur DHCP, vérifiez que le serveur DHCP du réseau dans lequel les nœuds sont créés possède suffisamment d'adresses IP. Il doit y avoir plus d'adresses IP que de nœuds s'exécutant dans le cluster d'utilisateur.

IP statiques

Si le cluster utilise des adresses IP statiques, vérifiez que vous avez alloué suffisamment d'adresses IP au cluster :

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

où :

• [ADMIN_CLUSTER_KUBECONFIG] indique à kubectl d'utiliser le fichier kubeconfig du cluster d'administrateur, qui permet d'afficher et/ou de modifier les configurations de cluster d'utilisateur.
• -n [USER_CLUSTER_NAME] indique à kubectl d'examiner un espace de noms portant le même nom que le cluster d'utilisateur.
• [USER_CLUSTER_NAME] -o yaml indique à kubectl le cluster d'utilisateur sur lequel vous exécutez la commande. -o yaml affiche la configuration du cluster d'utilisateur.

Dans le résultat de la commande, recherchez le champ reservedAddresses. Il doit y avoir plus d'adresses IP dans le champ que de nœuds en cours d'exécution dans le cluster d'utilisateur.

Si vous devez ajouter d'autres adresses au champ reservedAddresses, procédez comme suit :

1. Ouvrez le fichier de configuration du cluster d'utilisateur pour le modifier :

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] edit cluster [USER_CLUSTER_NAME] \
   -n [USER_CLUSTER_NAME] --validate=false
   

   La configuration du cluster s'ouvre dans l'éditeur par défaut de votre interface système.

2. Ajoutez autant de blocs d'adresses IP statiques supplémentaires que nécessaire. Un bloc d'adresses IP comporte les champs gateway, hostname, ip et netmask.

   Remarque:Il est toujours possible d'ajouter des blocs d'adresses IP au champ reservedAddresses, mais il n'est pas sûr de supprimer des adresses IP utilisées.

Voici un exemple de champ reservedAddresses avec ses quatre blocs d'adresses IP statiques mis en surbrillance :

...
networkSpec:
  dns:
  - 172.x.x.x
  ntp: 129.x.x.x
  reservedAddresses:
  - gateway: 100.x.x.x
    hostname: host-1
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-2
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-3
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-4
    ip: 100.x.x.x
    netmask: x
...

Modifier le fichier de configuration

Sur la VM de votre poste de travail administrateur, modifiez votre fichier de configuration. Définissez la valeur de bundlepath, où [VERSION] est la version de GKE On-Prem vers laquelle vous mettez à niveau vos clusters :

bundlepath: /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION].tgz

À propos des fonctionnalités activées automatiquement

Une nouvelle version de GKE On-Prem peut inclure de nouvelles fonctionnalités ou une compatibilité avec des fonctionnalités VMware vSphere spécifiques. Parfois, la mise à niveau vers une version de GKE On-Prem active automatiquement ces fonctionnalités. Vous pouvez en apprendre plus sur les nouvelles fonctionnalités dans les notes de version de GKE On-Prem. De nouvelles fonctionnalités apparaissent parfois dans le fichier de configuration GKE On-Prem.

Désactiver les nouvelles fonctionnalités via le fichier de configuration

Si vous devez désactiver une nouvelle fonctionnalité qui a été automatiquement activée dans une nouvelle version de GKE On-Prem 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 le champ de la fonctionnalité. Fermez le fichier.

3. Ouvrez votre fichier de configuration actuel et ajoutez le champ de la nouvelle fonctionnalité dans la spécification appropriée.

4. Dans le champ, indiquez false ou une valeur équivalente.

5. Enregistrez le fichier de configuration. Procédez à la mise à niveau de vos clusters.

Avant de mettre à niveau vos clusters, vous devez toujours lire les notes de version. Vous ne pouvez pas modifier de manière déclarative la configuration d'un cluster existant après sa mise à niveau.

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

Mettre à jour votre cluster d'utilisateur

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.

gkectl

Depuis votre poste de travail administrateur, 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.

Console

Vous pouvez choisir d'enregistrer vos clusters d'utilisateur avec lq console Google Cloud lors de l'installation ou après les avoir créés. Depuis le menu GKE de la console Google Cloud, vous pouvez afficher vos clusters GKE On-Prem enregistrés et vos clusters Google Kubernetes Engine et vous y connecter.

Lorsqu'une mise à niveau devient disponible pour les clusters d'utilisateur GKE On-Prem, une notification s'affiche dans la console Google Cloud. Cliquer sur cette notification permet d'afficher la liste des versions disponibles et une commande gkectl que vous pouvez exécuter pour mettre à niveau le cluster :

1. Accédez au menu GKE dans la console Google Cloud.

   Accéder au menu GKE On-Prem

2. Dans la colonne Notifications du cluster d'utilisateur, cliquez sur Mise à niveau disponible, si cette option est disponible.

3. Copiez la commande gkectl upgrade cluster.

4. Depuis votre poste de travail administrateur, exécutez la commande gkectl upgrade cluster, où [ADMIN_CLUSTER_KUBECONFIG] est le fichier kubeconfig du cluster d'administrateur, [CLUSTER_NAME] est le nom du cluster utilisateur que vous mettez à niveau, et [CONFIG_FILE] est le fichier GKE On-Prem que vous utilisez pour effectuer la mise à niveau.

Reprendre une mise à niveau

Si une mise à niveau du cluster d'utilisateur est interrompue, mais que le cluster d'administrateur a bien été mis à niveau, vous pouvez reprendre la mise à niveau en exécutant à nouveau gkectl upgrade cluster avec le même fichier de configuration GKE On-Prem et le même cluster d'administrateur kubeconfig.

À propos de la reprise d'une mise à niveau du 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 pour obtenir de l'aide.

Problèmes connus

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

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.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. Actuellement, un problème connu nécessite que vous fournissiez l'identifiant unique universel (UUID) du dossier à vcenter.datadisk au lieu de son chemin d'accès au fichier. Cette incohérence peut entraîner l'échec des mises à niveau.

Un correctif est prévu pour la version 1.1.2. Avant de procéder à la mise à niveau, procédez comme suit afin d'utiliser le nœud du plan de contrôle administrateur pour contourner ce problème :

1. Depuis l'interface vCenter, obtenez l'UUID du dossier dans votre datastore vSAN.

2. Répertoriez les ressources de la machine figurant dans vos clusters. Ces machines correspondent aux nœuds des clusters :

   kubectl get machines -n all

3. Pour la Machine du plan de contrôle administrateur (gke-admin-master), ouvrez sa configuration pour la modifier :

   kubectl edit machine [MACHINE_NAME]
   

4. Modifiez le champ spec.providerSpec.value.machineVariables.data_disk_path. Remplacez le chemin d'accès du fichier VMDK par l'UUID. Exemple :

   spec:
   providerSpec:
    value:
      apiVersion: vsphereproviderconfig.k8s.io/v1alpha1
      kind: VsphereMachineProviderConfig
      machineVariables:
        data_disk_path: 14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk
        datacenter: datacenter
        datastore: datastore

5. Enregistrez le fichier.

6. Ouvrez le fichier de configuration GKE On-Prem.

7. Dans vcenter.datadisk, remplacez le dossier dans chemin d'accès au fichier par l'UUID du dossier. Exemple :

   vcenter:
    ...
    datadisk: "14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk"
   

8. Procédez à la mise à niveau de vos clusters.

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"

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, GKE On-Prem crée automatiquement des règles d'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 compte utilisateur vSphere fourni dans le champ vcenter dispose de l'autorisation Host.Inventory.EditCluster.
• Au moins trois hôtes physiques sont disponibles.

Désactiver VMware DRS avant la mise à niveau vers la version 1.1.0-gke.6

Si vous ne souhaitez pas activer cette fonctionnalité pour vos clusters d'utilisateur existants (par exemple, si vous ne disposez pas d'un nombre suffisant d'hôtes pour l'exécuter), effectuez la procédure ci-dessous avant de mettre à niveau vos clusters d'utilisateur :

1. Ouvrez votre fichier de configuration GKE On-Prem existant.
2. Sous la spécification usercluster, ajoutez le champ antiaffinitygroups comme décrit dans la documentation antiaffinitygroups :

   usercluster:
         ...
         antiaffinitygroups:
           enabled: false
   

3. Enregistrez le fichier.
4. Utilisez le fichier de configuration pour effectuer la mise à niveau. Vos clusters sont mis à niveau, mais la fonctionnalité n'est pas activée.

Autre scénario de mise à niveau

Cet article décrit le moyen le plus simple de mettre à niveau GKE On-Prem. Le tableau ci-dessous décrit un autre scénario de mise à niveau. Dans ce scénario, vous ne devez mettre à niveau que gkectl et vos clusters, vous ne mettez pas à niveau le poste de travail d'administrateur :

Scénario	Étapes
La version ne comporte aucune mise à jour de sécurité pour le poste de travail administrateur.	Téléchargez gkectl. Téléchargez le package. Suivez les instructions figurant sur cette page.

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