À propos des versions disponibles

Utilisez la fonctionnalité de canal de publication pour Google Kubernetes Engine (GKE) afin de choisir des versions pour vos clusters, en vous offrant un équilibre entre disponibilité des fonctionnalités et stabilité.

GKE met automatiquement à niveau tous les clusters au fil du temps, y compris ceux qui ne sont pas enregistrés dans un canal de publication, afin de s'assurer qu'ils reçoivent les mises à jour de sécurité, les correctifs aux problèmes connus et les nouvelles fonctionnalités, et qu'ils exécutent une version compatible de Kubernetes. Vous pouvez contrôler la chronologie des mises à niveau à l'aide d'intervalles et d'exclusions de maintenance.

Nous vous recommandons d'enregistrer votre cluster dans un version disponible, car cela vous offre le plus de contrôle en ce qui concerne le champ d'application des exclusions de maintenance, en empêchant des types spécifiques de mises à niveau et non pas toutes les mises à niveau – et de séquencer le déploiement des mises à niveau du cluster. Les clusters Autopilot ne peuvent être enregistrés que dans une version disponible.

Si vous n'enregistrez pas votre cluster Standard dans un canal de publication, vous pouvez désactiver les mises à niveau automatiques des nœuds pour les pools de nœuds sélectionnés et gérer manuellement les mises à niveau des nœuds de ces pools de nœuds. Cependant, tous les plans de contrôle des clusters sont automatiquement mis à niveau. Lorsqu'une version atteint la fin de sa période de compatibilité, les plans de contrôle et les nœuds du cluster sont automatiquement mis à niveau quel que soit le canal de publication. Pour en savoir plus, consultez la comparaison entre les clusters enregistrés et non enregistrés dans un canal de publication.

Canaux disponibles

Le tableau suivant explique les propriétés des canaux de publication disponibles, chacun offrant un compromis entre la disponibilité et la stabilité des fonctionnalités. Tous les canaux proposent des versions prises en charge de GKE et sont considérés comme étant en disponibilité générale (DG) (bien que ce ne soit pas toujours le cas des fonctionnalités individuelles, comme indiqué ci-dessous). Les versions de Kubernetes incluses dans ces canaux sont des versions officielles, et comprennent les API Kubernetes en DG et bêta.

Canal Disponibilité de la nouvelle version de Kubernetes Quand utiliser ce canal ?
Élasticité Plusieurs semaines après le partage en Open Source de la version en DG Obtenez la dernière version de Kubernetes le plus tôt possible et exploitez les nouvelles fonctionnalités de GKE dès leur mise en DG. GKE met fréquemment à jour votre cluster pour rester sur la dernière version du correctif et proposer les fonctionnalités Kubernetes les plus récentes. Les clusters abonnés au canal rapide utilisent les versions en disponibilité générale. Toutefois, nous vous recommandons d'utiliser le canal rapide pour tester les versions et les API les plus récentes de Kubernetes dans des environnements de préproduction.
Standard (par défaut) Deux à trois mois après la publication dans le canal rapide Accédez aux fonctionnalités de GKE et de Kubernetes rapidement après leur passage en DG, mais sur une version qui a été qualifiée sur une période plus longue. Offre un compromis entre la disponibilité des fonctionnalités et la stabilité des releases. Il s'agit du canal que nous recommandons pour la plupart des utilisateurs.
Stable Deux à trois mois après la publication dans le canal standard Donnez la priorité à la stabilité plutôt qu'aux nouvelles fonctionnalités. GKE déploie les modifications et les nouvelles versions dans ce canal en dernier, après leur validation sur les canaux rapide et standard, vous permettant ainsi de dégager davantage de temps pour la validation.
Étendu Alignement avec le canal standard Utilisez ce canal pour bénéficier d'une assistance à long terme, en conservant un cluster exécutant une version mineure aussi longtemps que possible. Pour en savoir plus, consultez la page Obtenir un support à long terme avec le canal étendu.
Aucun canal (non recommandé) Alignement avec le canal standard Cette option n'est pas recommandée. Le plan de contrôle et les nœuds sont mis à niveau automatiquement en accord avec les canaux standard et stable. Lorsque vous devez désactiver les mises à niveau automatiques des nœuds au niveau d'un pool de nœuds, vous pouvez utiliser cette option de configuration. Vous pouvez également désactiver les mises à niveau automatiques des nœuds au niveau du cluster avec les canaux de publication. Pour en savoir plus, consultez la comparaison entre les clusters enregistrés et non enregistrés dans un canal de publication.

