Présentation de la mise à jour

Cette page présente le processus de mise à niveau et des informations sur les écarts de version pour Google Distributed Cloud (logiciel uniquement) pour les clusters VMware. Ces informations devraient vous aider à planifier l'ordre dans lequel vous mettez à niveau les clusters dans un environnement multicluster. Pour en savoir plus sur la planification, y compris une checklist pour vous aider à planifier la mise à niveau, consultez les bonnes pratiques de mise à niveau.

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.

Différences entre les clusters avancés

Lorsque les clusters avancés sont activés, il existe des différences avec les mises à niveau, en particulier dans la version preview des clusters avancés de la version 1.31. Pour voir les différences de mise à niveau, recherchez le mot advanced dans ce document. Pour obtenir un tableau de toutes les différences, consultez la section Différences lors de l'exécution de clusters avancés.

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

Règles de version pour gkectl

La version de gkectl que vous pouvez utiliser pour la mise à niveau dépend de la version du cluster cible (c'est-à-dire la version du cluster vers laquelle vous effectuez la mise à niveau). En règle générale, vous utilisez la même version d'gkectl que la version cible du cluster. Les règles suivantes sont appliquées lors de la mise à niveau:

• La version gkectl ne peut pas être une version mineure inférieure à la version mineure cible du cluster. Par exemple, si vous mettez à niveau un cluster 1.29 vers la version 1.30, vous ne pouvez pas utiliser gkectl 1.29, car cette version est inférieure à la version cible du cluster. Les versions de correctif n'ont pas d'importance. Par exemple, vous pouvez utiliser la version gkectl 1.29.0-gke.1456 pour passer à une version de correctif supérieure, telle que 1.29.1000-gke.94.

• La version gkectl ne peut pas être supérieure de plus de deux versions mineures à la version actuelle du cluster. Par exemple, si vous mettez à niveau un cluster de version 1.28 vers la version 1.29, la version gkectl peut être 1.29 ou 1.30. Toutefois, vous ne pouvez pas utiliser la version 1.31 de gkectl, car elle est trois versions mineures plus récente que la version du cluster.

Si nécessaire, consultez Télécharger gkectl pour obtenir une version compatible de gkectl.

Pour en savoir plus sur les décalages de version entre les clusters d'administrateur et les clusters d'utilisateur, consultez la section Décalage de version de ce document.

Séquence de mise à niveau

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:

Mises à niveau du cluster d'administrateur

Mises à niveau de clusters d'utilisateurs

Lors de la mise à niveau des clusters d'utilisateur, vous pouvez choisir de mettre à niveau le cluster d'utilisateur dans son ensemble (ce qui signifie que vous pouvez mettre à niveau le plan de contrôle et tous les pools de nœuds du cluster), ou mettre à niveau le plan de contrôle du cluster d'utilisateur et laisser les pools de nœuds dans la version actuelle. L'approche que vous adoptez dépend de plusieurs facteurs, tels que:

• Environnement (production ou hors production) dans lequel se trouve le cluster.
• Durée de votre intervalle de maintenance.
• Version du cluster d'utilisateur.

Par exemple, dans un environnement de développement, vous pouvez simplifier le processus et mettre à niveau à la fois le plan de contrôle du cluster d'utilisateur et tous les pools de nœuds. Toutefois, dans un environnement de production avec une courte période de maintenance, vous pouvez choisir de ne mettre à niveau que le plan de contrôle, car cela prend moins de temps. Avec les plans de contrôle haute disponibilité, la mise à niveau du plan de contrôle ne devrait pas perturber les charges de travail des utilisateurs. Lorsque le plan de contrôle est en version 1.28 ou ultérieure, vous pouvez ignorer une version mineure lors de la mise à niveau des pools de nœuds.

• Version 1.31: non disponible sur les clusters avancés.
• Version 1.32 et ultérieure: disponible sur les clusters avancés.

Mettre à niveau de manière sélective les pools de nœuds

Dans certains cas, vous pouvez souhaiter mettre à niveau certains, mais pas tous les pools de nœuds d'un cluster d'utilisateur. Par exemple, après avoir mis à niveau le plan de contrôle, vous pouvez mettre à niveau un pool de nœuds qui enregistre un trafic léger ou qui exécute vos charges de travail les moins critiques. Une fois que vous êtes convaincu que vos charges de travail s'exécutent correctement sur la nouvelle version, vous pouvez mettre à niveau d'autres pools de nœuds, jusqu'à ce que tous les pools de nœuds soient mis à niveau. Pour en savoir plus, consultez Mettre à niveau les pools de nœuds.

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

Si vos clusters sont en version 1.16 ou ultérieure, vous pouvez ignorer une version mineure lors de la mise à niveau des pools de nœuds. Effectuer une mise à niveau en ignorant une version réduit de moitié le temps qu'il faudrait pour mettre à niveau deux versions de pool de nœuds de manière séquentielle. De plus, les mises à niveau avec saut de version vous permettent d'augmenter le délai entre les mises à niveau nécessaires pour rester sur une version compatible. Réduire le nombre de mises à niveau réduit les perturbations de la charge de travail et le temps de vérification. Pour en savoir plus, consultez la section Ignorer une version lors de la mise à niveau des pools de nœuds.

Choisir un outil pour mettre à niveau des clusters d'utilisateurs

Google Distributed Cloud vous propose un choix d'outils pour mettre à niveau les clusters d'utilisateurs.

• L'outil de ligne de commande gkectl, que vous exécutez sur votre poste de travail administrateur. Avant la mise à niveau, vous devez modifier le fichier de configuration de votre cluster d'utilisateur pour définir la version cible du plan de contrôle du cluster et, éventuellement, des pools de nœuds. Vous spécifiez ce fichier sur la ligne de commande pour gkectl.

  Si vous avez activé le cluster avancé, vous devez utiliser gkectl pour la mise à niveau. Les clients de l'API GKE On-Prem ne sont pas compatibles avec les clusters avancés.

• La Google Cloud console, Google Cloud CLI ou Terraform, que vous pouvez exécuter à partir de n'importe quel ordinateur disposant d'une connectivité réseau à l'API GKE On-Prem. Ces outils standards sont des clients de l'API GKE On-Prem, qui s'exécute sur l'infrastructure Google Cloud .

  • Vous ne pouvez utiliser Terraform pour la mise à niveau que si vous avez créé le cluster utilisateur à l'aide de Terraform.

  • Si votre cluster d'utilisateur a été créé à l'aide de gkectl, il doit être enregistré dans l'API GKE On-Prem pour utiliser la console ou gcloud CLI pour la mise à niveau. Dans les versions 1.16 et ultérieures, les clusters créés à l'aide de gkectl sont enregistrés dans l'API GKE On-Prem par défaut. Pour les clusters créés dans des versions antérieures, vous pouvez enregistrer le cluster après sa création.

    Même si vous décidez d'utiliser gkectl pour la mise à niveau, vous pouvez enregistrer le cluster dans l'API GKE On-Prem pour obtenir des informations sur les clusters à l'aide de la console ou de gcloud CLI.

L'outil que vous utilisez dépend de la manière dont vous envisagez de mettre à niveau les clusters d'utilisateurs:

• Mettre à niveau le cluster dans son ensemble : vous pouvez utiliser gkectl, la console Google Cloud , Google Cloud CLI ou Terraform pour mettre à niveau un cluster d'utilisateur (le plan de contrôle et tous les pools de nœuds).

• Mettre à niveau uniquement le plan de contrôle : vous pouvez utiliser gkectl, la gcloud CLI ou Terraform pour mettre à niveau le plan de contrôle d'un cluster d'utilisateur séparément des pools de nœuds. La console ne permet pas de mettre à niveau uniquement le plan de contrôle.

• Mettre à niveau sélectivement des pools de nœuds après la mise à niveau du plan de contrôle : vous pouvez utiliser gkectl, la gcloud CLI ou Terraform pour mettre à niveau des pools de nœuds spécifiques après la mise à niveau du plan de contrôle.

• Mettre à niveau le plan de contrôle et un ou plusieurs pools de nœuds en même temps : seul gkectl est compatible avec ce cas d'utilisation.

Décalage entre les versions

Le décalage entre les versions est la différence de versions mineures entre un cluster d'administrateur et ses clusters d'utilisateur gérés. Dans les sections suivantes, la version du cluster d'utilisateur fait référence à la version du plan de contrôle et des pools de nœuds, dans leur ensemble.

De plus, le décalage de version correspond à la différence de versions mineures entre le plan de contrôle d'un cluster d'utilisateur et les pools de nœuds du cluster d'utilisateur.

Dans un environnement multicluster, comprendre le décalage de version compatible et les règles de version pour les mises à niveau peut vous aider à planifier l'ordre dans lequel vous mettez à niveau les clusters.

Différence de version entre les clusters d'administrateur et d'utilisateur

Un cluster d'administrateur peut gérer des clusters d'utilisateur avec différentes versions. Cette fonctionnalité vous permet de mettre à niveau une flotte de clusters d'utilisateurs selon un calendrier qui convient à votre organisation.

Différence de version entre le plan de contrôle du cluster d'utilisateur et le pool de nœuds

Règles de version pour les mises à niveau du plan de contrôle du cluster d'administrateur et du cluster d'utilisateur

Les règles de version pour les clusters d'administrateur et les mises à niveau du plan de contrôle des clusters d'utilisateur sont les mêmes. Vous pouvez passer directement à n'importe quelle version de la même version mineure ou de la version mineure suivante. Par exemple, vous pouvez passer de la version 1.32.0 à la version 1.32.1, ou de la version 1.31.1 à la version 1.32.0. Les versions de correctif n'affectent pas les règles de version de mise à niveau.

Si vous passez à une version qui ne fait pas partie de la prochaine version mineure, vous devez effectuer une mise à niveau via une version de chaque version mineure entre votre version actuelle et la version cible. Il n'est pas possible d'ignorer une version mineure. Par exemple, si vous souhaitez passer de la version 1.30.x à la version 1.32.x, vous ne pouvez pas le faire directement. Vous devez d'abord passer de la version 1.30.x à la version 1.31.x, puis effectuer la mise à niveau vers la version 1.32.x.

En règle générale, seules les mises à niveau de 1.n vers 1.n+1 sont prises en charge pour les mises à niveau du cluster d'administrateur et du plan de contrôle du cluster d'utilisateur.

Règles de version pour les mises à niveau des pools de nœuds

Dans la version 1.28 et les versions ultérieures, vous pouvez ignorer une version mineure lorsque vous mettez à niveau un pool de nœuds dans un cluster d'utilisateur. Par exemple, si le plan de contrôle d'un cluster d'utilisateur est à la version 1.32 et qu'un pool de nœuds est à la version 1.30, vous pouvez ignorer la version 1.31 et mettre directement à niveau le pool de nœuds vers la version 1.32. Les versions de correctif n'ont pas d'incidence sur les règles de version de mise à niveau.

En termes généraux, si un plan de contrôle de cluster d'utilisateur est à 1.n, vous pouvez mettre à niveau les pools de nœuds situés à 1.n-2 directement vers 1.n. Passer une version mineure lors de la mise à niveau des pools de nœuds peut réduire le temps de mise à niveau par rapport à deux mises à niveau de pool de nœuds (pour passer de 1.n-2 à 1.n-1, puis à 1.n). C'est une autre raison pour laquelle vous pouvez préférer mettre à niveau le plan de contrôle d'un cluster d'utilisateur séparément des pools de nœuds qui s'exécutent sur le cluster d'utilisateur.

• Version 1.31: non disponible sur les clusters avancés.
• Version 1.32 et ultérieure: disponible sur les clusters avancés.

Mises à niveau de versions de correctif

Nous vous recommandons, autant que possible, de procéder à la mise à niveau vers la dernière version du correctif, afin de vous assurer que vos clusters disposent des derniers correctifs de sécurité. Les versions de correctif n'ont pas d'incidence sur le décalage de version ni sur les règles de mise à niveau. Pour une version mineure donnée, vous pouvez passer à n'importe quelle version de correctif supérieure. Autrement dit, vous pouvez mettre à jour un cluster de version 1.32.X vers la version 1.32.Y tant que Y est supérieur à X. Par exemple, vous pouvez passer de la version 1.31.0 à la version 1.31.1 et de la version 1.31.1 à la version 1.31.3.

Étape suivante

Consultez les bonnes pratiques de mise à niveau et créez un plan de mise à niveau de vos clusters.