Canaux de publication de Cloud Service Mesh géré

Cloud Service Mesh publie régulièrement des mises à jour pour fournir des mises à jour de sécurité, résoudre les problèmes connus et introduire de nouvelles fonctionnalités. Les canaux de publication permettent de trouver un équilibre entre la stabilité et l'ensemble des fonctionnalités de la version Cloud Service Mesh. Les canaux de publication de Cloud Service Mesh sont associés aux canaux de publication de Google Kubernetes Engine (GKE). Google gère automatiquement la version et la fréquence de mise à jour de chaque canal de publication.

Ce document explique comment comparer les canaux de publication et mettre à jour les proxys non gérés.

Canaux de publication disponibles

Les canaux de publication suivants sont disponibles. Chaque canal offre un compromis entre la disponibilité des fonctionnalités et l'évolution des mises à jour. Les fonctionnalités de chaque canal ont un niveau de maturité différent. 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.

Canal Nouvelle disponibilité de Cloud Service Mesh géré Propriétés
Élasticité Après chaque version de Cloud Service Mesh Obtenez la dernière version de Cloud Service Mesh le plus tôt possible et profitez des nouvelles fonctionnalités dès leur publication. Votre plan de contrôle est fréquemment mis à jour pour rester sur la dernière version de correctif disponible et proposer de nouvelles fonctionnalités. Il est préférable d'utiliser le canal rapide pour tester les versions et les API les plus récentes de Cloud Service Mesh dans des environnements de préproduction.
Standard Le canal Rapide est promu à Standard* Accédez aux fonctionnalités de Cloud Service Mesh et d'Istio assez rapidement après leur lancement, 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 versions. Il s'agit du canal que nous recommandons pour la plupart des utilisateurs.
Stable Le canal Standard est promu à Stable* Donnez la priorité à la stabilité plutôt qu'aux nouvelles fonctionnalités. Les modifications et les nouvelles versions de ce canal sont déployées en dernier, après leur validation sur les canaux rapide et standard, vous permettant ainsi de dégager davantage de temps pour la validation.
*Le calendrier de promotion au canal suivant dépend de plusieurs facteurs, dont la version Open Source d'Istio, la version d'Anthos et le calendrier des correctifs. Il est donc susceptible d'être modifié. Pour rester informé des dernières nouveautés, ajoutez l'URL des notes de version de Cloud Service Mesh à votre lecteur de flux, ou ajoutez l'URL du flux directement : https://cloud.google.com/feeds/servicemesh-release-notes.xml

Lorsqu'une version mineure de Cloud Service Mesh géré présente une utilisation suffisante et une stabilité démontrée dans le canal rapide, elle est promue dans le canal standard. À terme, la version mineure est promue dans le canal stable, qui ne reçoit que les mises à jour prioritaires et les correctifs de sécurité. Chaque promotion, basée sur les performances observées du plan de contrôle exécutant cette version, indique un niveau progressif de stabilité et de préparation à la production.

Tous les canaux sont basés sur une version en disponibilité générale (bien que ce ne soit pas toujours le cas des fonctionnalités individuelles, comme indiqué). Les nouvelles versions de Cloud Service Mesh sont d'abord publiées dans le canal rapide, puis promues dans les canaux standard et stable au fil du temps. Vous pouvez ainsi choisir un canal qui répond à vos besoins d'entreprise, de stabilité et de fonctionnalité.

Le canal Cloud Service Mesh de votre cluster est déterminé par le canal de votre cluster GKE.

Canal GKE Canal Cloud Service Mesh
Élasticité Élasticité
Standard Standard
Stable Stable
(aucune chaîne) Standard

Versions de Cloud Service Mesh par canal

Votre canal Cloud Service Mesh est déterminé par le canal de votre cluster GKE au moment du provisionnement de Cloud Service Mesh géré. Si vous modifiez le canal du cluster GKE ultérieurement, vous conservez le canal Cloud Service Mesh d'origine.

