Cette page a été traduite par l'API Cloud Translation.

Mettre à niveau un cluster ou un pool de nœuds

Ce document explique comment mettre à niveau des clusters et des pools de nœuds dans Google Distributed Cloud. Ce document décrit la procédure à suivre pour mettre à niveau votre poste de travail d'administrateur, vos clusters d'utilisateur et vos clusters d'administrateur. Pour les clusters d'utilisateur, ce document explique comment mettre à niveau le plan de contrôle et les pools de nœuds en même temps ou séparément.

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

Présentation de la mise à niveau
Ce document décrit, entre autres, le décalage entre les versions et les règles de version pour les mises à niveau, qui ont changé à partir de la version 1.28.
Bonnes pratiques de mise à niveau
Ce document fournit des checklists et des bonnes pratiques pour la mise à niveau des clusters.

Examiner vos règles de pare-feu

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

Avec les vérifications préliminaires côté serveur, lorsque vous mettez à niveau un cluster d'utilisateur à l'aide de gkectl, les vérifications préliminaires sont exécutées sur le cluster d'administrateur plutôt que localement sur le poste de travail administrateur. Les vérifications préliminaires côté serveur sont également exécutées sur le cluster d'administrateur lorsque vous mettez à niveau un cluster à l'aide de la console Google Cloud, de Google Cloud CLI ou de Terraform.

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

Exigences concernant l'API Google et IAM

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

Activer kubernetesmetadata.googleapis.com :
```
gcloud services enable --project PROJECT_ID  \
    kubernetesmetadata.googleapis.com
```
Remplacez PROJECT_ID par l'ID du projet hôte du parc dont le cluster d'utilisateur est membre. Il s'agit du projet que vous avez spécifié lors de la création du cluster. Si vous avez créé le cluster à l'aide de gkectl, il s'agit de l'ID de projet indiqué dans le champ gkeConnect.projectID du fichier de configuration du cluster.
Si votre organisation a configuré une liste d'autorisation qui permet au trafic provenant des API Google et d'autres adresses de transiter par votre serveur proxy, ajoutez kubernetesmetadata.googleapis.com à la liste d'autorisation.
Accordez le rôle kubernetesmetadata.publisher au compte de service logging-monitoring:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member "serviceAccount:SERVICE_ACCOUNT_EMAIL" \
  --role "roles/kubernetesmetadata.publisher"