Lorsque vous inscrivez un cluster dans une version disponible, il est automatiquement mis à niveau à la date spécifiée dans la colonne Mise à niveau automatique du calendrier de mise en ligne de GKE ou après cette date.

Lorsqu'une version a accumulé suffisamment d'utilisation et qu'elle a fait la preuve de sa stabilité entre les différents clusters dans le canal rapide, elle est promue dans le canal standard. À terme, la version est promue dans le canal stable, qui ne reçoit que les mises à jour prioritaires. Chaque promotion, basée sur les performances observées pour les clusters exécutant cette version, indique un niveau progressif de stabilité et de préparation à la production.

Les correctifs de sécurité critiques sont appliqués à tous les canaux de publication afin de protéger vos clusters et l'infrastructure de Google. Dans de rares situations d'urgence, GKE peut mettre à niveau automatiquement les clusters vers des versions qui ne sont pas encore disponibles dans leur version disponible.

Versions disponibles dans un canal

Chaque version disponible propose plusieurs versions mineures. Ces versions ont atteint le niveau de qualification requis par le canal en question. Cet ensemble de versions disponibles inclut une version par défaut pour la création de clusters, sélectionnée parmi un ensemble de versions disponibles dans ce canal. Pour connaître les versions disponibles dans un canal de publication, suivez les instructions pour afficher les versions par défaut et les versions disponibles pour les canaux de publication.

  • Les nouvelles versions de correctif sont disponibles au moins une semaine avant d'être une cible de mise à niveau automatique pour tous les canaux.
  • De nouvelles versions mineures sont disponibles :
    • au moins deux semaines avant d'être utilisées comme cible de mise à niveau automatique pour le canal rapide.
    • au moins quatre semaines avant d'être utilisées comme cible de mise à niveau automatique pour les canaux Standard et Stable.

Vous pouvez tester une nouvelle version de GKE avant de mettre à niveau votre environnement de production. Par exemple, vous pouvez vous abonner aux notifications de mise à niveau pour être informé des nouvelles versions, puis mettre à niveau de manière proactive un environnement de préproduction vers la nouvelle version avant que celle-ci ne devienne la cible de mise à niveau automatique pour les clusters de votre environnement de production.

Si vous devez conserver un cluster sur une version spécifique, par exemple pour valider ou tester des versions plus récentes avant la mise à niveau, nous vous recommandons d'utiliser des exclusions de maintenance.

Une fois qu'une version mineure est disponible dans un canal de publication, elle le restera pour les clusters nouveaux ou existants jusqu'à ce qu'elle atteigne sa date de fin d'assistance.

Que se passe-t-il lorsqu'une version devient une cible de mise à niveau automatique dans un version disponible ?

GKE met automatiquement à niveau les clusters au fil du temps vers de nouvelles cibles de mise à niveau automatique. Lorsque de nouvelles cibles de mise à niveau automatique sont disponibles, GKE évalue si votre cluster spécifique doit être mis à niveau vers cette nouvelle version. GKE vérifie si votre cluster comporte des règles de maintenance ou d'autres contraintes qui empêchent les mises à niveau automatiques. Il n'ignorera pas ces raisons, sauf dans de rares situations d'urgence.

