Ignorer une version lors de la mise à niveau des pools de nœuds

Les mises à niveau avec saut de version vous permettent de sauter une version mineure lorsque vous mettez à niveau des pools de nœuds de calcul après avoir mis à niveau le plan de contrôle du cluster d'utilisateur. Cela réduit le nombre de cycles de drainage et de redémarrage des nœuds. Par exemple, si un pool de nœuds de calcul est en version 1.29, vous pouvez mettre à niveau le plan de contrôle du cluster d'utilisateur vers la version 1.30, puis vers la version 1.31, puis mettre à niveau le pool de nœuds de calcul directement de la version 1.29 vers la version 1.31. Cette fonctionnalité est compatible avec les clusters avancés et non avancés, à l'exception des clusters avancés de la version 1.31 et des versions de Google Distributed Cloud (logiciel uniquement) pour VMware antérieures à la version 1.28.

Avant de commencer, assurez-vous de bien connaître les sections Présentation de la mise à niveau, Règles de version pour les mises à niveau, Bonnes pratiques de mise à niveau et Mettre à niveau un cluster.

Limites

Voici les limites des mises à niveau avec saut de version :

  • Les mises à niveau avec saut de version sont compatibles avec les pools de nœuds Ubuntu et Container-Optimized OS, mais pas avec les pools de nœuds Windows.

  • Version 1.31 : cette fonctionnalité n'est pas disponible sur les clusters avancés.

  • Version 1.32 et ultérieures : cette fonctionnalité est disponible sur les clusters avancés.

  • Les pools de nœuds d'équilibreur de charge (pools de nœuds avec enableLoadBalancer: true) ne sont pas compatibles avec les mises à niveau avec saut de version ni avec le décalage entre les versions. La version d'un pool de nœuds d'équilibreur de charge doit correspondre à la version du cluster.

  • En raison des contraintes de Kubernetes, le plan de contrôle d'un cluster d'utilisateur doit être mis à niveau une version mineure à la fois. Notez toutefois que la mise à niveau du plan de contrôle prend beaucoup moins de temps et est moins risquée que la mise à niveau des pools de nœuds sur lesquels vos charges de travail s'exécutent.

Avantages des mises à niveau avec saut de version

Cette section décrit certains des avantages des mises à niveau avec saut de version.

Il est plus facile de maintenir vos clusters dans une version compatible.

Une nouvelle version mineure de Google Distributed Cloud est publiée tous les quatre mois, et chaque version mineure bénéficie d'une période d'assistance d'un an. Pour que vos clusters restent dans la période de compatibilité, vous devez effectuer une mise à niveau de version mineure environ tous les quatre mois, comme indiqué ci-dessous :

Déc.

Jan.

Févr.

Mars

Avr.

Mai

Juin

Juil.

Août

Sept.

Oct.

Nov.

Déc.

Jan.

Févr.

Mars

Avr.

Mai

Juin

Juil.

Août

Sept.

Oct.

Nov.

Déc.

Jan.

Févr.

Mars
1,14 Changer de formule
1.15 Changer de formule
1.16 Changer de formule
1.28 Changer de formule
1,29 Changer de formule

Cette exigence pose des problèmes lorsque vous avez besoin d'un intervalle de validation long pour vérifier une nouvelle version mineure et d'un intervalle de maintenance court pour mettre à niveau vos clusters vers la nouvelle version mineure. Pour surmonter ces difficultés, vous pouvez utiliser une mise à niveau avec saut de version, qui permet à vos clusters de rester dans la période de compatibilité en mettant à niveau un cluster tous les huit mois au lieu de tous les quatre mois. Le tableau suivant montre que si vous ignorez la mise à niveau pour la version 1.15, vous ne procéderez à la mise à niveau qu'après huit mois au lieu de quatre.

Déc.

Jan.

Févr.

Mars

Avr.

Mai

Juin

Juil.

Août

Sept.

Oct.

Nov.

Déc.

Jan.

Févr.

Mars

