Managed Anthos Service Mesh release channels

Anthos Service Mesh releases updates often, to deliver security updates, fix known issues, and introduce new features. Release channels balance between stability and the feature set of the Anthos Service Mesh version. Anthos Service Mesh release channels are tied to Google Kubernetes Engine (GKE) release channels. Google automatically manages the version and upgrade cadence for each release channel.

This document covers comparisons of release channels, and how to update unmanaged proxies.

Available release channels

The following release channels are available. Each channel offers a trade-off between feature availability and update churn. Features in each channel have a different maturity level. Critical security patches are delivered to all release channels in order to protect your clusters and Google's infrastructure.

Channel New managed Anthos Service Mesh availability Properties
Rapid After each Anthos Service Mesh release Get the latest Anthos Service Mesh release as early as possible, and be able to use new features the moment they are included in a release. Your control plane is frequently updated to stay on the latest available patch version, and deliver newer capabilities. The Rapid channel is best used to test newer Anthos Service Mesh versions and APIs on pre-production environments.
Regular Rapid is promoted to Regular* Access Anthos Service Mesh and Istio features reasonably soon after they debut, but on a version that has been qualified over a longer period of time. Offers a balance of feature availability and release stability, and is what we recommend for most users.
Stable Regular is promoted to Stable* Prioritize stability over new functionality. Changes and new versions in this channel are rolled out last, after being validated on the Rapid and Regular channels which allows even more time for validation.
*The promotion schedule to the next channel depends on multiple factors, including the open source Istio release, Anthos release, and patching schedule, and therefore is subject to change. To stay informed with the latest information, add the URL of the Anthos Service Mesh release notes to your feed reader, or add the feed URL directly: https://cloud.google.com/feeds/servicemesh-release-notes.xml

When a minor version of managed Anthos Service Mesh has sufficient usage and demonstrated stability in the Rapid channel, it is promoted to the Regular channel. Eventually, the minor version is promoted to the Stable channel, which only receives high-priority updates and security patches. Each promotion signals a graduating level of stability and production-readiness, based on observed performance of the control plane running that version.

All channels are based on a generally available (GA) release (although individual features may not always be GA, as marked). New Anthos Service Mesh versions are first released to the Rapid channel, and over time are promoted to the Regular, and Stable channel. This allows you to select a channel that meets your business, stability, and functionality needs.

Your cluster's Anthos Service Mesh channel is determined by its GKE cluster channel.

GKE Channel Anthos Service Mesh Channel
Rapid Rapid
Regular Regular
Stable Stable
(no channel) Regular

Anthos Service Mesh versions per channel

Your Anthos Service Mesh channel is determined by your GKE cluster channel at time of provisioning managed Anthos Service Mesh. If you change the GKE cluster channel later, then you keep the original Anthos Service Mesh channel.

The following table shows the current channel to Anthos Service Mesh version mapping:

Channel Anthos Service Mesh Version
Rapid 1.18
Regular 1.17
Stable 1.17

Default channel

In a newly installed Anthos Service Mesh where there is a single managed channel installed in a cluster, that channel will be the default channel for that cluster.

If clusters with an existing Istio or Anthos Service Mesh installation have the default tag configured, then it must be pointed to the managed revision. Otherwise, no action is required.

You can use the istio-injection=enabled label as an alias that points injection to the other labels you use for the channel, such as the default revision. Wherever our documentation shows to use the istio.io/rev namespace label for injection, it's possible to use the istio-injection=enabled label instead.

Injection labels

To allow Anthos Service Mesh to manage the workloads in a given namespace, the namespace must be labeled with a label corresponding to the installed channel. Managed Anthos Service Mesh supports two types of labels:

  • standard revision labels, namely asm-managed-stable, asm-managed, asm-managed-rapid, corresponding to the channels stable, regular, and rapid.
  • default injection label (for example, istio-injection=enabled), corresponding to the default channel for that cluster. Using the default injection label simplifies migration between revisions. For example, when migrating from Istio OSS or from unmanaged Anthos Service Mesh to managed Anthos Service Mesh, since there is no need to re-label each namespace individually. Wherever Anthos Service Mesh documentation shows to use the istio.io/rev namespace label for injection, it's possible to use the istio-injection=enabled label instead.

Other examples of injection labels include labelling workloads with sidecar.istio.io/inject (commonly used for gateways) and istio.io/rev, which works for both namespaces and workloads.

Default injection labels

To apply the default injection label to a namespace:

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

Revision labels

Like other Kubernetes labels, a revision label is a key-value pair. The key in a revision label is always istio.io/rev, but the value varies. To select a release channel, you apply one of the follow revision names to your namespaces:

Revision name Channel
asm-managed Regular
asm-managed-rapid Rapid
asm-managed-stable Stable

For example, to apply the Regular release channel to a namespace:

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

We recommend that you use the same release channel that the cluster uses.

To see what release channel a namespace is using:

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

Update unmanaged proxies

After each Anthos Service Mesh release, restart the unmanaged proxies for your services and gateways. Although the service mesh is fine when the control plane and proxies are at different versions, we recommend that you update the proxies so that they are configured with the new Anthos Service Mesh version.

  1. Check the control plane and proxy version.

  2. If the control plane version is newer than the proxy version, restart the unmanaged proxies for your services and gateways.

    kubectl rollout restart deployment -n NAMESPACE