```
Remplacez SERVICE_ACCOUNT_EMAIL par l'adresse e-mail de votre compte de service logging-monitoring.

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

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

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

Pour mettre à niveau le cluster à l'aide de la console, vous devez au minimum disposer des éléments suivants:

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

Modifier la configuration avant ou après une mise à niveau

Si vous devez modifier la configuration de vos clusters, mettez-les à jour avant ou après. La seule modification apportée à la configuration du cluster pour une mise à niveau doit être la version. Selon la version et le type de cluster, les autres modifications de configuration sont ignorées en mode silencieux ou font échouer la mise à niveau. Pour en savoir plus, consultez Supprimer les modifications non compatibles pour débloquer la mise à niveau.

Mettre à niveau votre poste de travail administrateur.

Vous devez mettre à niveau votre poste de travail administrateur si vous prévoyez de mettre à niveau un cluster d'utilisateur à l'aide de gkectl.

Si vous prévoyez de mettre à niveau un cluster d'utilisateur à l'aide de la console, de gcloud CLI ou de Terraform, vous pouvez ignorer la mise à niveau du poste de travail administrateur pour le moment. Toutefois, vous devrez mettre à niveau le poste de travail administrateur lorsque vous serez prêt à mettre à niveau le cluster d'administrateur, car seul gkectl est compatible avec les mises à niveau.

La façon dont vous mettez à niveau votre poste de travail administrateur dépend de la façon dont vous l'avez créé : gkeadm ou user-mmanaged.

gkeadm

Localiser les fichiers requis

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 la section Recréer un fichier d'informations s'il est manquant.

Mettre à niveau

Pour mettre à niveau le poste de travail administrateur:

Téléchargez gkeadm:
```
gkeadm upgrade gkeadm --target-version TARGET_VERSION
```
Remplacez TARGET_VERSION par la version cible de votre mise à niveau. Vous devez spécifier un numéro de version complet au format X.Y.Z-gke.N.. Pour obtenir la liste des versions de Google Distributed Cloud, consultez la section Historique des versions.
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.

Géré par l'utilisateur

Sur votre poste de travail administrateur, accédez au répertoire dans lequel vous souhaitez installer une nouvelle version de gkectl.

Téléchargez gkectl:

gsutil cp gs://gke-on-prem-release/gkectl/VERSION/gkectl ./
chmod +x gkectl

Remplacez VERSION par la version cible de votre mise à niveau. Par exemple, 1.29.100-gke.248.

Téléchargez le bundle Google Distributed Cloud. Assurez-vous que la version correspond à celle que vous avez utilisée pour télécharger gkectl:

gsutil cp gs://gke-on-prem-release/gke-onprem-bundle/VERSION/gke-onprem-vsphere-VERSION.tgz ./

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

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

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Le résultat affiche la version actuelle et les versions disponibles pour la mise à niveau.

Si vous prévoyez d'utiliser la console, gcloud CLI ou Terraform pour effectuer la mise à niveau, il faut compter environ 7 à 10 jours après la publication de la version pour que celle-ci soit disponible dans l'API GKE On-Prem dans toutes les régions Google Cloud. La console répertorie uniquement les versions disponibles pour la mise à niveau du cluster d'utilisateur. Les étapes de mise à niveau d'un cluster d'utilisateur à l'aide de gcloud CLI ou de Terraform incluent une étape permettant d'exécuter gcloud container vmware clusters query-version-config afin d'obtenir les versions disponibles pour la mise à niveau.

Mettre à niveau un cluster d'utilisateur

Vous pouvez utiliser gkectl, la console, gcloud CLI ou Terraform pour mettre à niveau un cluster d'utilisateur. Pour en savoir plus sur le choix de l'outil à utiliser, consultez la section Choisir un outil pour mettre à niveau les clusters d'utilisateur.

gkectl

Préparer la mise à niveau d'un cluster d'utilisateur

Procédez comme suit sur votre poste de travail administrateur:

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

Si votre cluster dispose d'un pool de nœuds Windows, exécutez gkectl prepare windows, puis mettez à jour le champ osImage du pool de nœuds. Pour obtenir des instructions détaillées, consultez la page Mettre à niveau un cluster d'utilisateur avec des pools de nœuds Windows.
Dans le fichier de configuration du cluster d'utilisateur, définissez gkeOnPremVersion sur la version cible de votre mise à niveau.
Pools de nœuds Ubuntu et COS uniquement: spécifiez les pools de nœuds que vous souhaitez mettre à niveau. La mise à niveau des pools de nœuds séparément du plan de contrôle est possible pour les pools de nœuds Ubuntu et COS, mais pas pour les pools de nœuds Windows.

Dans le fichier de configuration de votre cluster d'utilisateur, indiquez les pools de nœuds que vous souhaitez mettre à niveau, comme suit:
- Pour chaque pool de nœuds que vous souhaitez mettre à niveau, supprimez le champ nodePools.nodePool[i].gkeOnPremVersion ou définissez-le sur une chaîne vide.
- Pour chaque pool de nœuds que vous ne souhaitez pas mettre à niveau, définissez nodePools.nodePool[i].gkeOnPremVersion sur la version actuelle.
Par exemple, supposons que votre cluster d'utilisateur utilise la version 1.15.5-gke.41 et qu'il comporte deux pools de nœuds: pool-1 et pool-2. Supposons également que vous souhaitiez mettre à niveau le plan de contrôle et pool-1 vers la version 1.16.3-gke.45, mais que vous souhaitiez que pool-2 reste à la version 1.15.5-gke.41. La partie suivante d'un fichier de configuration de cluster d'utilisateur montre comment spécifier cet exemple:
```
gkeOnPremVersion: 1.16.3-gke.45

nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  cpus: 4
  memoryMB: 8192
  replicas: 3
  osImageType: ubuntu_containerd
- name: pool-2
  gkeOnPremVersion: 1.15.5-gke.41
  cpus: 4
  memoryMB: 8192
  replicas: 5
  osImageType: ubuntu_containerd