Avr.

Mai

Juin

Juil.

Août

Sept.

Oct.

Nov.

Déc.

Jan.

Févr.

Mars
1,14 Changer de formule
1.15
1.16 Changer de formule
1.28
1,29

Ignorer une version mineure lors de la mise à niveau de vos pools de nœuds réduit le nombre de mises à niveau requises pour rester sur une version compatible. De plus, vous n'avez pas besoin de qualifier la version mineure ignorée, car elle n'est utilisée que temporairement par le plan de contrôle.

Intervalle de maintenance plus court

Avec une mise à niveau sans version intermédiaire, vous n'avez pas besoin d'élargir votre intervalle de maintenance. Ignorer une version mineure lors de la mise à niveau des pools de nœuds prend autant de temps que de mettre à niveau les pools de nœuds vers la version mineure suivante, car chaque nœud d'un pool de nœuds est drainé et recréé une fois. Par conséquent, une mise à niveau avec saut de version permet de gagner du temps et de réduire les perturbations de la charge de travail.

Résumé

En résumé, une mise à niveau avec saut de version offre les avantages suivants :

  • Mettez à niveau les clusters vers une version compatible : Google Distributed Cloud est compatible avec les trois versions mineures les plus récentes. Si vos clusters utilisent une version non compatible, selon la version du cluster, ignorer une version mineure lors de la mise à niveau des pools de nœuds peut vous permettre de passer à une version compatible avec moins de mises à niveau.

  • Gagnez du temps : ignorer une version mineure lors de la mise à niveau des pools de nœuds prend le même temps que la mise à niveau des pools de nœuds vers la version mineure suivante. Par conséquent, une mise à niveau avec saut de version prend environ la moitié du temps nécessaire pour mettre à niveau les pools de nœuds deux fois. De même, avec une mise à niveau avec saut de version, vous ne disposez que d'une seule fenêtre de validation, contre deux avec les mises à niveau standards.

  • Réduire les perturbations : des intervalles plus longs entre les mises à niveau et moins de temps consacré à la mise à niveau et à la validation signifient que vos charges de travail s'exécutent plus longtemps avec moins de perturbations.

Contrôler les versions du plan de contrôle et du pool de nœuds lors d'une mise à niveau

Dans le fichier de configuration du cluster d'utilisateur, le champ nodePools[i].gkeOnPremVersion permet à un pool de nœuds spécifique d'utiliser une version différente de celle du champ gkeOnPremVersion de niveau supérieur. En modifiant la valeur du champ nodePools[i].gkeOnPremVersion, vous contrôlez le moment où un pool de nœuds est mis à niveau lorsque vous exécutez gkectl upgrade cluster. Si vous n'incluez pas nodePools[i].gkeOnPremVersion dans le fichier de configuration ou si vous définissez le champ sur une chaîne vide, les pools de nœuds sont mis à niveau vers la même version cible que celle que vous spécifiez dans gkeOnPremVersion.

Séquence de mise à niveau avec saut de version

La séquence de mise à niveau des clusters d'administrateur et d'utilisateur dépend de la version du cluster vers laquelle vous effectuez la mise à niveau, appelée version cible :

1.32 et versions ultérieures

Utilisez cette séquence si la version cible est la version 1.32 ou une version ultérieure. Supposons que le plan de contrôle de votre cluster d'utilisateur et tous les pools de nœuds soient à la version mineure 1.N. De manière générale, la mise à niveau de votre cluster de la version 1.N vers la version 1.N+2 à l'aide d'une mise à niveau avec saut de version fonctionne comme suit :

  1. Mettez à niveau le cluster d'administrateur de la version 1.N vers une version intermédiaire, 1.N+1.
  2. Mettez à niveau le cluster d'administrateur de la version intermédiaire 1.N+1 vers la version cible 1.N+2.
  3. Mettez à niveau uniquement le plan de contrôle du cluster d'utilisateur de la version source, 1.N, vers une version intermédiaire, 1.N+1. Laissez les pools de nœuds sur la version source. La version intermédiaire est nécessaire, car le plan de contrôle doit être mis à niveau une version mineure à la fois.
  4. Mettez à niveau le plan de contrôle et les pools de nœuds vers la version cible, 1.N+2.

