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 trois fois par an. Chaque cycle de publication dure environ 15 semaines.
À 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 mineure 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. Cette période de compatibilité est suivie d'une période de maintenance de deux mois. Pendant 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 mineure atteint sa fin de vie et devient officiellement incompatible et indisponible. Les versions mineures de GKE qui sont arrivées en fin de vie ne reçoivent plus de correctifs de sécurité ou de corrections de bugs. Les versions de correctif d'une version mineure qui est arrivée en fin de vie ne sont pas compatibles et ne sont pas disponibles.
À partir de la version 1.19 de GKE, 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'état du cluster et son alignement sur la règle d'asymétrie de version Open Source. 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.
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 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.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.N)
- Une version de correctif avec un suffixe "-gke.N" (tel que 1.18.6-gke.N) 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 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 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).
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)"
Utiliser la console Google Cloud pour vérifier les versions
Pour afficher les versions disponibles et par défaut, procédez comme suit :
Accédez à la page Google Kubernetes Engine dans Google Cloud Console.
Cliquez sur add_box 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 souhaité 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.
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 cluster1.X: spécifie la plus haute version de patch+gke.N valide, publiée dans la version mineure 1.X1.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 versions recevront les correctifs pour les bugs et problèmes de sécurité tout au long de la période d'assistance.
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. 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 des versions de GKE lors de la mise à niveau d'un cluster ?
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.23 vers la version 1.25 tout en ignorant la version 1.24.
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.23 vers la version 1.25, mettez-le d'abord à niveau de la version 1.23 vers la version 1.24, 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.24 à la version 1.25.
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.
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.