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 canal de publication, car cela vous offre le plus de contrôle en ce qui concerne le champ d'application des exclusions de maintenance, en empêchant temporairement 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 section Quand ne pas enregistrer votre cluster dans une version disponible.
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 ? |
|---|---|---|
| Rapide | 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 obtenir un support à 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. Lorsque vous devez désactiver les mises à niveau automatiques des nœuds au niveau du pool de nœuds, vous pouvez utiliser cette option de configuration. Le plan de contrôle et les nœuds sont mis à niveau automatiquement en accord avec les canaux standard et stable. Pour en savoir plus, consultez la section Quand ne pas enregistrer votre cluster 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 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.
Versions disponibles dans un canal
Chaque canal de publication 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 appliquées par défaut à tous les canaux.
- De nouvelles versions mineures sont disponibles :
- au moins deux semaines avant d'être utilisées par défaut pour le canal rapide.
- au moins quatre semaines avant d'être utilisées par défaut 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 version par défaut.
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 nouvelle version devient la version par défaut dans un canal de publication ?
Lorsqu'une nouvelle version de GKE devient la version par défaut dans un canal de publication :
- Les nouveaux clusters sont créés à l'aide de la nouvelle version par défaut dans le canal de publication sélectionné.
- Les clusters éligibles existants sont automatiquement mis à niveau dans les 10 jours à partir du moment où la nouvelle version devient la version par défaut dans son canal de publication.
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 nouvelle version par défaut est une nouvelle version mineure.
- GKE a suspendu le déploiement de la nouvelle version par défaut 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.
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 canal de publication, 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.
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.
.Le cluster restera sur la version de correctif du canal le plus récent jusqu'à ce que la version par défaut du canal dans lequel il est enregistré devient supérieure à sa version. Le cluster sera alors automatiquement mis à niveau vers la version par défaut.
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 :
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 compatibilité à 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 l'assistance étendue, GKE commence à mettre à niveau les clusters vers la version mineure suivante, 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
Vous ne pouvez enregistrer que des clusters standards exécutant la version 1.27 ou ultérieure dans le canal étendu. Le plan de contrôle et les nœuds du cluster doivent exécuter la version 1.27 ou ultérieure.
Vous ne pouvez pas enregistrer un cluster dans le canal étendu lorsque vous utilisez les fonctionnalités suivantes :
- Mode de cluster Autopilot
- Clusters alpha
- API Kubernetes explicitement activées (version bêta)
- Passerelle
- Pools de nœuds Windows Server
- Options de configuration sysctl personnalisées
- Sauvegarde pour GKE
- Config Connector
- Les fonctionnalités multicluster suivantes :
Tarifs de l'assistance étendue
Si vous souhaitez enregistrer un cluster dans le canal étendu, 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 une action manuelle 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é | Délai entre les modifications de versions mineures | Action manuelle requise |
|---|---|---|---|---|
| Conserver temporairement une version mineure plus longtemps | Conservez une version mineure pour limiter un problème empêchant les mises à niveau. | Même fréquence moyenne, avec une interruption pour une durée supplémentaire sur une version mineure. |
|
|
| Mise à niveau manuelle d'une 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. |
|
|
| Ne rien faire et recevoir des mises à niveau mineures à la même fréquence | Bénéficiez de mises à niveau de versions mineures à la même fréquence que les autres canaux, et de nouvelles fonctionnalités le plus tard possible. | Tous les quatre mois, en moyenne. |
|
Quand ne pas enregistrer votre cluster dans une version disponible
Vous pouvez choisir de ne pas enregistrer de cluster Standard dans un canal de publication (appelé "aucun canal" et "statique"). En raison des limites liées aux clusters non enregistrés dans les canaux de publication, 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.
Si vous souhaitez empêcher temporairement les mises à niveau automatiques pour l'ensemble du cluster ou tous ses nœuds, utilisez 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.
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 |
|
| 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 :
|
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.
Étape suivante
- Utiliser les canaux de publication
- Obtenez plus d'informations sur la mise à jour des clusters.
- Découvrez comment recevoir des notifications de mise à niveau des clusters.
- Découvrez comment gérer les mises à niveau automatiques des clusters dans tous les environnements grâce au séquençage du déploiement.