Cette page présente le processus de mise à niveau et des informations sur les écarts de version qui devraient vous aider à planifier l'ordre dans lequel vous mettez à niveau les clusters dans un environnement multicluster. Pour obtenir des informations de planification plus détaillées, y compris une checklist pour vous aider à planifier la mise à niveau, consultez la page Bonnes pratiques de mise à niveau.
Séquence de mise à niveau
Depuis la version 1.7, les mises à niveau sur place doivent toujours suivre une séquence de mise à niveau spécifique :
Mettez à niveau le poste de travail administrateur. Nous vous recommandons de le faire même si vous prévoyez d'utiliser la console Google Cloud, Google Cloud CLI ou Terraform pour mettre à niveau des clusters d'utilisateur.
Mettez à niveau les clusters d'utilisateurs, un à la fois. Dans les versions 1.14 et ultérieures, vous pouvez éventuellement mettre à niveau le plan de contrôle d'un cluster d'utilisateur séparément des pools de nœuds du cluster d'utilisateur. Pour en savoir plus sur les raisons de procéder à cette opération, consultez la section Mises à niveau des clusters d'utilisateurs.
Une fois que tous les pools de nœuds d'un cluster d'utilisateur sont de la même version que le plan de contrôle du cluster d'utilisateur, le cluster d'utilisateur est complètement mis à niveau.
Un cluster d'administrateur ne peut pas être à une version mineure ultérieure à celle des clusters d'utilisateur qu'il gère. Si l'un de vos clusters d'utilisateurs est à la même version mineure que le cluster d'administrateur, vous ne pouvez pas mettre à niveau le cluster d'administrateur.
Lorsque tous les clusters d'utilisateur sont à jour avec au moins une version mineure de plus que le cluster d'administrateur, vous pouvez éventuellement mettre à niveau le cluster d'administrateur.
Le décalage de version et les règles de version pour les mises à niveau ont changé dans la version 1.28 et les versions ultérieures. Pour en savoir plus, consultez la section Différence de version.
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 (en 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 de version 1.28 ou ultérieure, vous pouvez ignorer une version mineure lors de la mise à niveau des pools de nœuds.
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.
Mettre à niveau les pools de nœuds de manière sélective
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 la mise à niveau du plan de contrôle, vous pouvez mettre à niveau un pool de nœuds comportant un trafic faible ou exécutant 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.
Choisir un outil pour mettre à niveau des clusters d'utilisateurs
Google Distributed Cloud vous offre plusieurs outils pour mettre à niveau les clusters d'utilisateur.
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 àgkectl.La console Google Cloud, 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 d'utilisateur à l'aide de Terraform.
Si votre cluster d'utilisateur a été créé avec
gkectl, il doit être enregistré dans l'API GKE On-Prem pour que vous puissiez utiliser la console ou gcloud CLI pour la mise à niveau. Dans les versions 1.16 et ultérieures, les clusters créés avecgkectlsont enregistrés par défaut dans l'API GKE On-Prem. Pour les clusters créés dans des versions précédentes, vous pouvez enregistrer le cluster après sa création.Même si vous décidez d'utiliser
gkectlpour 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, gcloud CLI ou Terraform pour mettre à niveau le plan de contrôle d'un cluster utilisateur séparément des pools de nœuds. La console n'est pas compatible avec la mise à niveau du plan de contrôle uniquement.Mettre à niveau de manière sélective les pools de nœuds après la mise à niveau du plan de contrôle : vous pouvez utiliser
gkectl, 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
gkectlest compatible avec ce cas d'utilisation.
Mises à niveau des clusters d'administrateur
Lorsque le plan de contrôle et les pools de nœuds de tous les clusters d'utilisateur sont à jour avec au moins une version mineure par rapport au cluster d'administrateur, vous pouvez éventuellement mettre à niveau le cluster d'administrateur. Seul gkectl est compatible avec la mise à niveau des clusters d'administrateur. Les clients API GKE On-Prem ne sont pas compatibles avec la mise à niveau des clusters d'administrateur.
Décalage entre les versions
L'écart de version correspond à 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, l'écart 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.
Décalage entre les versions du cluster d'administrateur et du cluster d'utilisateur
Un cluster d'administrateur peut gérer des clusters d'utilisateur qui existent dans différentes versions. Cette fonctionnalité vous permet de mettre à niveau un parc de clusters d'utilisateur selon un calendrier adapté à votre organisation.
1.29 et versions ultérieures
Le décalage de version est le même que dans la version 1.28. Dans la version 1.29, cette fonctionnalité est passée à la phase de disponibilité générale.
À partir de la version 1.29, les clusters d'utilisateurs peuvent être supérieurs de deux versions mineures à leur cluster d'administrateur. Par exemple, si un cluster d'administrateur est en version 1.28, les clusters d'utilisateurs gérés par ce cluster d'administrateur peuvent être en version 1.28, 1.29 ou 1.30.
En général, si 1.n est la version mineure du cluster d'administrateur, les clusters d'utilisateur peuvent se trouver sur 1.n, 1.n+1 ou 1.n+2. Les clusters d'utilisateur en version 1.n+2 ne peuvent pas être mis à niveau vers la version mineure suivante tant que le cluster d'administrateur n'a pas été mis à niveau au moins une version mineure.
1.28
Dans la version 1.28, les clusters d'utilisateur peuvent être supérieurs de deux versions mineures à leur cluster d'administrateur. Par exemple, si un cluster d'administrateur est à l'adresse 1.15, les clusters d'utilisateur gérés par ce cluster d'administrateur peuvent être à l'adresse 1.15, 1.16 ou 1.28. Les clusters d'utilisateur version 1.28 ne peuvent pas être mis à niveau vers la version 1.29 tant que le cluster d'administrateur n'a pas été mis à niveau vers la version 1.16 au minimum.
1.16 et versions antérieures
Dans la version 1.16 et les versions antérieures, les clusters d'utilisateur ne peuvent être supérieurs à leur cluster d'administrateur que d'une version mineure. Par exemple, si un cluster d'administrateur est en version 1.15, les clusters d'utilisateurs gérés par ce cluster d'administrateur peuvent être en version 1.15 ou 1.16.
En termes généraux, si 1.n est la version mineure du cluster d'administrateur, les clusters d'utilisateur peuvent être à 1.n ou 1.n+1. Vous ne pouvez pas mettre à niveau les clusters d'utilisateur vers la version mineure suivante tant que le cluster d'administrateur n'est pas à la même version mineure que le cluster d'utilisateur.
Différence de version entre le plan de contrôle du cluster d'utilisateur et le pool de nœuds
1.29 et versions ultérieures
Le décalage de version est le même que dans la version 1.28. Dans la version 1.29, cette fonctionnalité est passée à l'étape de disponibilité générale.
À partir de la version 1.29, le plan de contrôle d'un cluster d'utilisateur peut être supérieur de deux versions mineures aux pools de nœuds du cluster. Par exemple, si le plan de contrôle d'un cluster d'utilisateur est à 1.30, les pools de nœuds du cluster peuvent être à 1.28, 1.29 ou 1.30.
En termes généraux, si 1.n est la version mineure d'un plan de contrôle de cluster d'utilisateur, les pools de nœuds du cluster peuvent se trouver dans 1.n, 1.n-1 ou 1.n-2.
Les plans de contrôle des clusters d'utilisateurs ne peuvent pas être mis à niveau vers la prochaine version mineure tant que tous les pools de nœuds ne sont pas à 1.n ou 1.n-1.
1.28
Dans la version 1.28, le plan de contrôle d'un cluster d'utilisateur peut être jusqu'à deux versions mineures supérieure à celle des pools de nœuds du cluster. Par exemple, si le plan de contrôle d'un cluster d'utilisateur est à 1.28, les pools de nœuds du cluster peuvent être à 1.15, 1.16 ou 1.28. Les plans de contrôle de cluster d'utilisateur ne peuvent pas être mis à niveau vers la version 1.29 tant que tous les pools de nœuds ne sont pas en version 1.28 ou 1.16.
1.16 et versions antérieures
Dans les versions 1.16 et antérieures, le plan de contrôle d'un cluster d'utilisateur ne peut être qu'une version mineure supérieure aux pools de nœuds du cluster. Par exemple, si le plan de contrôle d'un cluster d'utilisateur est à la version 1.16, les pools de nœuds du cluster peuvent être à la version 1.15 ou 1.16.
En termes généraux, si 1.n est la version mineure d'un plan de contrôle de cluster d'utilisateur, les pools de nœuds du cluster peuvent être à 1.n ou 1.n-1. Les clusters d'utilisateur ne peuvent pas être mis à niveau vers la version mineure suivante tant que tous les pools de nœuds ne sont pas de la même version mineure que le plan de contrôle.
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 du cluster d'utilisateur sont identiques. 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.30.0 à la version 1.30.1, ou de la version 1.29.1 à la version 1.30.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.28.x à la version 1.30.x, vous ne pouvez pas effectuer de mise à niveau directement. Vous devez d'abord passer de la version 1.28.x à la version 1.29.x, puis effectuer la mise à niveau vers la version 1.30.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 de pools de nœuds
À partir de la version 1.28, vous pouvez ignorer une version mineure lors de la mise à niveau d'un pool de nœuds dans un cluster d'utilisateur. Par exemple, si un plan de contrôle de cluster d'utilisateur est à la version 1.30 et qu'un pool de nœuds est à la version 1.28, vous pouvez ignorer la version 1.29 et mettre à niveau le pool de nœuds directement vers la version 1.30. Les versions de correctif n'ont pas d'incidence sur les règles de version de mise à niveau.
En général, si un plan de contrôle de cluster d'utilisateur se trouve sur 1.n, vous pouvez mettre à niveau les pools de nœuds situés sur 1.n-2 directement vers 1.n. Le fait d'ignorer une version mineure lors de la mise à niveau des pools de nœuds peut réduire le temps nécessaire à l'exécution de 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 préférerez peut-être mettre à niveau le plan de contrôle d'un cluster d'utilisateur séparément des pools de nœuds exécutés sur le cluster d'utilisateur.
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'affectent pas les règles de décalage et de mise à niveau des versions. 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.30.X vers la version 1.30.Y tant que Y est supérieur à X. Par exemple, vous pouvez passer de la version 1.29.0 à la version 1.29.1 et de la version 1.29.1 à la version 1.29.3.
Étape suivante
Consultez les bonnes pratiques de mise à niveau et créez un plan de mise à niveau de vos clusters.