1.31

Utilisez cette séquence spéciale si le cluster d'utilisateur est en version 1.29, ce qui signifie que la version cible est la version 1.31. Lorsqu'un cluster d'utilisateur est en version 1.29, un cluster d'administrateur qui gère le cluster d'utilisateur peut être en version 1.16, 1.28 ou 1.29.

  1. Si votre cluster d'administrateur est en version 1.16, mettez-le à niveau vers la version 1.28.
  2. Si votre cluster d'administrateur est en version 1.28, mettez-le à niveau vers la version 1.29.
  3. Mettez à niveau uniquement le plan de contrôle du cluster d'utilisateur de la version source, 1.29, vers une version intermédiaire, 1.30. Laissez les pools de nœuds sur la version source. La version intermédiaire 1.30 est nécessaire, car le plan de contrôle doit être mis à niveau une version mineure à la fois.
  4. Mettez à niveau le cluster d'administrateur de la version 1.29 vers la version intermédiaire 1.30.
  5. Mettez à niveau le cluster d'administrateur vers la version cible, 1.31.
  6. Mettez à niveau le plan de contrôle du cluster d'utilisateur et les pools de nœuds vers la version cible, 1.31.

1.30 et versions antérieures

Utilisez cette séquence si la version cible est la version 1.30 ou une version antérieure.

Supposons que le plan de contrôle de votre cluster d'utilisateur et tous les pools de nœuds soient à la version mineure 1.N. De manière générale, la mise à niveau de votre cluster de la version 1.N vers la version 1.N+2 à l'aide d'une mise à niveau avec saut de version fonctionne comme suit :

  1. Mettez à niveau uniquement le plan de contrôle de la version source, 1.N, vers une version intermédiaire 1.N+1. Laissez les pools de nœuds sur la version source. La version intermédiaire est nécessaire, car le plan de contrôle doit être mis à niveau une version mineure à la fois.
  2. Mettez à niveau le plan de contrôle et les pools de nœuds vers la version cible 1.N+2.

Effectuer une mise à niveau en ignorant des versions

Cette section décrit la procédure à suivre pour effectuer une mise à niveau en ignorant une version.

Avant de commencer

  1. Assurez-vous que la version actuelle (la version source) du cluster est la version 1.16 ou ultérieure. Veillez à vérifier la version du plan de contrôle (gkeOnPremVersion) et de tous les pools de nœuds (nodePools[i].gkeOnPremVersion).

  2. Dans les versions 1.29 et ultérieures, les vérifications préliminaires côté serveur sont activées par défaut. Assurez-vous de vérifier vos règles de pare-feu pour apporter les modifications nécessaires.

  3. Pour passer à la version 1.28 ou ultérieure, vous devez activer kubernetesmetadata.googleapis.com et attribuer le rôle IAM (Identity and Access Management) kubernetesmetadata.publisher au compte de service de surveillance de la journalisation. Pour en savoir plus, consultez Exigences concernant les API Google et IAM.

Procéder à la mise à niveau

1.32 et versions ultérieures

Utilisez cette séquence si la version cible est la version 1.32 ou une version ultérieure.

