Gestion des versions et compatibilité GKE

Cette page explique la gestion des versions dans Google Kubernetes Engine (GKE) et les règles liées à la compatibilité des versions. Vous pouvez consulter le calendrier de déploiement et de compatibilité des versions actuelles dans le calendrier des versions de GKE.

Compatibilité avec les versions

La compatibilité de GKE avec les versions mineures de Kubernetes est basée sur les règles Open Source de Kubernetes. GKE est compatible avec une version mineure en fournissant des versions de correctif de la même version mineure et, régulièrement, en mettant à automatiquement niveau les clusters vers ces correctifs plus récents.

Compatibilité de Kubernetes avec une version mineure

La communauté Kubernetes Open Source Software (OSS) publie une version mineure avec de nouvelles fonctionnalités et améliorations trois fois par an. Chaque cycle de publication dure environ 15 semaines.

Kubernetes est compatible avec chaque version mineure pendant 14 mois. Des bugs importants et des failles de sécurité détectées dans une version mineure compatible sont corrigés avec la publication d'une version de correctif au cas par cas. La communauté Kubernetes modifie parfois l'agenda de compatibilité des versions, si nécessaire. Pour en savoir plus, consultez la section Période d'assistance.

Compatibilité de GKE avec une version mineure

Une fois que Kubernetes a publié une nouvelle version mineure, GKE l'introduit d'abord dans le canal rapide. GKE fournit des versions de correctif pendant cette période, mais comme le canal rapide fournit les versions les plus récentes de GKE, ces versions sont exclues des contrats de niveau de service GKE et peuvent présenter des problèmes sans solutions de contournement connues.

Après la disponibilité initiale dans le canal rapide, GKE promeut la nouvelle version mineure dans le canal standard. GKE fournit jusqu'à 24 mois de compatibilité au total pour une version mineure une fois que la version a été mise à disposition pour la création de clusters dans le canal standard. Cette assistance inclut environ 14 mois d'assistance standard et environ 10 mois supplémentaires d'assistance étendue disponible avec le canal étendu. Pour connaître la disponibilité de versions mineures spécifiques, consultez le calendrier des versions GKE.

Cycle de vie d'une version mineure de GKE

Le cycle de vie d'une version mineure de GKE comprend les étapes clés suivantes :

