Cette page présente le processus de mise à niveau et les informations sur le décalage 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 qui vous aidera à planifier la mise à niveau, consultez la page Bonnes pratiques de mise à niveau.
Séquence de mise à niveau
Les mises à niveau sur place depuis la version 1.7 doivent toujours suivre une séquence de mise à niveau spécifique:
Mettre à 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 indépendamment des pools de nœuds du cluster d'utilisateur. Pour en savoir plus, consultez la section Mises à niveau des clusters d'utilisateur.
Une fois que tous les pools de nœuds d'un cluster d'utilisateur sont associés à la même version que le plan de contrôle du cluster d'utilisateur, celui-ci est entièrement mis à niveau.
Un cluster d'administrateur ne peut pas avoir une version mineure ultérieure à celle des clusters d'utilisateur qu'il gère. Si l'un de vos clusters d'utilisateur est associé à 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 au moins une version mineure postérieure à celle du cluster d'administrateur, vous pouvez éventuellement mettre à niveau le cluster d'administrateur.
Le décalage et les règles de version pour les mises à niveau ont été modifiés dans les versions 1.28 et ultérieures. Pour en savoir plus, consultez la section Décalage de version.
Mises à niveau des clusters d'utilisateur
Lors de la mise à niveau des clusters d'utilisateur, vous pouvez choisir de mettre à niveau le cluster d'utilisateur dans son ensemble (vous pouvez ainsi 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 conserver la version actuelle des pools de nœuds. L'approche que vous adoptez dépend de plusieurs facteurs, tels que:
- Environnement (de production ou hors production) dans lequel se trouve le cluster.
- Durée de l'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 souhaiterez peut-être ne mettre à niveau que le plan de contrôle, car 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 avec les pools de nœuds Windows.
Mettre à niveau les pools de nœuds de manière sélective
Dans certains cas, vous souhaiterez peut-être mettre à niveau certains pools de nœuds d'un cluster d'utilisateur, mais pas tous. Par exemple, après avoir mis à niveau le plan de contrôle, vous pouvez mettre à niveau un pool de nœuds avec 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 des pools de nœuds supplémentaires jusqu'à ce que tous les pools soient mis à niveau.
Choisir un outil pour mettre à niveau les clusters d'utilisateur
Google Distributed Cloud vous fournit un choix d'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 surgkectl.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 les 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 pouvoir utiliser la console ou la gcloud CLI pour la mise à niveau. À partir de la version 1.16, 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 que vous utilisez 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 avec 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 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 du cluster d'administrateur
Lorsque le plan de contrôle et les pools de nœuds de tous les clusters d'utilisateur sont au moins une version mineure postérieure à celle du cluster d'administrateur, vous pouvez éventuellement mettre à niveau le cluster d'administrateur. Seul gkectl permet de mettre à niveau des clusters d'administrateur. Les clients de l'API GKE On-Prem ne sont pas compatibles avec la mise à niveau des clusters d'administrateur.
Décalage entre les versions
Le décalage de version correspond à la différence entre les 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 globale du plan de contrôle et des pools de nœuds.
En outre, le décalage de version correspond à la différence entre les 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 les règles de décalage et de version compatibles pour les mises à niveau peut vous aider à planifier l'ordre dans lequel vous mettrez à niveau les clusters.
Décalage entre les versions du cluster d'administrateur et d'utilisateur
Un cluster d'administrateur peut gérer des clusters d'utilisateur de 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 à l'étape Disponibilité générale.
À partir de la version 1.29, les clusters d'utilisateur peuvent être jusqu'à deux versions mineures supérieures à celles de leur cluster d'administrateur. Par exemple, si un cluster d'administrateur est à 1.16, les clusters d'utilisateur gérés par ce cluster d'administrateur peuvent être à 1.16, 1.28 ou 1.29.
En règle générale, si 1.n est la version mineure du cluster d'administrateur, les clusters d'utilisateur peuvent être 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 prochaine version mineure 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 jusqu'à deux versions mineures supérieures à leur cluster d'administrateur. Par exemple, si un cluster d'administrateur est à 1.15, les clusters d'utilisateur gérés par ce cluster d'administrateur peuvent être à 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 seule version mineure supérieure à celle du cluster d'administrateur. Par exemple, si un cluster d'administrateur est à 1.15, les clusters d'utilisateur gérés par ce cluster d'administrateur peuvent être à 1.15 ou 1.16.
En règle générale, 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 prochaine version mineure tant que le cluster d'administrateur ne dispose pas de la même version mineure que le cluster d'utilisateur.
Écart du plan de contrôle du cluster d'utilisateur et de la version du 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 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 à celles des pools de nœuds du cluster. Par exemple, si le plan de contrôle d'un cluster d'utilisateur est à 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 du plan de contrôle d'un cluster d'utilisateur, les pools de nœuds du cluster peuvent être définis sur 1.n, 1.n-1 ou 1.n-2.
Les plans de contrôle des 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 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 à celles 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 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 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 qu'une version mineure 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.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 du plan de contrôle d'un cluster d'utilisateur, les pools de nœuds du cluster peuvent être 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 sont pas associés à 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 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 de mise à niveau.
Si vous passez à une version qui ne fait pas partie de la prochaine version mineure, vous devez passer à 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 passer à la version 1.29.x.
En règle générale, seules les mises à niveau de 1.n vers 1.n+1 sont compatibles avec 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 à 1.29 et si 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 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 les pools de nœuds situés à 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 à la mise à niveau de deux pools de nœuds (pour passer de 1.n-2 à 1.n-1, puis à 1.n). C'est une autre raison pour laquelle vous pouvez mettre à niveau le plan de contrôle d'un cluster d'utilisateur séparément de celui 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'installer 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 les règles de décalage et de mise à niveau des versions. 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 la 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
Consultez les bonnes pratiques de mise à niveau et créez un plan de mise à niveau de vos clusters.