Le tableau suivant montre le mappage entre le canal actuel et la version de Cloud Service Mesh:

Canal Version de Cloud Service Mesh
Élasticité 1.19
Standard 1.19
Stable 1.19

Chaîne par défaut

Dans un service Cloud Service Mesh nouvellement installé sur lequel un seul canal géré est installé dans un cluster, ce canal sera le canal par défaut de ce cluster.

Si le tag par défaut est configuré sur les clusters avec une installation Istio ou Cloud Service Mesh existante, il doit être pointé vers la révision gérée. Otherwise, no action is required.

Vous pouvez utiliser le libellé istio-injection=enabled en tant qu'alias qui pointe vers les autres libellés que vous utilisez pour le canal, tels que la révision par défaut. Chaque fois que notre documentation indique d'utiliser l'étiquette d'espace de noms istio.io/rev pour l'injection, il est possible d'utiliser l'étiquette istio-injection=enabled à la place.

Libellés d'injection

Pour permettre à Cloud Service Mesh de gérer les charges de travail dans un espace de noms donné, celui-ci doit comporter un libellé correspondant au canal installé. Cloud Service Mesh géré accepte deux types de libellés:

  • Les libellés de révision standards, à savoir asm-managed-stable, asm-managed, asm-managed-rapid, correspondant aux canaux stable, regular et rapid.
  • Le libellé d'injection par défaut (par exemple, istio-injection=enabled), correspondant au canal par défaut de ce cluster. L'utilisation du libellé d'injection par défaut simplifie la migration entre les révisions. C'est notamment le cas lors de la migration à partir d'Istio OSS ou de Cloud Service Mesh non géré vers Cloud Service Mesh géré, car il n'est pas nécessaire d'ajouter un libellé individuellement pour chaque espace de noms. Chaque fois que la documentation de Cloud Service Mesh indique d'utiliser le libellé d'espace de noms istio.io/rev pour l'injection, il est possible d'utiliser le libellé istio-injection=enabled à la place.

D'autres exemples de libellés d'injection incluent l'ajout de libellés sur les charges de travail avec sidecar.istio.io/inject (couramment utilisé pour les passerelles) et istio.io/rev, qui fonctionne à la fois pour les espaces de noms et les charges de travail.

Libellés d'injection par défaut

Pour appliquer le libellé d'injection par défaut à un espace de noms :

kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev- --overwrite

Libellés de révision

Comme les autres libellés Kubernetes, un libellé de révision est une paire clé-valeur. La clé d'un libellé de révision est toujours istio.io/rev, mais la valeur varie. Pour sélectionner un canal de publication, vous devez appliquer l'un des noms de révision suivants à vos espaces de noms :

Nom de la révision Canal
asm-managed Standard
asm-managed-rapid Version précoce
asm-managed-stable Stable

Par exemple, pour appliquer le canal de publication standard à un espace de noms, procédez comme suit :

kubectl label namespace NAMESPACE istio.io/rev=asm-managed --overwrite

Nous vous recommandons d'utiliser le même canal de publication que celui du cluster.

Pour connaître le canal de publication utilisé par un espace de noms, procédez comme suit :

kubectl get namespace NAMESPACE -o jsonpath='{.metadata.labels.istio\.io/rev}{"\n"}'

Mettre à jour les proxys non gérés

Après chaque nouvelle version de Cloud Service Mesh, redémarrez les proxys non gérés pour vos services et passerelles. Bien que le maillage de services fonctionne correctement lorsque le plan de contrôle et les proxys utilisent des versions différentes, nous vous recommandons de mettre à jour les proxys afin qu'ils soient configurés avec la nouvelle version de Cloud Service Mesh.

  1. Vérifiez les versions du plan de contrôle et des proxys.

  2. Si la version du plan de contrôle est plus récente que la version des proxys, redémarrez les proxys non gérés pour vos services et vos passerelles.

    kubectl rollout restart deployment -n NAMESPACE