Vous pouvez trouver les cibles de mise à niveau automatique de vos clusters de plusieurs façons:

  • Pour obtenir les cibles de mise à niveau automatique pour un cluster spécifique, consultez Obtenir des informations sur les mises à niveau d'un cluster.
  • Le tableau des versions actuelles fournit la liste des cibles de mise à niveau automatique actuelles pour chaque version disponible. La version spécifique qui s'applique à votre cluster dépend de la version mineure du cluster et des contraintes spécifiques.
  • Les notes de version de GKE répertorient les nouvelles cibles de mise à niveau automatique pour les clusters qui exécutent des versions mineures spécifiques avec des mises à jour de version, telles que la note 2024-R33.

Si 10 jours se sont écoulés et que les mises à niveau automatiques n'ont pas démarré pour votre cluster, le délai peut être dû à l'une des raisons suivantes:

  • Votre cluster est temporairement inéligible pour les mises à niveau automatiques. Cela peut être dû au fait que :
    • Le cluster se situe en dehors de la période d'un intervalle de maintenance configuré.
    • Le cluster se situe dans la période d'une exclusion de maintenance.
    • Les mises à niveau automatiques sont suspendues car votre cluster utilise des fonctionnalités Kubernetes obsolètes qui sont supprimées dans la prochaine version mineure.
    • Le cluster a été automatiquement mis à niveau vers une version de correctif il y a moins de 24 heures.
    • Le cluster a été automatiquement mis à niveau vers une version mineure il y a moins de 30 jours et la cible de la mise à niveau automatique est une nouvelle version mineure.
  • GKE a suspendu le déploiement de la nouvelle cible de mise à niveau automatique pour des raisons techniques ou commerciales :
    • Des problèmes techniques ont été détectés dans la nouvelle version.
    • Un gel de la production est mis en place en raison d'une période commerciale critique, telle que le Black Friday.

La cible de mise à niveau automatique recommandée est la version vers laquelle GKE met progressivement à niveau vos clusters au fil du temps. De toutes les cibles de mise à niveau automatique d'un version disponible, GKE rapproche vos clusters de cette version lorsqu'il effectue des mises à niveau automatiques.

Au fil de plusieurs mises à niveau automatiques, à l'exception des contraintes empêchant les mises à niveau automatiques, GKE met à niveau vos clusters de manière progressive vers la cible de mise à niveau automatique recommandée du canal de publication, jusqu'à ce que votre cluster atteigne la cible. Une fois la cible atteinte, votre cluster utilise en continu la cible de mise à niveau automatique recommandée existante, puis passe à la nouvelle cible recommandée lorsqu'elle est publiée.

Quelle est la version par défaut ?

Lorsque vous créez un cluster dans un version disponible, il utilise par défaut la version de correctif par défaut pour la création de clusters dans le version disponible sélectionné. Toutefois, vous pouvez spécifier une version disponible différente lorsque vous créez un cluster dans le canal de publication.

Plusieurs versions mineures sont disponibles dans un version disponible, et la version par défaut peut parfois être l'une des cibles de mise à niveau automatique d'un version disponible.

Exécuter des versions de correctif à partir d'un canal plus récent

En plus des versions de correctif disponibles répertoriées pour un version disponible, vous pouvez exécuter des versions de correctifs provenant de versions plus récentes que celle sur laquelle votre cluster est enregistré si la version mineure est disponible dans le canal de publication du cluster et que vous utilisez la gcloud CLI ou l'API GKE.

Par exemple, supposons que les versions suivantes soient disponibles dans les canaux rapide et standard :

  • Rapide : 1.23.2-gke.700, 1.22.4-gke.1500
  • Standard : 1.21.4-gke.400, 1.22.1-gke.400

Un cluster enregistré dans le canal standard exécutant la version 1.22.1-gke.400 de GKE peut passer à la version 1.22.4-gke.1500, mais pas à la version 1.23.2-gke.700 car il s'agit d'une version mineure différente.