```

Exécuter des vérifications préliminaires

Lors de la mise à niveau vers la version 1.29 ou une version ultérieure, vous pouvez exécuter les vérifications préliminaires avant de mettre à niveau un cluster d'utilisateur:

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

Avec l'option --dry-run, gkectl upgrade cluster exécute les vérifications préliminaires, mais ne lance pas le processus de mise à niveau. Bien que les versions antérieures de Google Distributed Cloud exécutent des vérifications préliminaires, elles ne peuvent pas être exécutées séparément de la mise à niveau. En ajoutant l'indicateur --dry-run, vous pouvez rechercher et résoudre les problèmes détectés par les vérifications préliminaires dans votre cluster d'utilisateur avant la mise à niveau.

Exécuter `gkectl upgrade cluster`

Il existe deux variantes de la commande gkectl upgrade cluster:

Asynchrone: (recommandé)
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. À la place, vous pouvez vérifier régulièrement la progression de la mise à niveau en exécutant gkectl list clusters et gkectl describe clusters. Pour utiliser la variante asynchrone, incluez l'option --async dans la commande.
Synchrone:
Avec la variante synchrone, la commande gkectl upgrade cluster renvoie des messages d'état au poste de travail administrateur à mesure que la mise à niveau progresse.

Mise à niveau asynchrone

Ignorez cette étape si vous effectuez une mise à niveau vers une version ultérieure à la version 1.16.

Si vous utilisez des identifiants préparés et un registre privé pour le cluster d'utilisateur, assurez-vous que les identifiants du registre privé sont préparés avant de mettre à niveau le cluster d'utilisateur. Pour en savoir plus sur la préparation des identifiants du registre privé, consultez la section Configurer les identifiants préparés pour les clusters d'utilisateur.
Sur votre poste de travail administrateur, démarrez 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 poste de travail administrateur pendant la mise à niveau.
Pour consulter l'état de la mise à niveau:
```
gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Le résultat 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.29.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 les événements du cluster:

gkectl describe clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --cluster USER_CLUSTER_NAME -v 5

Le résultat affiche la ressource personnalisée OnPremUserCluster pour le cluster d'utilisateur spécifié, qui inclut l'état, les conditions et les événements du cluster.

Nous enregistrons les événements de début et de fin de chaque phase critique de mise à niveau, y compris:

ControlPlaneUpgrade
MasterNodeUpgrade
AddonsUpgrade
NodePoolsUpgrade

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 clusters affiche un STATUS RUNNING:
```
NAMESPACE             NAME    READY   STATE     AGE     VERSION
my-uc-gkeonprem-mgmt  my-uc   True    RUNNING   9h      1.29.0-gke.1
```
En outre, une fois la mise à niveau terminée, gkectl describe clusters affiche un champ Last GKE On Prem Version sous Status. Exemple :
```
Status:
Cluster State:  RUNNING
Last GKE On Prem Version:  1.29.0-gke.1
```

Résoudre les problèmes de mise à niveau asynchrone

En général, un délai avant expiration est le résultat d'un interblocage causé par un PodDisruptionBudget (PDB). Dans ce cas, les pods ne peuvent pas être évincés des anciens nœuds, et les anciens nœuds ne peuvent pas être drainés. Si l'éviction du pod prend plus de 10 minutes, nous écrivons un événement dans l'objet OnPremUserCluster. Pour capturer l'événement, exécutez gkectl describe clusters. Vous pouvez ensuite ajuster le PDB pour permettre au nœud de se drainer. Ensuite, la mise à niveau peut se poursuivre et finir par 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 de cluster courants. En fonction du résultat, vous pouvez décider d'effectuer une correction manuelle ou de 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 échecs ou utiliser l'option --skip-preflight-check-blocking. Vous ne devez ignorer les vérifications préliminaires que si vous êtes certain qu'il n'y a pas d'échec critique.

Procédez comme suit sur votre poste de travail administrateur :

Ignorez cette étape si vous effectuez une mise à niveau vers une version ultérieure à la version 1.16.

Si vous utilisez des identifiants préparés et un registre privé pour le cluster d'utilisateur, assurez-vous que les identifiants du registre privé sont préparés avant de mettre à niveau le cluster d'utilisateur. Pour en savoir plus sur la préparation des identifiants du registre privé, consultez la section Configurer les identifiants préparés pour les clusters d'utilisateur.

Mettez à niveau le cluster :

gkectl upgrade cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG_FILE

Si vous effectuez une mise à niveau vers la version 1.14.0 ou une version ultérieure, un nouveau fichier kubeconfig est généré pour le cluster d'utilisateur. Il écrase tout fichier existant. Pour afficher les détails du cluster dans le fichier, exécutez la commande suivante:
```
kubectl config view --kubeconfig USER_CLUSTER_KUBECONFIG
```

Mettre à niveau des pools de nœuds supplémentaires

Si vous n'avez mis à niveau que le plan de contrôle du cluster d'utilisateur ou que vous avez mis à niveau le plan de contrôle et certains pools de nœuds, mais pas tous, procédez comme suit pour mettre à niveau les pools de nœuds:

