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

Dans la version 1.29 et les versions ultérieures, 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 lorsque vous mettez à niveau des pools de nœuds. Dans l'exemple précédent, vous pouvez mettre à niveau les pools de nœuds en version 1.16 directement vers la version 1.29 et ignorer la mise à niveau vers la version 1.28. Le fait d'ignorer une version mineure lors de la mise à niveau des pools de nœuds est appelé mise à niveau avec saut de version.

Cette page explique certains des avantages d'une mise à niveau sans version intermédiaire et fournit la procédure à suivre pour effectuer une mise à niveau sans version intermédiaire en modifiant les fichiers 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 Rôles utilisateur et tâches courantes de GKE. Cette page suppose que vous êtes déjà familiarisé avec la planification et l'exécution des mises à niveau de Google Distributed Cloud, comme décrit dans les sections suivantes :

Limites

Les mises à niveau sans passer par les versions intermédiaires présentent les limites suivantes :

  • Les mises à niveau de version sont acceptées pour les pools de nœuds Ubuntu et COS, mais pas pour 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érieure : cette fonctionnalité est disponible sur les clusters avancés.

  • En raison des contraintes de Kubernetes, le plan de contrôle d'un cluster d'utilisateur doit être mis à niveau d'une version mineure à la fois. Toutefois, notez 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 vos charges de travail s'exécutent.

Avantages des mises à niveau sans passer par une version intermédiaire

Cette section décrit certains des avantages de l'utilisation des mises à niveau sans version intermédiaire.

Il est plus facile de conserver 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 de compatibilité d'un an. Pour que vos clusters restent dans la période d'assistance, 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'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 difficultés, vous pouvez utiliser une mise à niveau avec saut de version, qui permet à vos clusters de rester dans la fenêtre compatible en mettant à niveau un cluster tous les huit mois au lieu de tous les quatre mois. Le tableau suivant montre comment le fait d'ignorer la mise à niveau vers la version 1.15 signifie que vous ne passerez à la version supérieure qu'au bout de 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

Si vous ignorez une version mineure lors de la mise à niveau de vos pools de nœuds, vous réduisez le nombre de mises à niveau nécessaires 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 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 sans version intermédiaire permet de gagner du temps et de réduire les perturbations de la charge de travail.

Résumé

En résumé, une mise à niveau sans passer par les versions intermédiaires présente les avantages suivants :

  • Mettez vos clusters à 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, vous pouvez, selon la version du cluster, ignorer une version mineure lors de la mise à niveau des pools de nœuds pour que vos clusters passent à 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 sans version intermédiaire 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 en sautant une version, vous ne disposez que d'une seule période de validation, contre deux avec les mises à niveau régulières.

  • Réduisez les perturbations : des intervalles plus longs entre les mises à niveau et moins de temps passé à mettre à niveau et à valider 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.

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 supérieure, telle que la version 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 maximale vers 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 mettre à niveau tous vos clusters vers la version 1.30. Une fois tous les clusters à la version 1.30, mettez à niveau le cluster d'administrateur vers la version 1.31. Vous pourrez ensuite mettre à niveau les clusters d'utilisateur vers la même version corrective 1.31 que le cluster d'administrateur.

Séquence de mise à niveau avec saut de version

L'ordre dans lequel vous mettez à niveau les 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 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 1.N vers 1.N+2 à l'aide d'une mise à niveau sans version intermédiaire 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 depuis 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.
  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 à la 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 le gère peut être en version 1.27, 1.28 ou 1.29.

  1. Si votre cluster d'administrateur est à la version 1.27, 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 dans 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 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 et les pools de nœuds du cluster d'utilisateur vers la version cible 1.31.

1.30 et versions antérieures

Utilisez cette séquence si la version cible est 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 à la 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 sans version intermédiaire 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 de mise à niveau en ignorant une version.

Avant de commencer

  1. Assurez-vous que la version actuelle (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 effectuer la mise à niveau 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 de surveillance de la journalisation. Pour en savoir plus, consultez Exigences concernant les API Google et IAM.

Procéder à la mise à niveau

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 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 les étapes 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 les étapes 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'utilisateur sont en version 1.29, vous pouvez commencer 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 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 indique que la mise à niveau a réussi.

  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, mais cette fois vers la version 1.31 cible, TARGET_VERSION. Attendez qu'un message indique que la mise à niveau a réussi.

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

      Une fois votre fichier de configuration mis à jour, il devrait 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 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
    Choisissez une version intermédiaire (1.N+1). INTERMEDIATE_VERSION
    Choisissez la version cible (1.N+2). Sélectionnez le correctif recommandé à partir de 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 réussi.

  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, mais cette fois vers la version cible, TARGET_VERSION. Attendez qu'un message indique que la mise à niveau a réussi.

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

      Une fois votre fichier de configuration mis à jour, il devrait 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 économiser de l'espace :

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

Étapes suivantes