Pour passer à une version de correctif sur un canal plus récent, le plan de contrôle de votre cluster doit exécuter une version de correctif avec la même version mineure. Par exemple, si le cluster exécute 1.21.3-gke.200, vous devez d'abord mettre à niveau le cluster vers une version de correctif disponible dans son canal de publication actuel, 1.22.1-gke.400. Vous pouvez ensuite mettre à niveau le cluster vers la version 1.22.4-gke.1500.

Vous pouvez également créer un cluster qui exécute 1.22.4-gke.1500 et est enregistré dans le canal standard.

GKE maintient le cluster sur la version de correctif du canal le plus récent jusqu'à ce qu'une cible de mise à niveau automatique plus récente soit disponible dans le canal enregistré pour le cluster.

Découvrir les nouveautés d'un canal

Pour connaître les nouveautés disponibles dans un canal de publication, consultez les notes de version. Chaque canal de publication comporte des notes de version distinctes, en plus des notes de version générales.

Canal de publication Notes de version
Canal rapide HTML ou flux Atom.
Canal standard HTML ou flux Atom.
Canal stable HTML ou flux Atom.

Choisir le meilleur canal de publication pour votre cluster

Les canaux n'incluent que les versions en disponibilité générale de Kubernetes, et chaque canal représente un niveau de qualité et de maturité différent des versions de Kubernetes et de GKE. Le schéma suivant représente le cycle d'adoption des canaux de publication :

Cycle d'adoption des versions disponibles

Comme le montre ce schéma, les versions disponibles utilisent des versions au milieu du cycle d'adoption, y compris les utilisateurs de la première heure (canal rapide), la majorité précoce (canal standard) et la majorité (canal stable). La première partie du cycle d'adoption correspond aux innovateurs, qui testent les dernières fonctionnalités à l'aide de la version amont Kubernetes. La dernière partie du cycle d'adoption concerne la majorité tardive, qui utilise une version proche de l'abandon et doit passer à une version compatible.

Dans vos environnements de préproduction, utilisez le canal rapide pour les versions plus récentes dans lesquelles vous pouvez tester les fonctionnalités dès qu'elles sont en disponibilité générale.

Pour les charges de travail de production nécessitant une certaine maturité par rapport aux fonctionnalités les plus récentes, nous vous recommandons d'utiliser le canal standard (par défaut) ou la version stable.

  • Si vous avez besoin d'effectuer un suivi minutieux des nouvelles fonctionnalités, envisagez d'utiliser le canal standard, qui propose un compromis entre stabilité et actualisation de la version de l'OSS Kubernetes.
  • Si votre principale exigence est la maturité, en particulier pour les clusters de production, utilisez la version stable.

