À propos des versions disponibles

Autopilot Standard

---

Utilisez les canaux de publication pour Google Kubernetes Engine (GKE) afin de choisir des versions pour vos clusters avec l'équilibre choisi entre la disponibilité des fonctionnalités et la 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 modifier 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 vie, 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 décrit les propriétés des versions disponibles, chacune offrant un compromis entre la disponibilité des fonctionnalités et l'évolution des mises à jour. 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.

Version	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. Attention :Comme le canal rapide fournit les versions les plus récentes de GKE, ces versions sont exclues du contrat de niveau de service GKE et peuvent contenir des problèmes sans solutions de contournement connues.
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 assez 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 de 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

Remarque : Les calendriers exacts des versions dépendent de plusieurs facteurs, y compris le calendrier des versions Open Source et des correctifs. Ils sont donc susceptibles d'être modifiés. Pour vous tenir informé des dernières nouveautés, consultez les notes de version de GKE ou abonnez-vous au flux RSS de votre canal.

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 une version par défaut, sélectionnée parmi un ensemble de versions disponibles pour ce canal. Ces versions ont atteint le niveau de qualification requis par le canal en question. Au fil du temps, GKE met automatiquement à niveau les clusters vers la version par défaut.

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

Pour les versions 1.19 et ultérieures, 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 de vie.

Remarque : Lorsque vous créez un cluster dans un canal de publication, si vous spécifiez une version antérieure à la version par défaut dans ce canal de publication, GKE peut automatiquement mettre à niveau le cluster vers la version par défaut. Si vous souhaitez empêcher temporairement la mise à niveau automatique du cluster lorsque vous sélectionnez le nouveau canal, procédez comme suit : configurez une exclusion de maintenance avant de sélectionner le nouveau canal.

Afficher les versions par défaut et disponibles pour les canaux de publication

Remarque : Les versions antérieures à la version par défaut d'un canal ne sont visibles que via gCloud CLI et l'API Kubernetes Engine.

Pour afficher les versions par défaut et disponibles pour les canaux de publication, exécutez la commande suivante en remplaçant COMPUTE_ZONE par votre zone de calcul :

gcloud container get-server-config --format "yaml(channels)" --zone COMPUTE_ZONE

Pour afficher les versions disponibles pour les clusters non enregistrés dans une version disponible, exécutez cette commande équivalente pour les versions disponibles en remplaçant "yaml(channels)" dans la commande par "yaml(validMasterVersions)".

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 disponibles répertoriées pour un canal de publication, GKE fournit un accès limité aux versions de correctif des canaux de publication moins matures. Un cluster enregistré dans un canal de publication peut utiliser les versions de correctif d'un canal plus récentsi la version mineure dans le canal le plus récent est identique à la version mineure 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.

Remarque: La création ou la mise à niveau d'un cluster vers une version de correctif disponible dans un canal de publication plus récent n'est possible qu'à partir de gcloud CLI ou de l'API GKE.

Le cluster restera sur la version de correctif du canal moins mature 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.

Enregistrer un cluster dans un canal de publication

Cette section explique comment sélectionner un canal de publication pour les nouveaux clusters ou pour les clusters existants qui n'utilisaient pas auparavant de canal de publication. Vous pouvez également modifier la version disponible d'un cluster existant, qui est déjà inscrit dans une version disponible.

Cette modification ne nécessite aucun temps d'arrêt. Cependant, étant donné que GKE peut avoir des mises à niveau automatiques différentes disponibles dans la version disponible, nous vous recommandons d'utiliser des intervalles de maintenance et des exclusions pour contrôler la chronologie des mises à niveau.

Enregistrer de nouveaux clusters

Vous pouvez créer et enregistrer un nouveau cluster dans un canal de publication à l'aide de gCloud CLI ou de la console Google Cloud. Par défaut, les nouveaux clusters sont enregistrés automatiquement dans le canal de publication Standard.

Console

Pour les clusters GKE Standard, vous pouvez choisir de spécifier un autre canal lors de la création dans la console Google Cloud.

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

   Accéder à Google Kubernetes Engine

2. Cliquez sur Créer.

3. Dans la section Standard, cliquez sur Configurer.

4. Sous Version du plan de contrôle, l'option Canal de publication est sélectionnée par défaut.

5. Dans la liste déroulante Version disponible, sélectionnez une version disponible dans laquelle enregistrer le cluster ou conservez par défaut la version standard.

   Remarque : Les fonctionnalités de mise à niveau automatique des nœuds et de réparation automatique des nœuds sont activées par défaut. La mise à niveau automatique des nœuds ne peut pas être désactivée pour un cluster abonné à un canal de publication. La réparation automatique des nœuds peut être désactivée, mais nous vous recommandons de conserver la configuration par défaut.

6. Continuez à créer le cluster selon la procédure de votre choix.

7. Cliquez sur Créer.

gcloud

Pour créer et enregistrer un cluster Standard dans un canal de publication spécifique, exécutez la commande suivante :