Modifiez le fichier de configuration de votre cluster d'utilisateur. Pour chaque pool de nœuds que vous souhaitez mettre à niveau, supprimez le champ nodePools.nodePool[i].gkeOnPremVersion ou définissez-le sur une chaîne vide, comme illustré dans l'exemple suivant:
```
gkeOnPremVersion: 1.16.3-gke.45

nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  cpus: 4
  memoryMB: 8192
  replicas: 3
  osImageType: ubuntu_containerd
- name: pool-2
  gkeOnPremVersion: ""
  cpus: 4
  memoryMB: 8192
  replicas: 5
  osImageType: ubuntu_containerd
```
Exécutez gkectl update cluster pour appliquer la modification:
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG
```
Remplacez les éléments suivants :
- ADMIN_CLUSTER_KUBECONFIG: chemin d'accès au fichier kubeconfig de votre cluster d'administrateur
- USER_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'utilisateur

Si vous rencontrez un problème après la mise à niveau d'un pool de nœuds, vous pouvez effectuer un rollback vers la version précédente. Pour en savoir plus, consultez la section Effectuer le rollback d'un pool de nœuds après une mise à niveau.

Reprendre une mise à niveau

Si la mise à niveau d'un cluster d'utilisateur est interrompue, vous pouvez la reprendre 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

Console

La mise à niveau d'un cluster d'utilisateur nécessite certaines modifications au niveau du cluster d'administrateur. La console effectue automatiquement les opérations suivantes:

Il enregistre le cluster d'administrateur dans l'API GKE On-Prem s'il n'est pas déjà enregistré.
Il télécharge et déploie un bundle de composants sur le cluster d'administrateur. La version des composants correspond à la version que vous spécifiez pour la mise à niveau. Ces composants permettent au cluster d'administrateur de gérer les clusters d'utilisateur de cette version.

Pour mettre à niveau un cluster d'utilisateur:

Dans la console, accédez à la page de présentation des clusters Google Kubernetes Engine.

Accéder aux clusters GKE
Sélectionnez le projet Google Cloud, puis le cluster que vous souhaitez mettre à niveau.
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 Choisir la version cible, sélectionnez la version vers laquelle vous souhaitez effectuer la mise à niveau. Cette liste ne contient que les dernières versions des correctifs.
Cliquez sur Mettre à jour.

Avant la mise à niveau du cluster, des vérifications préliminaires sont exécutées pour valider l'état du cluster et celui des nœuds. Si les vérifications préliminaires réussissent, le cluster d'utilisateur est mis à niveau. La mise à niveau prend environ 30 minutes.

Pour afficher l'état de la mise à niveau, cliquez sur Afficher les détails dans l'onglet Détails du cluster.

gcloud CLI

La mise à niveau d'un cluster d'utilisateur nécessite certaines modifications au niveau du cluster d'administrateur. La commande gcloud container vmware clusters upgrade effectue automatiquement les opérations suivantes:

Il enregistre le cluster d'administrateur dans l'API GKE On-Prem s'il n'est pas déjà enregistré.
Il télécharge et déploie un bundle de composants sur le cluster d'administrateur. La version des composants correspond à la version que vous spécifiez pour la mise à niveau. Ces composants permettent au cluster d'administrateur de gérer les clusters d'utilisateur de cette version.

Pour mettre à niveau un cluster d'utilisateur:

Mettez à jour les composants de la Google Cloud CLI :
```
gcloud components update
```
Pools de nœuds Ubuntu et COS uniquement: si vous souhaitez mettre à niveau uniquement le plan de contrôle du cluster d'utilisateur et conserver tous les pools de nœuds sur la version actuelle, modifiez la règle de mise à niveau sur le cluster:
```
gcloud container vmware clusters update USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --upgrade-policy control-plane-only=True
```
Remplacez les éléments suivants :
- USER_CLUSTER_NAME: nom du cluster d'utilisateur à mettre à niveau.
- PROJECT_ID: ID du projet hôte du parc auquel le cluster d'utilisateur fait partie. Il s'agit du projet que vous avez spécifié lors de la création du cluster. Si vous avez créé le cluster à l'aide de gkectl, il s'agit de l'ID de projet indiqué dans le champ gkeConnect.projectID du fichier de configuration du cluster.
- REGION: région Google Cloud dans laquelle l'API GKE On-Prem s'exécute et stocke ses métadonnées. Si vous avez créé le cluster à l'aide d'un client API GKE On-Prem, il s'agit de la région que vous avez sélectionnée lors de la création du cluster. Si vous avez créé le cluster à l'aide de gkectl, il s'agit de la région que vous avez spécifiée lors de l'enregistrement du cluster dans l'API GKE On-Prem.

Obtenez la liste des versions disponibles pour la mise à niveau:

gcloud container vmware clusters query-version-config \
  --cluster=USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION

La sortie de la commande ressemble à ceci :

versions:
- version: 1.16.3-gke.45
- version: 1.16.2-gke.28
- version: 1.16.1-gke.45
- version: 1.16.0-gke.669
- version: 1.15.6-gke.25
- version: 1.15.5-gke.41

An Anthos version must be made available on the admin cluster ahead of the user
cluster creation or upgrade. Versions annotated with isInstalled=true are
installed on the admin cluster for the purpose of user cluster creation or
upgrade whereas other version are released and will be available for upgrade
once dependencies are resolved.

To install the version in the admin cluster, run:
$ gcloud container vmware admin-clusters update my-admin-cluster --required-platform-version=VERSION

Vous pouvez ignorer le message après la liste des versions. Peu importe si la version vers laquelle vous effectuez la mise à niveau est installée sur le cluster d'administrateur. La commande upgrade télécharge et déploie un groupe de composants correspondant à la version que vous spécifiez dans la commande upgrade.

Mettez à niveau le cluster. Si vous avez exécuté la commande update pour définir la règle de mise à niveau sur control-plane-only=True, seul le plan de contrôle du cluster est mis à niveau. Sinon, le plan de contrôle du cluster et tous les pools de nœuds sont mis à niveau.
```
gcloud container vmware clusters upgrade USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --version=VERSION
```
Remplacez VERSION par la version de Google Distributed Cloud vers laquelle vous souhaitez effectuer la mise à niveau. Spécifiez une version à partir du résultat de la commande précédente. Nous vous recommandons de passer à la version de correctif la plus récente.

La sortie de la commande ressemble à ceci :
```
Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.
```
Dans l'exemple de résultat, la chaîne operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 correspond au OPERATION_ID de l'opération de longue durée. Vous pouvez vérifier l'état de l'opération en exécutant la commande suivante dans une autre fenêtre de terminal:
```
gcloud container vmware operations describe OPERATION_ID \
  --project=PROJECT_ID \
  --location=REGION