Avant de commencer, assurez-vous que votre cluster d'administrateur est au moins à la même version mineure (1.N) que votre cluster d'utilisateur. Si votre cluster d'utilisateur est en version 1.30 et que votre cluster d'administrateur est en version 1.28 ou 1.29, mettez à niveau votre cluster d'administrateur d'une version mineure à la fois jusqu'à ce qu'il atteigne la version 1.30. Si vous avez déjà mis à niveau votre cluster d'administrateur vers la version 1.N+1 ou 1.N+2 (par exemple, lors de la mise à niveau d'un autre cluster d'utilisateur), ignorez les étapes de mise à niveau du cluster d'administrateur.

  1. Définissez la version source (1.N), la version intermédiaire (1.N+1) et la version cible (1.N+2) dans les variables d'espace réservé suivantes. Spécifiez les numéros de version complets au format X.Y.Z-gke.N, par exemple 1.34.1000-gke.111 :

    Description Version
    Obtenez la version actuelle du cluster d'utilisateur. Il s'agit de la version source (1.N). SOURCE_VERSION
    Sélectionnez une version intermédiaire (1.N+1). INTERMEDIATE_VERSION
    Sélectionnez le correctif recommandé dans la version mineure cible (1.N+2). TARGET_VERSION

  2. Mettez à niveau le poste de travail administrateur et le cluster d'administrateur de la version source (1.N) vers la version intermédiaire (1.N+1) :

    1. Mettez à niveau votre poste de travail administrateur vers la version intermédiaire, INTERMEDIATE_VERSION, et attendez que la mise à niveau se termine.

    2. Importez les images de l'OS du bundle intermédiaire dans vSphere :

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

      Remplacez ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig de votre cluster d'administrateur.

    3. Définissez le champ bundlePath du fichier de configuration du cluster d'administrateur sur le bundle intermédiaire :

      bundlePath: "/var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz"

    4. Mettez à niveau le cluster d'administrateur vers la version intermédiaire :

      gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE

      Remplacez ADMIN_CLUSTER_CONFIG_FILE par le chemin d'accès de votre fichier de configuration de cluster d'administrateur.

  3. Mettez à niveau le poste de travail administrateur et le cluster d'administrateur de la version intermédiaire (1.N+1) vers la version cible (1.N+2) :

    1. Mettez à niveau votre poste de travail administrateur vers la version cible, TARGET_VERSION, et attendez que la mise à niveau se termine.

    2. Importez les images de l'OS du bundle cible dans vSphere :

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

    3. Définissez le champ bundlePath dans le fichier de configuration du cluster d'administrateur sur le bundle cible :

      bundlePath: "/var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz"

    4. Mettez à niveau le cluster d'administrateur vers la version cible :

      gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE

  4. Mettez à niveau uniquement le plan de contrôle du cluster d'utilisateur de la version source (1.N) vers la version intermédiaire (1.N+1) :

    1. Effectuez les modifications suivantes dans le fichier de configuration du cluster d'utilisateur :

      • Définissez le champ gkeOnPremVersion sur la version intermédiaire, INTERMEDIATE_VERSION.

      • Définissez toutes les versions de pool de nœuds de calcul dans nodePools[i].gkeOnPremVersion sur la version source, SOURCE_VERSION. Si votre cluster comporte des pools de nœuds d'équilibreur de charge (enableLoadBalancer: true), définissez leur champ gkeOnPremVersion sur une chaîne vide ("") afin qu'ils soient mis à niveau avec le plan de contrôle.

      Une fois que vous avez mis à jour votre fichier de configuration, il ressemble à l'exemple suivant :

      gkeOnPremVersion: INTERMEDIATE_VERSION
# Omitted fields
nodePools:
- name: pool-1
  gkeOnPremVersion: SOURCE_VERSION
  # Omitted fields
- name: pool-2
  gkeOnPremVersion: SOURCE_VERSION
  # Omitted fields

    2. Mettez à niveau le plan de contrôle du cluster d'utilisateur :

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

      Remplacez USER_CLUSTER_CONFIG_FILE par le chemin d'accès au fichier de configuration de votre cluster d'utilisateur.

  5. Mettez à niveau le plan de contrôle du cluster d'utilisateur et les pools de nœuds de calcul vers la version cible (1.N+2) :

    1. Effectuez les modifications suivantes dans le fichier de configuration du cluster d'utilisateur :

      • Définissez le champ gkeOnPremVersion sur la version cible, TARGET_VERSION.

      • Définissez nodePools[i].gkeOnPremVersion pour chaque pool de nœuds sur une chaîne vide ("").

      Une fois que vous avez mis à jour votre fichier de configuration, il ressemble à l'exemple suivant :

      gkeOnPremVersion: TARGET_VERSION
