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

À partir de la version 1.29, Google Distributed Cloud permet au plan de contrôle d'un cluster d'utilisateur d'être jusqu'à deux versions mineures plus récentes que les pools de nœuds du cluster. Par exemple, si le plan de contrôle d'un cluster d'utilisateur est à la version 1.29, les pools de nœuds du cluster peuvent être à la version 1.16, 1.28 ou 1.29. De plus, Google Distributed Cloud vous permet d'ignorer une version mineure lors de la mise à niveau des pools de nœuds. À l'aide de l'exemple précédent, vous pouvez mettre à niveau les pools de nœuds de la version 1.16 directement vers la version 1.29 et ignorer la mise à niveau vers la version 1.28. L'ignorer lors de la mise à niveau des pools de nœuds est appelée mise à niveau avec version ignorée.

Les mises à niveau avec saut de version sont possibles pour les pools de nœuds Ubuntu et COS, mais pas pour les pools de nœuds Windows. De plus, cette fonctionnalité n'est pas disponible si vous avez activé les clusters avancés.

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

Cette page explique certains des avantages d'une mise à niveau en ignorant une version et explique comment effectuer une mise à niveau en ignorant une version en apportant des modifications au fichier de configuration et en exécutant gkectl upgrade cluster.

Cette page s'adresse aux administrateurs et opérateurs informatiques qui gèrent le cycle de vie de l'infrastructure technologique sous-jacente. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise. Cette page suppose que vous connaissez la planification et l'exécution des mises à niveau de Google Distributed Cloud, comme décrit ci-dessous:

Avantages des mises à niveau en ignorant les versions

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

Gérer plus facilement 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 dispose d'une fenêtre d'assistance d'un an. Pour que vos clusters restent dans la période de prise en charge, vous devez effectuer une mise à niveau vers une 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 défis lorsque vous avez besoin d'une longue période de validation pour vérifier une nouvelle version mineure et d'une courte période de maintenance pour mettre à niveau vos clusters vers la nouvelle version mineure. Pour surmonter ces défis, vous pouvez utiliser une mise à niveau avec saut de version, qui permet à vos clusters de rester dans la période de prise en charge 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 vers la version 1.15, vous ne la ferez 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

Passer 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 avec saut de version, vous n'avez pas besoin d'élargir votre fenêtre de maintenance. Passer une version mineure lors de la mise à niveau des pools de nœuds prend la même durée que la mise à niveau des pools de nœuds vers la version mineure suivante, car chaque nœud d'un pool de nœuds est vidé et recréé une fois. Par conséquent, une mise à niveau en ignorant une 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 présente les avantages suivants:

  • Mettre à jour 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 permettre de passer à une version compatible avec moins de mises à niveau.

  • Gagnez du temps: sauter une version mineure lors de la mise à niveau des pools de nœuds prend la même durée que de mettre à niveau les 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 deux fois des pools de nœuds. De même, avec une mise à niveau avec saut de version, vous n'avez qu'une seule fenêtre de validation, contre deux avec les mises à niveau standards.

  • Réduire les perturbations: les périodes plus longues entre les mises à niveau et le temps réduit 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 de niveau supérieur gkeOnPremVersion. 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.

Règles de version

Les règles de mise à niveau dépendent de la version mineure du cluster.

  • Pour les versions 1.30 et antérieures, la version mineure du cluster d'utilisateur doit être supérieure ou égale à celle du cluster d'administrateur. La version du correctif n'a pas d'importance. Par exemple, si un cluster d'utilisateur est en version 1.30.1, le cluster d'administrateur peut être mis à niveau vers une version de correctif ultérieure, telle que 1.30.3.

  • Pour les versions 1.31 et ultérieures, la version du cluster d'administrateur, y compris la version du correctif, doit être supérieure ou égale à celle du cluster d'utilisateur. Par exemple, si un cluster d'administrateur est en version 1.31.1, la version la plus récente à laquelle le cluster d'utilisateur peut être mis à niveau est la version 1.31.1.

Lorsque vous souhaitez mettre à niveau vos clusters vers la version 1.31, vous devez d'abord passer tous vos clusters à la version 1.30. Une fois tous les clusters à la version 1.30, mettez à niveau le cluster administrateur vers la version 1.31. Vous pouvez ensuite mettre à niveau les clusters d'utilisateur vers la même version de correctif 1.31 que le cluster d'administrateur.

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 de cluster vers laquelle vous effectuez la mise à niveau, appelée version cible:

1.31

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

  1. Si votre cluster administrateur est à la version 1.27, mettez-le à niveau vers la version 1.28.
  2. Si votre cluster 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 à la version source. La version intermédiaire 1.30 est nécessaire, car le plan de contrôle doit être mis à niveau d'une version mineure à la fois.
  4. Mettez à niveau le cluster administrateur de la version 1.29 vers la version intermédiaire 1.30.
  5. Mettez à niveau le cluster d'administration 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 antérieure.

Supposons que le plan de contrôle de votre cluster d'utilisateur et tous les pools de nœuds soient en version mineure 1.N. De manière générale, la mise à niveau de votre cluster de 1.N vers 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 à la version source. La version intermédiaire est nécessaire, car le plan de contrôle doit être mis à niveau d'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 une version

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. Veillez à examiner 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 kubernetesmetadata.publisher au compte de service de surveillance de la journalisation. Pour en savoir plus, consultez les Exigences concernant l'API Google et IAM.

Procéder à la mise à niveau

1.31

Utilisez cette séquence spéciale si le cluster utilisateur est en version 1.29, ce qui signifie que la version cible est 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 le gère peut être en version 1.27, 1.28 ou 1.29.

  1. Si votre cluster d'administrateur est en version 1.27, 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 le ou 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 en version 1.29, vous pouvez commencer la mise à niveau de la 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 intermédiaire 1.30. 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 indiquant que la mise à niveau a réussi s'affiche.

  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 à niveau votre poste de travail administrateur à nouveau, mais cette fois vers la version cible 1.31, TARGET_VERSION. Attendez qu'un message indiquant que la mise à niveau a réussi s'affiche.

  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. Apportez 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 du pool de nœuds dans nodePools[i].gkeOnPremVersion sur la version source, SOURCE_VERSION.

      Une fois votre fichier de configuration mis à jour, il devrait se présenter comme 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 dans le 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 dans le fichier de configuration du cluster d'administrateur sur la version cible 1.31 du bundle:

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

  10. Upgrade the admin cluster to the target 1.31 version:

    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. Apportez les modifications suivantes dans le fichier de configuration du cluster utilisateur:

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

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

      Une fois votre fichier de configuration mis à jour, il devrait se présenter comme 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 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
    Sélectionnez une version intermédiaire (1.N+1). INTERMEDIATE_VERSION
    Sélectionnez 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 indiquant que la mise à niveau a réussi s'affiche.

  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 à niveau votre poste de travail administrateur à nouveau, mais cette fois vers la version cible, TARGET_VERSION. Attendez qu'un message indiquant que la mise à niveau a réussi s'affiche.

  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. Apportez 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 du pool de nœuds dans nodePools[i].gkeOnPremVersion sur la version source, SOURCE_VERSION.

      Une fois votre fichier de configuration mis à jour, il devrait se présenter comme 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. Apportez les modifications suivantes dans le fichier de configuration du cluster utilisateur:

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

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

      Une fois votre fichier de configuration mis à jour, il devrait se présenter comme 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 aucun autre cluster utilisateur à mettre à niveau, supprimez les bundles de votre poste de travail administrateur pour économiser de l'espace:

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

Étape suivante