Canaux de publication gérés pour Cloud Service Mesh

{version_1.0.1 d

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 équilibrent la stabilité entre la stabilité et l'ensemble des fonctionnalités de la version de Cloud Service Mesh. Les versions disponibles de Cloud Service Mesh sont liées aux versions disponibles de Google Kubernetes Engine (GKE). Google gère automatiquement la version et la fréquence de mise à niveau pour chaque canal de publication.

Ce document compare les versions disponibles et explique 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 publication de Cloud Service Mesh Obtenez la dernière version de Cloud Service Mesh dès que possible et soyez en mesure d'utiliser 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. La canal rapide est idéale 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 avec une version qualifiée sur une plus longue période. 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 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é est utilisée de manière suffisante et qu'elle a démontré sa 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 dans les versions 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 son cluster GKE.

Canal GKE Canal Cloud Service Mesh
Rapide Rapide
Standard Standard
Stable Stable
(aucun canal) 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 présente le mappage actuel entre le canal actuel et la version de Cloud Service Mesh:

Canal Version de Cloud Service Mesh
Rapide
Standard
Stable

Chaîne par défaut

Dans un maillage de services Cloud Service Mesh nouvellement installé où un seul canal géré est installé dans un cluster, ce canal est le canal par défaut pour ce cluster.

Si les clusters avec une installation Istio ou Cloud Service Mesh existante ont le tag par défaut configuré, celui-ci doit pointer vers la révision gérée. Otherwise, no action is required.

Vous pouvez utiliser le libellé istio-injection=enabled comme 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é, l'espace de noms doit comporter une étiquette correspondant au canal installé. Le service géré Cloud Service Mesh 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.
  • Étiquette 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. Par exemple, lors de la migration d'Istio OSS ou d'un service Cloud Service Mesh non géré vers un service Cloud Service Mesh géré, car il n'est pas nécessaire d'étiqueter à nouveau chaque espace de noms individuellement. 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 de 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