```

Mettre à niveau les pools de nœuds

Si vous avez choisi de ne mettre à niveau que le plan de contrôle du cluster d'utilisateur, procédez comme suit pour mettre à niveau les pools de nœuds une fois le plan de contrôle du cluster d'utilisateur mis à niveau:

Obtenez la liste des pools de nœuds du cluster d'utilisateur:

gcloud container vmware node-pools list
  --cluster=USER_CLUSTER_NAME  \
  --project=PROJECT_ID \
  --location=REGION

Pour chaque pool de nœuds que vous souhaitez mettre à niveau, exécutez la commande suivante:

gcloud container vmware node-pools update NODE_POOL_NAME \
  --cluster=USER_CLUSTER_NAME  \
  --project=PROJECT_ID \
  --location=REGION \
  --version=VERSION

Terraform

Mettez à jour les composants de la Google Cloud CLI :
```
gcloud components update
```
Si vous ne l'avez pas déjà fait, enregistrez le cluster d'administrateur dans l'API GKE On-Prem. Une fois le cluster enregistré dans l'API GKE On-Prem, vous n'avez pas besoin de répéter cette étape.

Obtenez la liste des versions disponibles pour la mise à niveau:

gcloud container vmware clusters query-version-config \
  --cluster=USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION

Remplacez les éléments suivants :

USER_CLUSTER_NAME: nom du cluster d'utilisateur.
PROJECT_ID: ID du projet de parc dont fait partie le cluster d'utilisateur. Il s'agit du projet que vous avez spécifié lors de la création du cluster. Si vous avez créé le cluster à l'aide de gkectl, il s'agit de l'ID de projet indiqué dans le champ gkeConnect.projectID du fichier de configuration du cluster.
REGION: région Google Cloud dans laquelle l'API GKE On-Prem s'exécute et stocke ses métadonnées. Dans le fichier main.tf que vous avez utilisé pour créer le cluster d'utilisateur, la région se trouve dans le champ location de la ressource de cluster.

La sortie de la commande ressemble à ceci :

versions:
- version: 1.16.3-gke.45
- version: 1.16.2-gke.28
- version: 1.16.1-gke.45
- version: 1.16.0-gke.669
- version: 1.15.6-gke.25
- version: 1.15.5-gke.41

An Anthos version must be made available on the admin cluster ahead of the user
cluster creation or upgrade. Versions annotated with isInstalled=true are
installed on the admin cluster for the purpose of user cluster creation or
upgrade whereas other version are released and will be available for upgrade
once dependencies are resolved.

To install the version in the admin cluster, run:
$ gcloud container vmware admin-clusters update my-admin-cluster --required-platform-version=VERSION

Téléchargez la nouvelle version des composants et déployez-les dans le cluster d'administrateur:
```
gcloud vmware admin-clusters update ADMIN_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --required-platform-version=VERSION
```
Cette commande télécharge la version des composants que vous spécifiez dans --required-platform-version sur le cluster d'administrateur, puis déploie les composants. Ces composants permettent au cluster d'administrateur de gérer les clusters d'utilisateur de cette version.
Dans le fichier main.tf que vous avez utilisé pour créer le cluster d'utilisateur, remplacez on_prem_version dans la ressource de cluster par la nouvelle version.
Pools de nœuds Ubuntu et COS uniquement: si vous ne souhaitez mettre à niveau que le plan de contrôle du cluster d'utilisateur et conserver tous les pools de nœuds dans la version actuelle, ajoutez ce qui suit à la ressource de cluster:
```
upgrade_policy {
  control_plane_only = true
}
```
Initialisez et créez le plan Terraform :
```
terraform init
```
Terraform installe les bibliothèques nécessaires, telles que le fournisseur Google Cloud.
Examinez la configuration et apportez des modifications si nécessaire:
```
terraform plan
```
Appliquez le plan Terraform pour créer le cluster d'utilisateur:
```
terraform apply
```

Mettre à niveau les pools de nœuds

Si vous avez choisi de ne mettre à niveau que le plan de contrôle du cluster d'utilisateur, procédez comme suit pour mettre à niveau des pools de nœuds supplémentaires une fois le plan de contrôle du cluster d'utilisateur mis à niveau:

Dans main.tf, dans la ressource de chaque pool de nœuds que vous souhaitez mettre à niveau, ajoutez les éléments suivants:

on_prem_version = "VERSION"

Exemple :

resource "google_gkeonprem_vmware_node_pool" "nodepool-basic" {
name = "my-nodepool"
location = "us-west1"
vmware_cluster = google_gkeonprem_vmware_cluster.default-basic.name
config {
  replicas = 3
  image_type = "ubuntu_containerd"
  enable_load_balancer = true
}
on_prem_version = "1.16.0-gke.0"
}

Initialisez et créez le plan Terraform :
```
terraform init
```
Examinez la configuration et apportez des modifications si nécessaire:
```
terraform plan
```
Appliquez le plan Terraform pour créer le cluster d'utilisateur:
```
terraform apply
```

Mettre à niveau le cluster d'administrateur

Après avoir mis à niveau vos clusters d'utilisateur, vous pouvez mettre à niveau votre cluster d'administrateur.

Avant de commencer :

Déterminez si vos certificats sont à jour et renouvelez-les si nécessaire.
Si vous effectuez une mise à niveau vers la version 1.13 ou une version ultérieure, vous devez d'abord enregistrer le cluster d'administrateur en remplissant la section gkeConnect du fichier de configuration du cluster d'administrateur. Exécutez la commande gkectl update cluster avec les modifications apportées au fichier de configuration.
Assurez-vous que votre gkectl et vos clusters sont la version appropriée pour une mise à niveau et que vous avez téléchargé le bundle approprié. Le décalage de version entre vos clusters d'administrateur et d'utilisateur dépend de la version de Google Distributed Cloud. Pour vous assurer de pouvoir mettre à niveau votre cluster d'administrateur, consultez la section Décalage entre les versions des clusters d'administrateur et d'utilisateurs.
Assurez-vous que le champ bundlepath dans le fichier de configuration du cluster d'administrateur correspond au chemin du groupe vers lequel vous souhaitez effectuer la mise à niveau.

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

Exécuter `gkectl upgrade admin`

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

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

Conditions requises pour la mise à niveau asynchrone:
- Compatible uniquement avec les clusters d'administrateur haute disponibilité de version 1.29 ou ultérieure.
- Controlplane V2 doit être activé sur tous les clusters d'utilisateur.
Synchrone:
Avec la variante synchrone, la commande gkectl upgrade admin renvoie des messages d'état au poste de travail administrateur à mesure que la mise à niveau progresse.

Mise à niveau asynchrone

Sur votre poste de travail administrateur, démarrez une mise à niveau asynchrone:
```
gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE \
    --async \
    FLAGS
