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 communauté Kubernetes Open Source Software (OSS) publie actuellement une version mineure avec de nouvelles fonctionnalités et améliorations environ tous les trois mois. À partir de Kubernetes 1.19, OSS accepte chaque version mineure pendant 12 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 est susceptible de modifier de temps en temps l'agenda de compatibilité des versions.

Google offre une compatibilité de 14 mois au total pour chaque version mineure de GKE une fois la version mise à disposition dans le canal standard. Les versions de nœuds et de pool de nœuds peuvent être jusqu'à deux versions mineures antérieures au plan de contrôle, mais elle ne peuvent pas être plus récentes que la version du plan de contrôle en raison de la règle de décalage des 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.

Après 12 mois, une version compatible entre dans une période de maintenance de deux mois avant d'atteindre sa fin de la vie.

Cycle de vie d'une version mineure de GKE

La première phase du cycle de vie d'une version mineure commence par la publication d'une version compatible de GKE. Les clusters exécutant une version mineure compatible reçoivent des correctifs réguliers afin de corriger les bugs et les problèmes de sécurité signalés. Conformément à la règle actuelle de compatibilité des versions de la communauté Kubernetes OSS, GKE prévoit de maintenir la compatibilité des versions mineures pendant 14 mois, y compris les 12 mois suivant la publication dans le canal standard, ainsi qu'une période de maintenance de deux mois.

Environ six mois après l'entrée en service d'une version mineure, la version devient indisponible pour la création de clusters et de plans de contrôle. Les plans de contrôle qui exécutent la version mineure seront mis à niveau progressivement vers la prochaine version mineure compatible. Pour les clusters exécutant une version statique, il reste possible de créer des pools de nœuds sur la version. Sachez également que les clusters qui exécutent une version de maintenance continueront de fonctionner. Les clusters de canaux de publication nécessitent des plans de contrôle et des nœuds utilisant la même version mineure.

À la fin de la période de publication de 12 mois, GKE propose une période de maintenance de deux mois. Pendant les deux mois de la période de maintenance, aucune nouvelle création de pool de nœuds ne sera autorisée pour une version de maintenance, mais les pools de nœuds existants qui exécutent une version de maintenance continueront de fonctionner.

À la fin de la période de maintenance, une version de maintenance atteint sa fin de vie et devient officiellement incompatible. Les versions mineures de GKE qui sont arrivées en fin de vie ne reçoivent plus de correctifs de sécurité et/ou de corrections de bugs.

À partir de la version 1.19, GKE met à niveau les nœuds qui exécutent une version non compatible une fois que la version est arrivée en fin de vie afin de garantir l'intégrité du cluster et son alignement sur la règle d'asymétrie de version Open Source.

Google n'est pas en mesure de fournir des correctifs ou des mises à jour pour les versions en fin de vie.

Notez que, dans de rares cas, il peut être nécessaire de modifier la période de maintenance ou la fin de vie 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 être raisonnablement résolus. Pour obtenir les dernières versions disponibles, consultez les notes de version de GKE.

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 tous les trois mois environ. Une version mineure incrémente la version de Kubernetes de 1.y à 1.y+1. Par exemple, Kubernetes 1.19 est la version mineure qui suit Kubernetes 1.18.
Version de correctif de Kubernetes (z)
Les nouvelles versions de correctif de Kubernetes (telles que la version 1.18.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.a)
Une version de correctif avec un suffixe "-gke.a" (telle que 1.18.6-gke.a) inclut des mises à jour de sécurité et/ou 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 quelles versions de Kubernetes sont disponibles et par défaut dans une zone donnée à partir de Google Cloud Console ou à l'aide de l'outil de ligne de commande gcloud.

Vérifier les versions à l'aide de l'outil gcloud

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).

Version précoce

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)"

Versions disponibles

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

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)"

Versions disponibles

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

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)"

Versions disponibles

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

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)"

Versions du plan de contrôle disponibles

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

Versions de nœuds disponibles

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

Vérifier les versions à l'aide de Google Cloud Console

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

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

    Accéder à Google Kubernetes Engine

  2. Cliquez sur Créer.

  3. Sélectionnez le mode de cluster Standard, puis cliquez sur Configurer.

  4. Dans la section Type d'emplacement, sélectionnez un type d'emplacement et l'emplacement souhaité pour votre cluster.

  5. 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.

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 l'outil gcloud, 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 actuellement 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 mis à niveau automatiquement.

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.

Questions fréquentes sur la compatibilité des versions

Quand la période de compatibilité commence-t-elle pour chaque version mineure ?

La compatibilité d'une version mineure de Kubernetes commence dès sa première mise à disposition pour la création de clusters dans le canal standard.

Combien de temps une version mineure de Kubernetes est-elle acceptée par GKE ?