Kubernetes publie une nouvelle version mineure.
GKE met la nouvelle version mineure à disposition dans le canal rapide.
GKE rend la nouvelle version mineure disponible dans le canal standard (début de la période d'assistance standard).
Pendant la période d'assistance standard, GKE fournit des correctifs pour la version mineure, qui incluent de nouvelles fonctionnalités, des correctifs de sécurité et des corrections de bugs.
La version mineure atteint la fin de l'assistance standard au bout d'environ 14 mois, correspondant à la période d'assistance étendue. Passé ce délai, GKE fournit des correctifs de sécurité pour les clusters du canal étendu.
La version mineure atteint la fin de l'assistance étendue, ce qui signifie que la version mineure ne reçoit plus de correctifs de sécurité.

Ajustements de la disponibilité des versions

GKE est susceptible de modifier la date de fin de compatibilité des versions de GKE en raison des changements de règles dans la communauté Kubernetes OSS, de la découverte de failles ou d'autres problèmes techniques qui ne peuvent pas être raisonnablement résolus. GKE est également susceptible de prolonger les dates de fin de compatibilité autour de périodes de forte activité telles que le Black Friday et le Cyber Monday.

GKE fournit au moins 14 mois d'assistance standard et jusqu'à 24 mois d'assistance étendue.

Pour obtenir les dernières versions disponibles, consultez les notes de version de GKE. GKE met régulièrement à jour le calendrier des versions pour refléter la chronologie des mises à niveau automatiques.

Périodes de disponibilité dans le cycle de vie d'une version mineure

GKE fournit les périodes de disponibilité suivantes pour une version mineure de Kubernetes :

Périodes d'assistance. GKE est compatible avec une version mineure pendant 24 mois au total.

Consultez le tableau suivant qui récapitule les périodes de disponibilité, décrites en détail dans les sections suivantes :

Période de disponibilité	Période approximative à partir de la disponibilité du canal standard	Compatibilité avec GKE	Accès à cette période de disponibilité
Période de disponibilité rapide uniquement	Mois -1 au mois 0	GKE fournit des versions de correctif avec de nouvelles fonctionnalités, des correctifs de sécurité et des corrections de bugs. Toutefois, ces versions sont exclues du contrat de niveau de service GKE et peuvent contenir des problèmes sans solutions de contournement connues.	Canal rapide uniquement
Période d'assistance standard	Mois 1 au mois 14	GKE fournit des versions de correctif avec de nouvelles fonctionnalités, des correctifs de sécurité et des corrections de bugs.	Canal rapide, standard, stable, étendu, sans canal
Période d'assistance étendue	Mois 15 au mois 24	GKE fournit des versions de correctif avec des correctifs de sécurité.	Canal étendu uniquement (nécessite GKE Enterprise ou des frais supplémentaires par cluster, consultez la page Obtenir un support à long terme avec le canal étendu)

Période de disponibilité rapide uniquement

GKE publie d'abord une nouvelle version mineure dans le canal rapide. La version accumule d'abord de l'utilisation et démontre sa stabilité à travers les clusters de ce canal avant d'être promue dans le canal standard. Seuls les clusters enregistrés dans le canal rapide peuvent exécuter une nouvelle version mineure pendant cette période de disponibilité.

Cette période dure généralement un à deux mois, mais la durée exacte dépend de chaque version mineure. Pour en savoir plus, consultez la section Calendrier estimé des canaux de publication.

Période d'assistance standard

La période d'assistance standard d'une version mineure de GKE commence lorsque la version est publiée dans le canal standard. Tous les clusters GKE, quel que soit l'enregistrement du canal de publication, peuvent exécuter une version mineure dans l'assistance standard. Au cours de cette période, GKE met automatiquement à niveau les clusters régulièrement vers de nouvelles versions de correctif, qui incluent de nouvelles fonctionnalités, des correctifs de sécurité et des corrections de bugs.

GKE met automatiquement à niveau les clusters de la manière suivante :

Canal rapide, standard, stable, sans canal : mises à niveau automatiques vers d'autres versions mineures compatibles ou versions de correctif de la même version mineure.
Étendu : GKE n'effectue la mise à niveau automatiquement que vers les versions de correctif plus récentes de la même version mineure.

Pour les clusters non enregistrés dans le canal de publication étendu, GKE met à niveau automatiquement les clusters vers la prochaine version mineure compatible avant la fin de l'assistance standard, en fonction du calendrier des canaux de publication du cluster. Pour en savoir plus, consultez la section Calendrier estimé des canaux de publication. Toutefois, GKE ne met pas à niveau les clusters pendant cette période s'ils utilisent des fonctionnalités ou des API obsolètes. Vous pouvez utiliser une exclusion de maintenance pour empêcher temporairement GKE de mettre à niveau votre cluster vers la prochaine version mineure.

Fin de l'assistance standard (anciennement fin de vie)

Une fois la période d'assistance standard terminée, la version mineure atteint la fin de la période d'assistance standard (anciennement fin de vie), et devient non compatible et indisponible pour tous les clusters non enregistrés dans le canal étendu.

Les clients qui exécutent une version en fin de compatibilité sont informés par un e-mail envoyé au contact du projet avant la fin de compatibilité de la version. GKE lance également la mise à niveau automatique progressive des nœuds (indépendamment de l'activation de la mise à niveau automatique) exécutant des versions non compatibles à des fins de sécurité et de compatibilité, car aucun nouveau correctif de sécurité ni correction de bug ne sera fourni aux versions en fin de compatibilité. Avant de contacter Cloud Customer Care pour tout problème lié à un cluster ou à des nœuds exécutant une version en fin de compatibilité, vous devez d'abord mettre à niveau votre cluster et vos nœuds vers une version compatible.

Les versions mineures de GKE qui ne sont plus compatibles ne reçoivent plus de correctifs de sécurité ni de corrections de bugs. Les versions de correctif d'une version mineure qui a atteint la fin de la période d'assistance ne sont pas compatibles et ne sont pas disponibles. GKE met automatiquement à niveau tous les clusters non enregistrés dans le canal étendu. Pour en savoir plus, consultez la section Mises à niveau automatiques à la fin de la période d'assistance.

Période d'assistance étendue

À la fin de l'assistance standard, la version mineure atteint la période d'assistance étendue (mois 15 à mois 24). Au cours de cette période, GKE fournit des correctifs de sécurité, y compris les suivants :

Correctifs de sécurité moyens, élevés et critiques pour les composants principaux de Kubernetes, le système d'exploitation des nœuds et les conteneurs gérés par Google, fournis avec la version du cluster GKE.
Pour Container-Optimized OS, la fin de la période de compatibilité du système d'exploitation des nœuds peut survenir avant la fin de l'assistance étendue de la version mineure de GKE ou introduire des modifications incompatibles. Pour en savoir plus sur la manière dont GKE continue de fournir des services d'assistance, consultez la section Mises à jour de Container-Optimized OS pendant la période d'assistance étendue.

Vers la fin de la période d'assistance étendue, GKE commence à mettre à niveau les clusters vers la prochaine version mineure. GKE ne met pas à niveau les clusters s'ils utilisent des fonctionnalités ou des API obsolètes. Vous pouvez utiliser une exclusion de maintenance pour empêcher temporairement GKE de mettre à niveau votre cluster vers la prochaine version mineure.

Fin de l'assistance étendue

À la fin de l'assistance étendue, GKE ne fournit plus de correctifs de sécurité, et la version mineure est considérée comme non compatible. GKE met à niveau les clusters qui exécutent toujours la version mineure non compatible vers la version mineure suivante, quelle que soit l'utilisation par le cluster de fonctionnalités ou d'API obsolètes.

Mises à niveau automatiques à la fin de la période de compatibilité

GKE planifie les mises à niveau automatiques des clusters d'une version mineure vers la prochaine version mineure compatible avant que la version mineure n'arrive en fin de compatibilité. La chronologie de cette mise à niveau dépend du calendrier des canaux de publication du cluster. Pour en savoir plus, consultez la section Calendrier estimé des canaux de publication. Par exemple, les clusters enregistrés dans le canal stable sont mis à niveau vers la prochaine version mineure plus proche de la fin de l'assistance standard que les clusters enregistrés dans le canal rapide.

Pendant la période d'assistance standard et la période d'assistance étendue pour les clusters enregistrés dans le canal étendu, vous pouvez empêcher la mise à niveau de cette version mineure avec une exclusion de maintenance. GKE ne mettra pas à niveau les clusters utilisant des fonctionnalités ou API obsolètes.

Toutefois, à la fin de l'assistance standard ou à la fin de l'assistance étendue pour les clusters enregistrés dans le canal étendu, GKE met automatiquement à niveau les clusters vers la prochaine version mineure compatible afin de garantir qu'ils restent performants, disponibles et sécurisées.

Chaque version de GKE est compatible pour une période d'assistance standard de 14 mois et pour une période d'assistance totale de 24 mois, assistance étendue incluse. Vous ne pouvez pas conserver votre cluster sur une version indéfiniment, car l'exploitation d'un cluster utilisant une version de GKE non compatible présente un risque important concernant la sécurité, de fiabilité et de compatibilité, car GKE ne fournit pas de correctifs de sécurité ou de corrections de bugs pour les versions en fin de période de compatibilité. GKE ne peut pas s'engager à fournir des correctifs ou des mises à jour pour les versions en fin de période de compatibilité.

GKE met à niveau le cluster de la manière suivante :

Plan de contrôle : GKE met automatiquement à niveau les plans de contrôle de cluster vers les versions compatibles lorsque la version du plan de contrôle n'est plus disponible pour la création de clusters.
Nœuds : GKE met automatiquement à niveau les nœuds qui exécutent une version non compatible une fois que la version est arrivée en fin de compatibilité, afin de garantir l'état du cluster et son alignement avec la règle de décalage entre les versions Open Source. Les nœuds exécutant des versions non compatibles sont généralement mis à niveau automatiquement vers une version compatible dans un délai d'un mois après la date de fin de compatibilité. Les nœuds exécutant des versions non compatibles peuvent ne pas être mis à niveau immédiatement en fin de vie, et la durée réelle peut varier à la discrétion de Google.

Mises à jour de Container-Optimized OS pendant la période d'assistance étendue

Au cours de la période d'assistance étendue d'une version mineure de GKE, GKE fournit des mises à niveau de correctif pour le cluster, qui peuvent inclure des mises à jour de Container-Optimized OS.

La version de Container-Optimized OS LTS arrive en fin de compatibilité avant la version mineure.

La version de Container-Optimized OS LTS peut arriver en fin de compatibilité avant la fin de l'assistance étendue pour la version mineure utilisant le canal. Dans ce scénario, GKE utilise la prochaine version de Container-Optimized OS LTS disponible pour les futures mises à niveau correctives, si possible. GKE effectue cette mise à jour avant que la version de Container-Optimized OS LTS utilisée par la version mineure des nœuds n'arrive en fin de compatibilité. Les administrateurs de cluster doivent déterminer s'ils souhaitent effectuer une mise à niveau vers la prochaine version de correctif de GKE, qui contient une nouvelle version de Container-Optimized OS LTS, ou conserver la même version de correctif de GKE et ne pas recevoir de mises à jour dans le système d'exploitation des nœuds, ni de correctifs de sécurité pour les principaux composants Kubernetes fournis avec la version de cluster GKE.

La prochaine version de Container-Optimized OS LTS introduit des modifications incompatibles avec la version mineure existante.

La prochaine version de Container-Optimized OS LTS peut introduire des modifications incompatibles avec les composants du système GKE, et GKE ne peut pas fournir de version de correctif avec des mises à jour du système d'exploitation des nœuds. Les administrateurs de cluster doivent déterminer s'ils souhaitent effectuer une mise à niveau vers la prochaine version mineure de GKE, ou bien accepter les mêmes compromis que ceux décrits dans le paragraphe précédent.

Schéma de gestion des versions

GKE ajoute une version de correctif GKE à la norme sémantique du secteur de gestion des versions de Kubernetes (x.y.z-gke.N) :

Version majeure de Kubernetes (x): Les versions majeures sont généralement incrémentées si des modifications incompatibles avec les versions antérieures sont introduites dans l'API publique. Une version majeure incrémente la version de Kubernetes de x.y à x+1.y.
Version mineure de Kubernetes (y): Une nouvelle version mineure de Kubernetes est publiée trois fois par an. Chaque cycle de publication dure environ 15 semaines. Les API obsolètes peuvent être supprimées dans une nouvelle version mineure, par exemple dans la version 1.22. Une version mineure incrémente la version de Kubernetes de 1.y à 1.y+1. Par exemple, Kubernetes 1.32 est la version mineure qui suit Kubernetes 1.31.
Version de correctif de Kubernetes (z): Les nouvelles versions de correctif de Kubernetes (telles que la version 1.32.6) destinées à GKE sont généralement publiées selon un rythme hebdomadaire. Les versions de correctif sont déployées de manière progressive dans les différentes zones.
Version de correctif de GKE (-gke.N): Une version de correctif avec un suffixe "-gke.N" (tel que 1.32.6-gke.N) peut inclure des mises à jour de sécurité et des corrections de bugs pour GKE avec le logiciel Kubernetes Open Source en amont. Ces mises à jour ou correctifs sont nécessaires pour la compatibilité et l'interopérabilité avec Google Cloud.

Vérifier les versions disponibles et par défaut

Pour plus d'informations sur les versions disponibles, consultez les notes de version de GKE.

Vous pouvez également vérifier les versions de Kubernetes disponibles et par défaut dans une zone donnée depuis la console Google Cloud ou à l'aide de Google Cloud CLI.

Utiliser la console Google Cloud pour vérifier les versions

Pour afficher les versions par défaut disponibles, procédez comme suit :

Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

Accéder à Google Kubernetes Engine
Cliquez sur Créer.
Sélectionnez le mode de cluster Standard, puis cliquez sur Configurer.
Dans la section Type d'emplacement, sélectionnez un type d'emplacement et l'emplacement prévu pour votre cluster.
Dans la section Version du plan de contrôle, sélectionnez une version disponible. Toutes les versions actuellement disponibles sont répertoriées pour ce canal. La version par défaut est automatiquement sélectionnée.

Utiliser la CLI gcloud pour vérifier les versions

Pour voir quelles versions sont disponibles et par défaut, exécutez l'une des commandes gcloud suivantes pour votre type de cluster. Chaque onglet fournit des commandes permettant de vérifier les versions correspondant à une version disponible spécifique ou pour aucun canal (statique).

Élasticité

Pour afficher les versions par défaut et disponibles dans la version disponible de Rapid, exécutez les commandes suivantes :

Version par défaut

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=RAPID" \
   --format="yaml(channels.channel,channels.defaultVersion)" \
   --location=COMPUTE_LOCATION

Versions disponibles

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=RAPID" \
   --format="yaml(channels.channel,channels.validVersions)" \
   --location=COMPUTE_LOCATION

Remplacez les éléments suivants :

COMPUTE_LOCATION : emplacement Compute Engine.

Standard

Pour afficher les versions par défaut et disponibles dans la version disponible de Regular, exécutez les commandes suivantes :

Version par défaut

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=REGULAR" \
   --format="yaml(channels.channel,channels.defaultVersion)" \
   --location=COMPUTE_LOCATION

Versions disponibles

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=REGULAR" \
   --format="yaml(channels.channel,channels.validVersions)" \
   --location=COMPUTE_LOCATION

Remplacez les éléments suivants :

COMPUTE_LOCATION : emplacement Compute Engine.

Stable

Pour afficher les versions par défaut et disponibles dans la version disponible de Stable, exécutez les commandes suivantes :

Version par défaut

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=STABLE" \
   --format="yaml(channels.channel,channels.defaultVersion)" \
   --location=COMPUTE_LOCATION

Versions disponibles

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=STABLE" \
   --format="yaml(channels.channel,channels.validVersions)" \
   --location=COMPUTE_LOCATION

Remplacez les éléments suivants :

COMPUTE_LOCATION : emplacement Compute Engine.

Étendu

Pour afficher les versions par défaut et disponibles dans la version disponible de Extended, exécutez les commandes suivantes :

Version par défaut

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=EXTENDED" \
   --format="yaml(channels.channel,channels.defaultVersion)" \
   --location=COMPUTE_LOCATION

Versions disponibles

gcloud container get-server-config \
   --flatten="channels" \
   --filter="channels.channel=EXTENDED" \
   --format="yaml(channels.channel,channels.validVersions)" \
   --location=COMPUTE_LOCATION

Remplacez les éléments suivants :

COMPUTE_LOCATION : emplacement Compute Engine.

Aucun canal

Pour afficher les versions par défaut et disponibles pour aucun canal (statique), exécutez les commandes suivantes :

Version par défaut

gcloud container get-server-config \
   --format="yaml(defaultClusterVersion)" \
   --location=COMPUTE_LOCATION

Versions du plan de contrôle disponibles

gcloud container get-server-config \
   --format="yaml(validMasterVersions)" \
   --location=COMPUTE_LOCATION

Versions de nœuds disponibles

gcloud container get-server-config \
   --format="yaml(validNodeVersions)" \
   --location=COMPUTE_LOCATION

Remplacez les éléments suivants :

COMPUTE_LOCATION : emplacement Compute Engine.

Spécifier la version du cluster

Cette section ne s'applique qu'aux clusters créés en mode Standard.

Lorsque vous créez ou mettez à niveau un cluster à l'aide de gcloud CLI, vous pouvez spécifier une version de cluster à l'aide de l'option --cluster-version. Vous pouvez utiliser une version spécifique, telle que 1.9.7-gke.N. Vous pouvez également utiliser un alias de version :

latest : spécifie la version de Kubernetes compatible la plus élevée actuellement disponible sur GKE dans la zone ou la région du cluster
1.X : spécifie la plus haute version de patch+gke.N valide, publiée dans la version mineure 1.X
1.X.Y : spécifie la plus haute correction gke.N valide dans la version 1.X.Y
- : pour les plans de contrôle de cluster, spécifie la version de Kubernetes par défaut des plans de contrôle. Pour les mises à niveau de nœuds, spécifie la version exécutée par le plan de contrôle du cluster.

La création ou la mise à jour d'un cluster en spécifiant la version latest (la plus récente) ne fournit pas de mises à jour automatiques. Activez les mises à niveau automatiques des nœuds pour vous assurer que les nœuds de votre cluster sont à jour et disposent de la dernière version stable.

Spécifier la version du nœud

Cette section ne s'applique qu'aux clusters créés en mode Standard. Dans les clusters Autopilot, les nœuds sont automatiquement mis à niveau vers la version du plan de contrôle, et vous ne pouvez pas spécifier de version.

Lorsque vous créez ou mettez à jour un pool de nœuds, vous pouvez spécifier sa version. Par défaut, les nœuds exécutent la même version de GKE que le plan de contrôle. La version des nœuds ne peut pas être antérieure de plus de deux versions mineures à la version du plan de contrôle.

À de rares exceptions près, les versions de nœud restent disponibles même si la version de cluster n'est plus disponible.

Règle de décalage entre les versions GKE

La règle de décalage entre les versions GKE garantit qu'un cluster GKE maintient la compatibilité entre le plan de contrôle et les nœuds. Dans un cluster GKE, les nœuds peuvent correspondre à la version du plan de contrôle ou exécuter jusqu'à deux versions mineures antérieures à celle du plan de contrôle.

Les nœuds ne peuvent pas exécuter de versions plus récentes que la version du plan de contrôle. Par exemple, si le plan de contrôle du cluster exécute la version 1.31, les nœuds peuvent exécuter les versions suivantes : 1.31, 1.30 ou 1.29, mais pas la version 1.28 ni une version antérieure. La version des nœuds ne peut pas être plus récente que celle du plan de contrôle en raison de la règle de décalage entre les versions de Kubernetes OSS.

Pour garantir la compatibilité et la fiabilité, les nœuds doivent utiliser une version compatible, indépendamment de l'utilisation d'un décalage de version valide.

Possibilité d'ignorer les versions mineures

GKE ne permet pas d'ignorer des versions mineures pour le plan de contrôle du cluster, en revanche vous pouvez ignorer des versions de correctif. Les nœuds de calcul peuvent ignorer des versions mineures. Par exemple, un pool de nœuds peut être mis à niveau de la version 1.32 vers la version 1.34 tout en ignorant la version 1.33.

Pour mettre à niveau un cluster en le faisant évoluer de plusieurs versions mineures, mettez à niveau votre plan de contrôle version mineure par version mineure, en veillant à chaque fois à mettre à niveau vos nœuds de calcul vers la même version. Par exemple, pour mettre à niveau votre plan de contrôle de la version 1.32 vers la version 1.34, mettez-le d'abord à niveau de la version 1.32 vers la version 1.33, puis mettez à niveau vos nœuds de calcul pour qu'ils correspondent à la version du plan de contrôle, puis répétez le processus pour passer de la version 1.33 à la version 1.34.

La mise à niveau des nœuds de calcul, de sorte qu'ils soient calqués sur les versions du plan de contrôle, vous permet d'éviter le décalage de version. Dans la mesure du possible, nous vous recommandons d'éviter d'ignorer la version. Le fait d'ignorer des versions de nœuds de calcul implique généralement un champ d'application de test plus étendu, qui s'il reste gérable, demande tout de même plus de planification.

Vous pouvez également créer un cluster avec la version de votre choix et redéployer vos charges de travail.