Canaux de publication de Cloud Service Mesh géré

Cloud Service Mesh publie régulièrement de nouvelles versions 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 Cloud Service Mesh sont liés aux canaux de publication Google Kubernetes Engine (GKE). Google gère automatiquement la version et la fréquence de mise à niveau de chaque canal de publication.

Ce document explique comment comparer les canaux de publication et comment 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
Rapide Après chaque version de Cloud Service Mesh Obtenez la dernière version de Cloud Service Mesh le plus tôt possible et exploitez les nouvelles fonctionnalités dès qu'elles sont incluses dans une version. 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. Le canal rapide est idéal pour tester les nouvelles versions et API 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 vous tenir informé des dernières informations, ajoutez l'URL des notes de version de Cloud Service Mesh à votre lecteur de flux ou ajoutez directement l'URL du flux : https://cloud.google.com/feeds/servicemesh-release-notes.xml.

Lorsqu'une version mineure de Cloud Service Mesh géré a été suffisamment utilisée et qu'elle a fait preuve de stabilité 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 au fil du temps dans les canaux standard et stable. 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 son canal de cluster GKE.

Canal GKE Chaîne Cloud Service Mesh
Rapide Rapide
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 ultérieurement le canal du cluster GKE, vous conservez le canal Cloud Service Mesh d'origine.

Le tableau suivant indique le mappage actuel entre les canaux et les versions de Cloud Service Mesh :

Canal Version de Cloud Service Mesh
Rapide 1.21
Standard 1.20
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é. Le service 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 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 sont à 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