GKE met à niveau les clusters vers une version plus récente qui répond aux normes de qualité exigées par le canal. Toutefois, nous vous recommandons de mettre à jour vos clusters à l'avance. Cette approche présente les avantages suivants :

  • Meilleur contrôle des mises à niveau et alignement sur vos heures de travail.
  • Meilleure prévisibilité : GKE ignore les clusters de mise à niveau automatique qui atteignent la cible de la version (c'est-à-dire les clusters qui ont été mis à jour manuellement vers la version cible suivante). Les nœuds sont automatiquement mis à niveau vers la version recommandée dans le canal sélectionné, afin de s'aligner sur la version du plan de contrôle et de vous protéger des failles et décalages de versions non compatibles.

Bénéficier d'un support à long terme avec le canal étendu

GKE fournit une assistance à long terme pour les versions mineures de Kubernetes via le canal étendu. Avec ce canal, vous pouvez rester sur une version mineure pendant 24 mois maximum. Après la période d'assistance standard de 14 mois, votre cluster reçoit des correctifs de sécurité pendant environ 10 mois supplémentaires pendant la période d'assistance étendue.

Comment GKE met-il automatiquement à niveau les clusters dans le canal étendu ?

Pour les clusters enregistrés dans le canal étendu, GKE met automatiquement à jour les clusters de la manière suivante :

  • Pendant la période d'assistance standard : GKE met à niveau les clusters vers des versions de correctif plus récentes de la même version mineure en suivant la même fréquence que le canal standard.
  • Pendant la période d'assistance étendue : GKE continue de fournir des mises à jour de correctifs de sécurité pour la version mineure. Environ deux mois avant la fin de la période d'assistance étendue, GKE commence à mettre à niveau les clusters vers la prochaine version mineure, sauf si le cluster utilise des fonctionnalités ou des API obsolètes. Vous pouvez utiliser des exclusions de maintenance pour éviter les mises à niveau de versions mineures jusqu'à la fin de l'assistance étendue.
  • À la fin de l'assistance étendue : GKE met à niveau tous les clusters qui exécutent toujours la version mineure désormais obsolète, indépendamment des problèmes bloquants. Vous ne pouvez pas configurer d'exclusions de maintenance après cette date.

Pour en savoir plus sur les différentes périodes de disponibilité et sur les mises à niveau fournies par GKE pendant la période d'assistance étendue, consultez la section Cycle de vie d'une version mineure de GKE.

Limites concernant l'enregistrement d'un cluster dans le canal étendu

Consultez les limites suivantes pour les clusters inscrits dans le canal étendu:

Tarifs de l'assistance étendue

Si vous souhaitez enregistrer un cluster dans le canal Extended, assurez-vous d'avoir consulté les tarifs de l'assistance étendue. Vous pouvez enregistrer un cluster dans le canal étendu sans frais supplémentaires si le projet a activé GKE Enterprise. Ou pour les clusters de l'édition GKE Standard, des frais basés sur l'utilisation s'appliquent lorsque votre cluster est inscrit dans le canal étendu et que la version mineure de votre cluster entre dans la période d'assistance étendue.

Bonnes pratiques pour le canal étendu

Consultez les scénarios suivants pour comprendre comment utiliser le canal étendu afin de minimiser les interruptions causées par les mises à niveau de versions mineures.

Les scénarios compatibles nécessitent des actions manuelles au fil du temps pour tirer le meilleur parti du canal. Nous vous déconseillons d'enregistrer un cluster dans le canal sans prévoir de passer à la version mineure suivante, car GKE finira par le mettre à niveau vers des versions mineures plus récentes avec la même fréquence que les autres canaux. Votre cluster pourrait ainsi entraîner des coûts plus élevés et recevoir des nouvelles fonctionnalités en dernier.

Scénarios compatibles et non compatibles

Pour en savoir plus sur les scénarios compatibles et non compatibles, consultez le tableau suivant et la section Utiliser la version étendue lorsque vous avez besoin d'un support à long terme. Une coche () indique un scénario compatible :

Scénario de mise à niveau Compatible Résumé Durée entre les modifications de version mineure Action manuelle requise
Rester temporairement sur une version mineure plus longtemps Restez sur une version mineure pour atténuer un problème empêchant les mises à niveau. Même fréquence moyenne, avec interruption pour une durée supplémentaire sur une version mineure.
  • Déplacer temporairement un cluster vers et depuis le canal étendu.
  • Mettez manuellement à niveau le cluster vers la nouvelle version mineure lorsque vous êtes prêt.
Mettre à niveau manuellement la version mineure une à deux fois par an Obtenez de nouvelles fonctionnalités mais avec des mises à niveau mineures moins fréquentes, lorsque c'est optimal pour les charges de travail du cluster. Une à deux fois par an.
  • Mettez à niveau manuellement le cluster vers une version mineure plus récente.
Ne rien faire et recevoir des mises à niveau mineures à la même fréquence Vous recevez les mises à niveau de versions mineures à la même fréquence que les autres canaux, et les nouvelles fonctionnalités le plus tard possible. Tous les quatre mois, en moyenne.
  • Surveiller les mises à niveau automatiques des versions mineures à partir de versions non compatibles

Clusters non enregistrés dans un version disponible

Nous ne recommandons pas cette option de configuration en raison des limites liées aux clusters non enregistrés dans des canaux de publication, mais vous pouvez choisir de ne pas enregistrer de cluster Standard dans un version disponible (appelé aucun canal et anciennement statique). N'utilisez cette option que si certains pools de nœuds ne peuvent pas être mis à niveau automatiquement et que vous devez mettre à niveau manuellement ces nœuds. Si votre cluster n'est pas enregistré dans une version disponible, vous pouvez désactiver la mise à niveau automatique des nœuds pour les pools de nœuds sélectionnés. Avec les canaux de publication, vous pouvez obtenir le même résultat au niveau du cluster pour tous les pools de nœuds. Toutefois, quel que soit le version disponible, tous les plans de contrôle des clusters sont automatiquement mis à niveau. Lorsqu'une version atteint la fin de sa période de compatibilité, les plans de contrôle et les nœuds du cluster sont automatiquement mis à niveau.

Si vous souhaitez empêcher les mises à niveau automatiques pour l'ensemble du cluster standard ou tous ses pools de nœuds, nous vous recommandons d'utiliser une exclusion de maintenance lorsque votre cluster est enregistré dans une version disponible. Les exclusions de maintenance vous permettent de désactiver temporairement les mises à niveau automatiques des nœuds pour tous les pools de nœuds, tandis que vous pouvez les désactiver au niveau du pool de nœuds si votre cluster n'est pas enregistré dans une version disponible.

Comparaison entre les clusters enregistrés et non enregistrés dans un version disponible

Consultez le tableau suivant pour comprendre les similitudes et les différences entre l'enregistrement et l'enregistrement de votre cluster dans une version disponible :

Caractéristique Cluster enregistré dans une version disponible Cluster non enregistré dans une version disponible
Comportement des mises à niveau partagées
Modifier le calendrier Alignement avec le canal de publication correspondant
  • Même date de début de mise à niveau automatique que la version stable pour les versions mineures
  • Mêmes versions mineures disponibles, versions de mise à niveau automatique de correctifs et versions par défaut que le canal standard
  • Mêmes versions de correctifs disponibles que le canal rapide pour les versions mineures disponibles dans le canal standard
Contrôle de l'interruption du pool de nœuds
Intervalles de maintenance Disponible Disponible
Exclusions de maintenance Champs d'application d'exclusion de maintenance disponibles :
  • "Aucune mise à niveau" (30 jours)
  • "Aucune mise à niveau mineure" (jusqu'à la fin de la période de compatibilité)
  • "Aucune mise à niveau mineure ni de mise à niveau des nœuds" (jusqu'à la fin de la compatibilité)
 Limité au champ d'application "Aucune mise à niveau" (30 jours)
Séquençage du déploiement Disponible avec les séquences basées sur le parc et sur le champ d'application Non disponible
Support à long terme Disponible uniquement avec le canal de publication étendu Non disponible
Autopilot Disponible Non disponible

Différences entre les clusters utilisant un canal rapide et les clusters alpha

Les clusters créés à l'aide d'un canal de publication rapide ne sont pas des clusters alpha. Les différences sont les suivantes :

  • Les clusters qui utilisent la fonctionnalité de canal de publication peuvent être mis à jour. La mise à jour automatique est activée et ne peut pas être désactivée. Les clusters alpha ne peuvent pas être mis à jour.
  • Les clusters qui utilisent la fonctionnalité de canal de publication n'expirent pas. Les clusters alpha expirent au bout de 30 jours.
  • Les API Alpha Kubernetes ne sont pas activées sur les clusters utilisant la fonctionnalité de canal de publication.

Étapes suivantes