```
Remplacez les éléments suivants :
- ADMIN_CLUSTER_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateur.
- ADMIN_CLUSTER_CONFIG_FILE: chemin d'accès au fichier de configuration du cluster d'administrateur.
- FLAGS : ensemble facultatif d'options Par exemple, vous pouvez inclure l'indicateur --skip-validation-infra pour ignorer la vérification de votre infrastructure vSphere.
La commande précédente est terminée et vous pouvez continuer à utiliser votre poste de travail administrateur pendant la mise à niveau.
Pour consulter l'état de la mise à niveau:
```
gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Le résultat affiche une valeur pour le cluster STATE. Si le cluster est toujours en cours de mise à niveau, la valeur de STATE est UPGRADING. Exemple :
```
NAME              STATE         AGE    VERSION
gke-admin-test    UPGRADING     9h     1.29.100-gke.248
```
Les valeurs possibles pour STATE sont RUNNING, UPGRADING, RECONCILING, ERROR et UNKNOWN.

Pour en savoir plus sur la progression de la mise à niveau et les événements du cluster:

gkectl describe admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Le résultat affiche la ressource personnalisée OnPremAdminCluster pour le cluster d'administrateur spécifié, qui inclut l'état, les conditions et les événements du cluster.

Nous enregistrons les événements de début et de fin de chaque phase critique de mise à niveau.