gcloud container clusters create CLUSTER_NAME \
    --zone COMPUTE_ZONE \
    --release-channel CHANNEL \
    ADDITIONAL_FLAGS

Pour créer et enregistrer un cluster Autopilot dans un canal de publication spécifique, exécutez la commande suivante :

gcloud container clusters create-auto CLUSTER_NAME \
    --region=COMPUTE_REGION
    --release-channel CHANNEL \
    ADDITIONAL_FLAGS

Remplacez les éléments suivants :

• CLUSTER_NAME : nom de votre nouveau cluster
• Pour les clusters régionaux, utilisez l'option --region COMPUTE_REGION et spécifiez la région pour votre cluster.
• Pour les clusters zonaux, utilisez l'option --region COMPUTE_ZONE et spécifiez la zone pour votre cluster.
• CHANNEL : type de canal de publication (rapid, regular ou stable).
• ADDITIONAL_FLAGS : regroupe toutes les options supplémentaires que vous devez spécifier lors de la création de votre cluster. Pour obtenir la liste complète des options facultatives pour les clusters Standards, consultez la documentation sur gcloud container clusters create. Pour obtenir la liste complète des options facultatives pour les clusters Autopilot, consultez la documentation sur gcloud container clusters create-auto.

Vous pouvez également créer un cluster avec une version spécifique à l'aide de l'option --cluster-version. Si vous ne spécifiez pas de canal de publication, GKE enregistre votre cluster dans le canal de publication le plus mature lorsque cette version est disponible.

Si vous ne spécifiez pas la version disponible ou la version du cluster, le cluster utilise par défaut la version disponible regular sur la version par défaut.

Enregistrer des clusters existants

Vous pouvez enregistrer un cluster existant dans un canal de publication, à condition que la version du plan de contrôle du cluster soit disponible dans le canal de publication cible. Pour vérifier si la version du plan de contrôle de votre cluster est disponible dans la version disponible cible, affichez les versions par défaut et disponibles pour les versions disponibles. Pour en savoir plus sur l'alignement de la version du plan de contrôle de votre cluster avec les versions disponibles pour votre canal de publication cible, consultez la page Sélectionner un nouveau canal de publication.

Pour vous inscrire, mettez à jour le canal de publication du cluster sur la cible CHANNEL.

Remarque : GKE ne met pas immédiatement à niveau le plan de contrôle et les nœuds du cluster vers la version disponible par défaut lors de l'inscription. Au lieu de cela, ils sont mis à niveau progressivement par le processus de mise à niveau automatique de GKE.

Trouver le canal de publication de votre cluster

Vous pouvez déterminer le canal de publication de votre cluster à l'aide de gcloud CLI ou de la console Google Cloud.

Remarque : Votre cluster doit être enregistré dans un canal de publication pour que celui-ci s'affiche.

Console

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

   Accéder à Google Kubernetes Engine

2. Cliquez sur le nom du cluster que vous souhaitez inspecter.

3. Sous Paramètres de base du cluster, vérifiez la valeur du champ Canal de publication (par exemple, Canal standard).

gcloud

gcloud container clusters describe CLUSTER_NAME \
    --zone COMPUTE_ZONE --format="value(releaseChannel.channel)"

Remplacez les éléments suivants :

• CLUSTER_NAME : nom du cluster
• COMPUTE_ZONE : zone de calcul de votre cluster.

Modifier le canal de publication de votre cluster

Vous pouvez modifier le canal de publication de votre cluster si la version du plan de contrôle est disponible dans le canal de publication cible. Vous devrez peut-être mettre à niveau le plan de contrôle de votre cluster vers une version disponible.

Pour vérifier si la version du plan de contrôle de votre cluster est disponible dans le canal de publication cible, affichez les versions par défaut et disponibles pour les canaux de publication. La version doit être disponible dans le canal cible.

• Si la version du plan de contrôle de votre cluster est déjà disponible dans le canal de publication cible, vous pouvez sélectionner le nouveau canal de publication.
• Si la version du plan de contrôle de votre cluster n'est pas disponible dans le canal de publication, vous pouvez mettre à niveau le plan de contrôle du cluster vers une version disponible. Si le canal cible ne propose que des versions antérieures, vous pouvez égalementrétrograder le cluster, à condition que la version cible soit une version de correctif antérieure de la même version mineure.

Pour sélectionner un nouveau canal de publication, mettez à jour le canal de publication du cluster sur le CHANNEL cible. Si vous souhaitez empêcher temporairement la mise à niveau automatique du cluster lorsque vous sélectionnez le nouveau canal, procédez comme suit : configurez une exclusion de maintenance avant de sélectionner le nouveau canal.

Si vous ne pouvez pas sélectionner le canal de publication cible car votre cluster exécute une version qui n'est pas disponible dans cette version, vous pouvez créer un cluster dans la version cible et migrer vos charges de travail. Si vous devez utiliser votre cluster existant, procédez comme suit:

1. Configurez une exclusion de maintenance avec le champ d'application "Aucune mise à niveau mineure".
2. Attendez que le canal de publication cible rende disponible la version mineure de Kubernetes de votre cluster.
3. Enregistrez le cluster existant dans le canal de publication cible.

Mettre à jour le canal de publication du cluster

Vous pouvez modifier la version disponible de votre cluster à l'aide de gcloud CLI ou de la console Google Cloud.

Console

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

   Accéder à Google Kubernetes Engine

2. Cliquez sur le nom du cluster que vous souhaitez inspecter.

3. Sous Paramètres de base du cluster, dans le champ Version disponible, cliquez sur .

4. Dans la liste déroulante Version disponible, sélectionnez la version disponible cible.

5. Lisez et acceptez l'avertissement en sélectionnant J'accepte les conditions.

6. Cliquez sur Save Changes (Enregistrer les modifications).

gcloud

Modifiez la propriété du canal de publication d'un cluster existant:

gcloud container clusters update CLUSTER_NAME \
  --release-channel CHANNEL

Remplacez les éléments suivants :

• CLUSTER_NAME : nom du cluster
• CHANNEL: canal de publication cible, qui peut être rapid, regular, stable ou None.

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 de limites concernant les clusters qui ne sont pas 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. Vous devez mettre à niveau ces nœuds manuellement. 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.

Avertissement : Si vous désactivez les mises à niveau automatiques des nœuds pour un pool de nœuds, vous devez les mettre à niveau manuellement pour vous assurer que votre cluster respecte les règles de compatibilité de la version de Kubernetes et du décalage de version et utilise des versions GKE compatibles. Le non-respect de ces règles de version entraînera une incompatibilité entre le plan de contrôle et les nœuds au fil du temps, et risque de dégrader la compatibilité et la fiabilité de votre cluster. Pour en savoir plus, consultez les questions fréquentes sur la compatibilité des versions.

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 de la mise à niveau partagée	GKE met automatiquement à niveau le plan de contrôle du cluster et, par défaut, met automatiquement à niveau les nœuds lorsque de nouvelles mises à niveau automatiques sont planifiées, en suivant le calendrier des lancements GKE GKE met automatiquement à niveau le plan de contrôle et les nœuds du cluster en fin de vie.
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 et correctives Mêmes versions mineures disponibles 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	Mises à jour automatiques des nœuds par défaut. Vous pouvez désactiver les mises à niveau automatiques des nœuds au niveau du cluster pendant six mois au maximum en créant une exclusion de maintenance avec n'importe quel type de champ d'application Vous pouvez désactiver la réparation automatique de nœuds pour un pool de nœuds de cluster standard.	Mises à jour automatiques des nœuds par défaut. Vous pouvez désactiver les mises à niveau automatiques des nœuds au niveau du pool de nœuds. Vous devez vous assurer que votre cluster respecte les règles de version et de décalage de version Vous pouvez désactiver les mises à niveau des nœuds au niveau du cluster pendant 30 jours maximum en créant une exclusion de maintenance avec le champ d'application "Aucune mise à niveau"
Intervalles de maintenance	Disponible	Disponible
Exclusions de maintenance	Champs d'application de l'exclusion de maintenance disponibles : "Aucune mise à niveau" (30 jours) "Aucune mise à jour mineure" (6 mois) "Aucune mise à niveau mineure ni de mise à niveau des nœuds" (6 mois)	Limité au champ d'application "Aucune mise à niveau" (30 jours)
Séquençage du déploiement	Disponible avec des séquences basées sur les parcs et les champs d'application	Non disponible
Autopilot	Disponible	Non disponible

Se désabonner d'un canal de publication

Remarque : Pour les clusters Autopilot, vous ne pouvez pas vous désabonner d'un canal de publication.

Vous pouvez vous désabonner d'un cluster standard à partir d'une version disponible à l'aide de la console Google Cloud, de gcloud CLI ou de l'API Kubernetes Engine. Vous pouvez également spécifier que vous ne souhaitez pas enregistrer votre cluster dans un canal de publication lors de sa création.

Console

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

   Accéder à Google Kubernetes Engine

2. Cliquez sur le nom du cluster que vous souhaitez inspecter.

3. Sous Paramètres de base du cluster, dans le champ Version disponible, cliquez sur .

4. Cochez la case d'option Version statique.

5. Lisez et acceptez l'avertissement en sélectionnant J'accepte les conditions.

6. Cliquez sur Save Changes (Enregistrer les modifications).

gcloud

Mettez à jour le canal de publication du cluster sur une valeur None :

gcloud container clusters update CLUSTER_NAME \
  --release-channel None

API

Spécifiez "releaseChannel": { "channel": UNSPECIFIED} lorsque vous créez ou mettez à jour un cluster.

Avertissements

Tenez compte des points suivants lors de l'utilisation des canaux de publication.

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

Les clusters créés à l'aide de la version précoce 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

• Obtenez plus d'informations sur la mise à niveau 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 les environnements avec le séquençage du déploiement.