Cette page présente le processus de mise à niveau et le décalage de versions. Ces informations doivent vous aider à planifier l'ordre dans lequel vous mettez à niveau les clusters dans un environnement multicluster. Pour obtenir des informations plus détaillées sur la planification, y compris une checklist pour vous aider à planifier la mise à niveau, consultez Bonnes pratiques de mise à niveau.
Séquence de mise à niveau
Les mises à niveau sur place effectuées depuis la version 1.7 doivent toujours suivre une séquence de mises à 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'utilisateur un par un. À partir de la version 1.14, 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 ces raisons, consultez la section Mises à niveau des clusters d'utilisateur.
Une fois que tous les pools de nœuds d'un cluster d'utilisateur ont 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 disposer d'une version mineure ultérieure à celle des clusters d'utilisateur qu'il gère. Si l'un de vos clusters d'utilisateur utilise 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 disposent d'au moins une version mineure après le cluster d'administrateur, vous pouvez éventuellement mettre à niveau le cluster d'administrateur.
Le décalage entre les versions et les règles de version pour les mises à niveau ont changé dans les versions 1.28 et ultérieures. Pour en savoir plus, consultez la section Décalage entre les versions.
Mises à niveau des clusters d'utilisateur
Lors de la mise à niveau de clusters d'utilisateur, vous pouvez choisir de mettre à niveau le cluster d'utilisateur dans son intégralité (ce qui signifie que vous pouvez mettre à niveau le plan de contrôle et tous les pools de nœuds du cluster), ou vous pouvez 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 un intervalle de maintenance court, vous pouvez mettre à niveau uniquement le plan de contrôle. Cela prend moins de temps et, 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 à la 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 compatible avec 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 façon sélective
Dans certains cas, vous souhaiterez peut-être mettre à niveau une partie des pools de nœuds d'un cluster d'utilisateur, mais pas tous. Par exemple, après la mise à niveau du plan de contrôle, vous pouvez mettre à niveau un pool de nœuds dont le trafic est faible 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 qu'ils soient tous mis à niveau.
Choisir un outil pour mettre à niveau les clusters d'utilisateur
Google Distributed Cloud vous propose 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, modifiez le fichier de configuration de votre cluster d'utilisateur afin de définir la version cible du plan de contrôle du cluster et, éventuellement, des pools de nœuds. Spécifiez ce fichier dans la ligne de commande pourgkectl.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éé à 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 degkectlsont enregistrés par défaut dans l'API GKE On-Prem. 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
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 la gcloud CLI.
L'outil à utiliser dépend de la manière dont vous prévoyez de mettre à niveau les clusters d'utilisateur:
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 les pools de nœuds de manière sélective 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.Mettez à niveau le plan de contrôle et un ou plusieurs pools de nœuds simultanément : seul
gkectlest compatible avec ce cas d'utilisation.
Mises à niveau du cluster d'administrateur
Lorsque le plan de contrôle et les pools de nœuds de tous les clusters d'utilisateur disposent d'au moins une version mineure postérieure au cluster d'administrateur, vous pouvez éventuellement mettre à niveau le cluster d'administrateur. Seul gkectl permet de mettre à niveau les 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
Le décalage entre les versions correspond à la différence de versions mineures entre un cluster d'administrateur et son ou 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.
En outre, le décalage entre les versions 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, la compréhension du décalage de versions et des règles de version pris en charge pour les mises à niveau peut vous aider à planifier l'ordre dans lequel vous mettez à niveau les clusters.
Décalage entre les versions des clusters d'administrateur et d'utilisateur
Un cluster d'administrateur peut gérer des clusters d'utilisateur de versions différentes. Cette fonctionnalité vous permet de mettre à niveau un parc de clusters d'utilisateur selon un calendrier adapté à votre organisation.
1.29 et ultérieure
Le décalage entre les versions 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'utilisateur peuvent posséder jusqu'à deux versions mineures supérieures à celles de leur cluster d'administrateur. Par exemple, si un cluster d'administrateur est à la version 1.16, les clusters d'utilisateur gérés par ce cluster d'administrateur peuvent être à la version 1.16, 1.28 ou 1.29.
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 de 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 posséder jusqu'à deux versions mineures supérieures à leur cluster d'administrateur. Par exemple, si un cluster d'administrateur est à la version 1.15, les clusters d'utilisateur gérés par ce cluster d'administrateur peuvent être à la version 1.15, 1.16 ou 1.28. Les clusters d'utilisateur de la 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 ou ultérieure.
1,16 et versions antérieures
À partir de la version 1.16, les clusters d'utilisateur ne peuvent avoir qu'une version mineure supérieure à leur cluster d'administrateur. Par exemple, si un cluster d'administrateur est à la version 1.15, les clusters d'utilisateur gérés par ce cluster d'administrateur peuvent être à la version 1.15 ou 1.16.
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 ou 1.n+1. Les clusters d'utilisateur ne peuvent pas être mis à niveau vers la version mineure suivante tant que le cluster d'administrateur ne dispose pas de la même version mineure que le cluster d'utilisateur.
Décalage entre les versions du plan de contrôle et du pool de nœuds du cluster d'utilisateur
1.29 et ultérieure
Le décalage entre les versions 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, le plan de contrôle d'un cluster d'utilisateur peut être jusqu'à deux versions mineures supérieures aux pools de nœuds du cluster. Par exemple, si le plan de contrôle d'un cluster d'utilisateur est défini sur 1, 29, les pools de nœuds du cluster peuvent être à 1.16, 1.28 ou 1.29.
En général, 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 sur 1.n, 1.n-1 ou 1.n-2.
Les plans de contrôle du cluster d'utilisateur ne peuvent pas être mis à niveau vers la version mineure suivante tant que tous les pools de nœuds ne sont pas définis sur 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érieures aux pools de nœuds du cluster. Par exemple, si le plan de contrôle d'un cluster d'utilisateur est défini sur 1, 28, les pools de nœuds du cluster peuvent être à 1.15, 1.16 ou 1.28. Les plans de contrôle des clusters d'utilisateur ne peuvent pas être mis à niveau vers la version 1.29 tant que tous les pools de nœuds ne sont pas définis sur 1.28 ou 1.16.
1,16 et versions antérieures
À partir de la version 1.16, le plan de contrôle d'un cluster d'utilisateur ne peut être que d'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 à 1,16, les pools de nœuds du cluster peuvent être à 1.15 ou 1.16.
En général, 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 sur 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 disposent pas de la même version mineure que le plan de contrôle.
Règles relatives aux versions pour les mises à niveau du plan de contrôle des clusters d'administrateur et des clusters d'utilisateur
Les règles de version sont identiques pour les clusters d'administrateur et les mises à niveau du plan de contrôle des clusters d'utilisateur. Vous pouvez effectuer une mise à niveau directement vers n'importe quelle version de la même version mineure ou de la prochaine version mineure. Par exemple, vous pouvez passer de la version 1.29.0 à la version 1.29.1, ou de la version 1.28.1 à la version 1.29.0. Les versions de correctif n'affectent pas les règles des versions de mise à niveau.
Si vous effectuez une mise à niveau vers une version qui ne fait pas partie de la prochaine version mineure, vous devez effectuer la mise à niveau via une version de chaque version mineure entre votre version actuelle et votre version cible. Il n'est pas possible d'ignorer une version mineure. Par exemple, si vous souhaitez passer de la version 1.16.x à la version 1.29.x, vous ne pouvez pas effectuer la mise à niveau directement. Vous devez d'abord passer de la version 1.16.x à la version 1.28.x, puis vers la version 1.29.x.
En général, seules les mises à niveau de 1.n vers 1.n+1 sont acceptées 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 le plan de contrôle d'un cluster d'utilisateur est à 1,29 et qu'un pool de nœuds est à 1,16, vous pouvez ignorer la version 1.28 et mettre à niveau le pool de nœuds directement vers la version 1.29. Les versions de correctif n'affectent pas les règles de version de mise à niveau.
En général, si le plan de contrôle d'un cluster d'utilisateur se trouve sur 1.n, vous pouvez mettre à niveau directement les pools de nœuds situés sur 1.n-2 vers 1.n. Ignorer une version mineure lors de la mise à niveau des pools de nœuds peut réduire le temps par rapport à deux mises à niveau de pools de nœuds (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 qui s'exécutent sur le cluster d'utilisateur.
Mises à niveau de versions de correctif
Dans la mesure du possible, nous vous recommandons d'effectuer une mise à niveau vers la dernière version du correctif pour vous assurer que vos clusters disposent des derniers correctifs de sécurité. Les versions de correctif n'affectent pas le décalage des versions ni les règles de mise à niveau. Pour une version mineure donnée, vous pouvez effectuer une mise à niveau vers n'importe quelle version de correctif supérieure. Autrement dit, vous pouvez mettre à niveau un cluster de version 1.29.X vers la version 1.29.Y tant que Y est supérieur à X. Par exemple, vous pouvez passer de la version 1.28.0 à la version 1.28.1 et de la version 1.28.1 à la version 1.28.3.
Étapes suivantes
Passez en revue les bonnes pratiques de mise à niveau et créez un plan de mise à niveau de vos clusters.