# Omitted fields
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  # Omitted fields
- name: pool-2
  gkeOnPremVersion: ""
  # Omitted fields

    2. Mettez à niveau le plan de contrôle et les pools de nœuds du cluster d'utilisateur :

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

1.31

Utilisez cette séquence spéciale si le cluster d'utilisateur est en version 1.29, ce qui signifie que la version cible est la version 1.31. Cette séquence est nécessaire, car les règles de version ont changé dans la version 1.31.

Lorsqu'un cluster d'utilisateur est en version 1.29, un cluster d'administrateur qui gère le cluster d'utilisateur peut être en version 1.16, 1.28 ou 1.29.

  1. Si votre cluster d'administrateur est en version 1.16, suivez la procédure pour mettre à niveau votre poste de travail administrateur et mettre à niveau votre cluster d'administrateur vers la version 1.28.

  2. Si votre cluster d'administrateur est en version 1.28, suivez la procédure pour mettre à niveau votre poste de travail administrateur et mettre à niveau votre cluster d'administrateur vers la version 1.29.

  3. Pour économiser de l'espace sur votre poste de travail administrateur, supprimez les bundles téléchargés :

    rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz

Lorsque le cluster d'administrateur et tous les clusters d'utilisateurs sont à la version 1.29, vous pouvez lancer la mise à niveau en ignorant une version.

  1. Définissez la version source (1.29), une version intermédiaire (1.30) et la version cible (1.31) dans les variables d'espace réservé suivantes. Toutes les versions doivent être le numéro de version complet au format x.y.z-gke.N, par exemple 1.29.700-gke.110.

    Version
    Obtenez la version 1.29 du cluster d'utilisateur actuel. Il s'agit de la version source. SOURCE_VERSION
    Choisissez une version 1.30 intermédiaire. INTERMEDIATE_VERSION
    Sélectionnez la version cible 1.31. Sélectionnez le correctif recommandé de la version mineure 1.31. TARGET_VERSION

  2. Mettez à niveau votre poste de travail administrateur vers la version intermédiaire 1.30, INTERMEDIATE_VERSION. Attendez qu'un message indique que la mise à niveau a bien été effectuée.

  3. Installez le bundle correspondant :

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

  4. Mettez à nouveau à niveau votre poste de travail administrateur, mais cette fois vers la version cible 1.31, TARGET_VERSION. Attendez qu'un message indique que la mise à niveau a bien été effectuée.

  5. Installez le bundle correspondant :

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

  6. Mettez à niveau uniquement le plan de contrôle du cluster d'utilisateur vers la version intermédiaire comme suit :

    1. Effectuez les modifications suivantes dans le fichier de configuration du cluster d'utilisateur :

      • Définissez le champ gkeOnPremVersion sur la version intermédiaire, INTERMEDIATE_VERSION.

      • Définissez toutes les versions de pool de nœuds dans nodePools[i].gkeOnPremVersion sur la version source, SOURCE_VERSION.

      Après avoir mis à jour votre fichier de configuration, il doit ressembler à ce qui suit :

      gkeOnPremVersion: INTERMEDIATE_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: SOURCE_VERSION
  ...