GKE fournit 14 mois de compatibilité pour chaque version mineure de Kubernetes disponible.

Les nouveaux clusters peuvent être créés sur une version mineure pendant environ six mois à compter du début de la période d'assistance de la version. Les pools de nœuds peuvent être créés sur une version mineure pendant environ 12 mois à compter du début de la période d'assistance de la version. Les versions recevront les correctifs critiques pour les bugs et problèmes de sécurité tout au long de la période d'assistance de 14 mois.

Quelle est la différence entre la période de maintenance et la période de fin de vie pour une version mineure de GKE ?

La période de maintenance signifie qu'une version doit bientôt entrer dans sa période de fin de vie. Elle ne peut recevoir que des correctifs de sécurité et de bugs importants. Pendant la période de fin de vie, la version mineure de GKE ne reçoit aucun correctif de sécurité, correction de bug ni aucune nouvelle fonctionnalité.

Quand la compatibilité d'une version de Kubernetes se termine-t-elle dans GKE ?

Une version mineure de Kubernetes n'est plus compatible avec GKE lorsqu'elle atteint sa fin de vie, au bout de 14 mois de compatibilité.

Que se passe-t-il à la date de début de la maintenance ?

GKE informe les clients des opérations de maintenance et de fin de vie à venir en passant par des points de contact existants, tels que les notes de version, les e-mails aux contacts du projet et les notifications GKE. le cas échéant. Les pools de nœuds existants qui exécutent une version de maintenance continueront de fonctionner et la création de pools de nœuds pour la version de maintenance sera désactivée.

Que se passe-t-il à la date de fin de vie ?

Les clients qui exécutent une version en fin de vie sont informés par un e-mail envoyé au contact du projet avant la fin de vie 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 en fin de vie à 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 vie. Avant de contacter Cloud Customer Care pour tout problème lié à un cluster ou à des nœuds exécutant une version en fin de vie, vous devez d'abord mettre à niveau votre cluster et vos nœuds vers une version compatible.

À quel moment précis mon cluster sera-t-il automatiquement mis à niveau ?

Les plans de contrôle de cluster seront automatiquement mis à niveau vers les versions compatibles lorsque la version du plan de contrôle n'est plus disponible pour la création de clusters.

Les nœuds exécutant des versions non compatibles seront mis à niveau automatiquement vers une version compatible dans un délai d'un mois après la date de fin de vie.

Puis-je ignorer plusieurs versions de GKE lors de la mise à niveau d'un cluster ?

Kubernetes OSS permet d'ignorer la version sur les nœuds de calcul. Par exemple, un pool de nœuds peut être mis à niveau de la version 1.19.x vers la version 1.21.x tout en ignorant la version 1.20.x. Vous pouvez également ignorer les versions du plan de contrôle lorsque vous mettez à niveau le plan de contrôle à l'aide de l'outil de ligne de commande gcloud ou de l'API GKE.

L'approche recommandée consiste à mettre à niveau votre plan de contrôle version mineure par version mineure et à mettre à niveau vos nœuds de calcul vers la même version à chaque fois. Par exemple, pour mettre à niveau votre plan de contrôle de la version 1.19.x vers la version 1.21.x, mettez d'abord à niveau la version 1.19.x vers la version 1.20.x, 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.20.x à la version 1.21.x.

Mettre à niveau votre plan de contrôle de manière incrémentielle et mettre à jour vos nœuds de calcul pour qu'ils correspondent aux versions vous aident à é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 implique généralement un champ d'application de test plus large qui demande plus de réflexion, même si cela peut être gérable.

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

Puis-je laisser mon cluster sur une version de Kubernetes indéfiniment ?

Non. Chaque version de GKE est compatible pendant 14 mois, et faire fonctionner un cluster qui utilise une version de GKE en fin de vie présente un risque important en matière de sécurité, de fiabilité et de compatibilité, car aucun correctif de sécurité ni de bug n'est fourni pour les versions en fin de vie.

À quelle fréquence dois-je mettre à niveau une version de Kubernetes pour qu'elle continue à être compatible ?

Nous vous recommandons d'activer un canal de publication et d'activer les mises à niveau automatiques des nœuds afin de réduire la charge opérationnelle liée à la mise à niveau des versions de GKE. Cependant, lors d'une mise à niveau manuelle, nous vous recommandons de passer à une version ultérieure au plus tard tous les six mois afin de pouvoir accéder à de nouvelles fonctionnalités et conserver une version compatible.

Quelle est la règle de déploiement des plans de contrôle GKE ?

Les plans de contrôle de cluster sont toujours mis à niveau régulièrement, que votre cluster soit inscrit dans un canal de publication ou que la mise à niveau automatique des nœuds soit désactivée. Pour en savoir plus, consultez la section Mises à niveau automatiques.