Exemple de résultat :

Events:
Type    Reason                             Age   From                             Message
----       ------                                  ----     ----                                -------
Normal  ControlPlaneUpgradeStarted         40m   onprem-admin-cluster-controller  Creating or updating admin cluster API Controller
Normal  ControlPlaneMachineUpgradeStarted  40m   onprem-admin-cluster-controller  Creating or updating control plane machine
Normal  StatusChanged                      40m   onprem-admin-cluster-controller  OnPremAdminCluster status changed:
- New ClusterState condition: UPGRADING
- New Ready condition: False, CreateOrUpdateControlPlaneMachine, Creating or updating control plane machine
Normal   StatusChanged      2m                onprem-admin-cluster-controller  OnPremAdminCluster status changed:
- New ClusterState condition: RUNNING
- New Ready condition: True, ClusterRunning, Cluster is running

Une fois la mise à niveau terminée, gkectl list admin affiche un STATUS RUNNING:
```
NAME              STATE         AGE    VERSION
gke-admin-test    RUNNING       9h     1.29.100-gke.248
```
En outre, une fois la mise à niveau terminée, gkectl describe admin affiche un champ Last GKE On Prem Version sous Status. Exemple :
```
Status:
  Cluster State:  RUNNING
  Last GKE On Prem Version:  1.29.0-gke.1
```

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 avant expiration, l'état du cluster passe de UPGRADING à ERROR, avec un événement indiquant que l'opération de mise à niveau a expiré. Notez que l'état ERROR signifie 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 continue de relancer l'opération. Lorsqu'une mise à niveau est bloquée ou échoue, vous pouvez exécuter gkectl diagnose pour rechercher les problèmes de cluster courants. En fonction du résultat, vous pouvez décider d'effectuer une correction manuelle ou de contacter l'assistance Google Cloud pour obtenir de l'aide.

Mise à niveau synchrone

Exécutez la commande ci-dessous.
```
gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE \
    FLAGS
```
Remplacez les éléments suivants :
- ADMIN_CLUSTER_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateur.
- ADMIN_CLUSTER_CONFIG_FILE : chemin d'accès au fichier de configuration du cluster d'administrateur.
- FLAGS : ensemble facultatif d'options Par exemple, vous pouvez inclure l'option --skip-validation-infra pour ignorer la vérification de votre infrastructure vSphere.
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 échecs ou utiliser l'option --skip-preflight-check-blocking avec la commande pour la débloquer.
Si vous effectuez une mise à niveau vers la version 1.14.0 ou une version ultérieure, un nouveau fichier kubeconfig est généré pour le cluster d'administrateur. Il écrase tout fichier existant. Pour afficher les détails du cluster dans le fichier, exécutez la commande suivante:
```
kubectl config view --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```

Supprimer le groupe complet

Si vous avez téléchargé un groupe complet et que vous avez réussi à exécuter les commandes gkectl prepare et gkectl upgrade admin, vous devez supprimer le groupe complet pour économiser de l'espace disque sur le poste de travail administrateur. Exécutez la commande suivante pour supprimer le bundle complet:

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

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

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

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