- name: pool-2
  gkeOnPremVersion: SOURCE_VERSION
  ...

    2. Mettez à niveau le plan de contrôle :

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

      Remplacez USER_CLUSTER_CONFIG par le chemin d'accès au fichier de configuration de votre cluster d'utilisateur.

  7. Définissez le champ bundlePath du fichier de configuration du cluster d'administrateur sur la version intermédiaire 1.30 du bundle :

    bundlePath: "/var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz"

  8. Mettez à niveau le cluster d'administrateur vers la version intermédiaire 1.30 :

    gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE

  9. Définissez le champ bundlePath du fichier de configuration du cluster d'administrateur sur la version 1.31 cible du bundle :

    bundlePath: "/var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz"

  10. Mettez à niveau le cluster d'administrateur vers la version 1.31 cible :

    gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE

  11. Mettez à niveau le plan de contrôle et les pools de nœuds vers la version cible comme suit :

    1. Effectuez les modifications suivantes dans le fichier de configuration du cluster d'utilisateur :

      • Définissez le champ gkeOnPremVersion sur la version cible, TARGET_VERSION.

      • Définissez tous les nodePools[i].gkeOnPremVersion sur une chaîne vide.

      Après avoir mis à jour votre fichier de configuration, il doit ressembler à ce qui suit :

      gkeOnPremVersion: TARGET_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  ...
- name: pool-2
  gkeOnPremVersion: ""
  ...

    2. Mettez à niveau le plan de contrôle et les pools de nœuds :

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

1.30 et versions antérieures

Utilisez cette séquence si la version cible est la version 1.30 ou une version antérieure.

  1. Définissez la version source (1.N), la version intermédiaire (1.N+1) et la version cible (1.N+2) dans les variables d'espace réservé suivantes. Toutes les versions doivent être le numéro de version complet au format x.y.z-gke.N, par exemple 1.16.11-gke.25.

    Version
    Obtenez la version actuelle du cluster. Il s'agit de la version source (1.N). SOURCE_VERSION
    Choisissez une version intermédiaire (1.N+1). INTERMEDIATE_VERSION
    Choisissez la version cible (1.N+2). Sélectionnez le correctif recommandé dans la version mineure cible. TARGET_VERSION

  2. Mettez à niveau votre poste de travail administrateur vers la version intermédiaire, INTERMEDIATE_VERSION. Attendez qu'un message indique que la mise à niveau a bien été effectuée.

  3. Installez le bundle correspondant :

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

    Remplacez ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig de votre cluster d'administrateur.

  4. Mettez à nouveau à niveau votre poste de travail administrateur, mais cette fois vers la version cible, TARGET_VERSION. Attendez qu'un message indique que la mise à niveau a bien été effectuée.

  5. Installez le bundle correspondant :

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

  6. Mettez à niveau uniquement le plan de contrôle vers la version intermédiaire comme suit :

    1. Effectuez les modifications suivantes dans le fichier de configuration du cluster d'utilisateur :

      • Définissez le champ gkeOnPremVersion sur la version intermédiaire, INTERMEDIATE_VERSION.

      • Définissez toutes les versions de pool de nœuds dans nodePools[i].gkeOnPremVersion sur la version source, SOURCE_VERSION.

      Après avoir mis à jour votre fichier de configuration, il doit ressembler à ce qui suit :

      gkeOnPremVersion: INTERMEDIATE_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: SOURCE_VERSION
  ...
- name: pool-2
  gkeOnPremVersion: SOURCE_VERSION
  ...

    2. Mettez à niveau le plan de contrôle :

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

      Remplacez USER_CLUSTER_CONFIG par le chemin d'accès au fichier de configuration de votre cluster d'utilisateur.

  7. Mettez à niveau le plan de contrôle et les pools de nœuds vers la version cible comme suit :

    1. Effectuez les modifications suivantes dans le fichier de configuration du cluster d'utilisateur :

      • Définissez le champ gkeOnPremVersion sur la version cible, TARGET_VERSION.

      • Définissez tous les nodePools[i].gkeOnPremVersion sur une chaîne vide.

      Après avoir mis à jour votre fichier de configuration, il doit ressembler à ce qui suit :

      gkeOnPremVersion: TARGET_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  ...
- name: pool-2
  gkeOnPremVersion: ""
  ...

    2. Mettez à niveau le plan de contrôle et les pools de nœuds :

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

Si vous n'avez pas d'autres clusters d'utilisateur à mettre à niveau, supprimez les bundles de votre poste de travail administrateur pour libérer de l'espace :

rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz

Étapes suivantes