Procédez comme suit :

Vérifiez si le plan de contrôle administrateur est opérationnel avant de commencer la tentative de mise à niveau initiale. Consultez la page Diagnostiquer les problèmes de cluster. Comme indiqué dans cette rubrique, exécutez la commande gkectl diagnose cluster pour le cluster d'administrateur.
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 gkectl et les versions de cluster, exécutez cette commande. Utilisez l'indicateur --details/-d pour obtenir des informations plus détaillées.
```
gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
```
La sortie fournit des informations sur les versions de votre cluster.
En fonction du résultat obtenu, recherchez les problèmes suivants et corrigez-les si nécessaire.
- Si la version actuelle du cluster d'administrateur est antérieure à une version mineure antérieure à la version TARGET_VERSION, mettez à niveau tous vos clusters de sorte qu'ils soient en version mineure antérieure à la version TARGET_VERSION.
- Si la version de gkectl est antérieure à la version 1.11 et que vous souhaitez passer à la version 1.12.x, vous devrez effectuer plusieurs mises à niveau. Mettez à niveau une version mineure à la fois jusqu'à la version 1.11.x, puis suivez les instructions de cette rubrique.
- Si la version de gkectl est antérieure à TARGET_VERSION, mettez à niveau le poste de travail administrateur vers le fichier TARGET_VERSION.
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
```
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.

Remarque : Par défaut, le bundle normal, et non le bundle complet, est téléchargé. Le bundle complet contient toutes les images de conteneur et de VM, tandis que le bundle standard télécharge les images du conteneur et de la VM depuis Google Cloud Platform sur le poste de travail administrateur lors de l'installation. Pour utiliser le bundle complet, le chemin d'accès au bundle dans la commande d'installation est gke-onprem-vsphere-TARGET_VERSION-full.tgz.
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, GKE sur VMware crée automatiquement des règles d'anti-affinité VMware Distributed Resource Scheduler (DRS) pour les nœuds de votre cluster d'utilisateur. Ces règles sont ainsi réparties sur au moins trois hôtes physiques dans votre centre de données. Depuis la version 1.1.0-gke.6, cette fonctionnalité est automatiquement activée pour les nouveaux clusters et pour les clusters existants.

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

La fonctionnalité VMware DRS est activée. VMware DRS nécessite l'édition de licence vSphere Enterprise Plus. Pour en savoir plus sur l'activation de DRS, consultez la page Enabling VMware DRS in a cluster (Activer VMware DRS dans un cluster).
Le nom d'utilisateur vSphere fourni dans votre fichier de configuration des identifiants dispose de l'autorisation Host.Inventory.EditCluster.
Au moins trois hôtes physiques sont disponibles.

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

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

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 du cluster d'utilisateur, GKE sur 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.

Étapes suivantes

Documentation de référence de la gcloud CLI
Documentation de référence sur Terraform
- google_gkeonprem_vmware_cluster
- google_gkeonprem_vmware_node_pool

Mettre à niveau un cluster ou un pool de nœuds

Examiner vos règles de pare-feu

Exigences concernant l'API Google et IAM

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

Modifier la configuration avant ou après une mise à niveau

Mettre à niveau votre poste de travail administrateur.

gkeadm

Localiser les fichiers requis

Mettre à niveau

Géré par l'utilisateur

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

Mettre à niveau un cluster d'utilisateur

gkectl

Préparer la mise à niveau d'un cluster d'utilisateur

Exécuter des vérifications préliminaires

Exécuter gkectl upgrade cluster

Mise à niveau asynchrone

Résoudre les problèmes de mise à niveau asynchrone

Mise à niveau synchrone

Mettre à niveau des pools de nœuds supplémentaires

Reprendre une mise à niveau

Console

gcloud CLI

Mettre à niveau les pools de nœuds

Terraform

Mettre à niveau les pools de nœuds

Mettre à niveau le cluster d'administrateur

Avant de commencer :

Exécuter gkectl upgrade admin

Mise à niveau asynchrone

Résoudre les problèmes de mise à niveau asynchrone

Mise à niveau synchrone

Supprimer le groupe complet

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

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

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

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

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

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

Problèmes connus concernant les versions récentes

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

Perturbation des charges de travail comportant des PodDisruptionBudgets

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

Annexe

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

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

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

Étapes suivantes

Exécuter `gkectl upgrade cluster`

Exécuter `gkectl upgrade admin`