Cloud Service Mesh 经常发布更新，以提供安全更新、解决已知问题以及推出新功能。发布渠道可让您在 Cloud Service Mesh 版本的稳定性与功能集之间取得平衡。Cloud Service Mesh 发布渠道与 Google Kubernetes Engine (GKE) 发布渠道相关联。Google 会自动管理每个发布渠道的版本和升级频率。
本文档介绍了发布渠道的比较以及如何更新非托管式代理。
可用发布渠道
您可以获得以下发布渠道。每个渠道都在功能可用性和更新流失率之间进行权衡取舍。每个渠道中的功能都有不同的成熟度级别。 我们会向所有发布渠道提供重要的安全补丁，以保护您的集群和 Google 的基础架构。
渠道
全新托管式 Cloud Service Mesh 可用性
属性
快速
每次 Cloud Service Mesh 版本发布后
尽早获取最新的 Cloud Service Mesh 版本，并在新功能加入版本后立即使用它们。您的控制层面会经常更新，以跟进可用的最新补丁程序版本并提供更新的功能。快速渠道最适合用于在预生产环境中测试较新的 Cloud Service Mesh 版本和 API。
常规
“快速”已提升为“普通”*
在 Cloud Service Mesh 和 Istio 功能首次发布后的合理时间内可以尽快访问，但应该访问经过较长时间验证合格的版本。兼顾功能可用性和版本稳定性，是我们向大多数用户推荐的做法。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-14。"],[],[],null,["# Managed Cloud Service Mesh release channels\n===========================================\n\n| **Deprecated:** Provisioning managed Cloud Service Mesh with asmcli will be deprecated on **Aug 22, 2024** and support will end in **February 2025**. This change only affects Google Cloud clusters. Off-Google Cloud clusters will continue to use asmcli as normal.\n\nCloud Service Mesh releases updates often, to deliver security updates, fix\nknown issues, and introduce new features. Release channels balance between\nstability and the feature set of the Cloud Service Mesh version. Cloud Service Mesh\nrelease channels are tied to\n[Google Kubernetes Engine (GKE) release channels](/kubernetes-engine/docs/concepts/release-channels).\nGoogle automatically manages the version and upgrade cadence for each release\nchannel.\n| **Note:** Managed Cloud Service Mesh consists of the managed control plane and managed data plane. Both components use the same release channel.\n\nThis document covers comparisons of release channels, and how to update\nunmanaged proxies.\n\n### Available release channels\n\nThe following release channels are available. Each channel offers a trade-off\nbetween feature availability and update churn. Features in each channel have a\ndifferent maturity level. Critical security patches are delivered to all release\nchannels in order to protect your clusters and Google's infrastructure.\n\nWhen a minor version of managed Cloud Service Mesh has sufficient usage and\ndemonstrated stability in the Rapid channel, it is promoted to the Regular\nchannel. Eventually, the minor version is promoted to the Stable channel, which\nonly receives high-priority updates and security patches. Each promotion\nsignals a graduating level of stability and production-readiness, based on\nobserved performance of the control plane running that version.\n\nAll channels are based on a generally available (GA) release (although\nindividual features may not always be GA, as marked). New Cloud Service Mesh\nversions are first released to the Rapid channel, and over time are promoted to\nthe Regular, and Stable channel. This allows you to select a channel that meets\nyour business, stability, and functionality needs.\n\nYour cluster's Cloud Service Mesh channel is determined by its GKE\ncluster channel.\n\n#### Cloud Service Mesh versions per channel\n\nYour Cloud Service Mesh channel is determined by your GKE cluster\nchannel at time of provisioning managed Cloud Service Mesh. If you change the\nGKE cluster channel later, then you keep the original\nCloud Service Mesh channel.\n\nThe following table shows the current channel to Cloud Service Mesh version mapping:\n\n#### Default channel\n\nIn a newly installed Cloud Service Mesh where there is a single managed channel\ninstalled in a cluster, that channel will be the default channel for that\ncluster.\n\nIf clusters with an existing Istio or Cloud Service Mesh installation have the\ndefault tag configured, then it must be pointed to the managed revision.\nOtherwise, no action is required.\n\nYou can use the `istio-injection=enabled` label as an alias that points\ninjection to the other labels you use for the channel, such as the\ndefault revision. Wherever our documentation shows to use the `istio.io/rev`\nnamespace label for injection, it's possible to use the\n`istio-injection=enabled` label instead.\n\n#### Injection labels\n\nTo allow Cloud Service Mesh to manage the workloads in a given namespace, the\nnamespace must be labeled with a label corresponding to the installed channel.\nManaged Cloud Service Mesh supports two types of labels:\n\n- standard [revision labels](/service-mesh/docs/revisions-overview#what_is_a_revision), namely `asm-managed-stable`, `asm-managed`, `asm-managed-rapid`, corresponding to the channels `stable`, `regular`, and `rapid`.\n- [default injection label](https://istio.io/latest/docs/setup/upgrade/canary/#default-tag) (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](/service-mesh/docs/managed/migrate-istio-operator) or from unmanaged Cloud Service Mesh to managed Cloud Service Mesh, since there is no need to re-label each namespace individually. Wherever Cloud 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.\n\nOther examples of injection labels include labelling workloads with\n`sidecar.istio.io/inject` (commonly used for gateways) and `istio.io/rev`, which\nworks for both namespaces and workloads. \n\n### Default injection labels\n\nTo apply the default injection label to a namespace:\n**Note:** Although you can also use `istio.io/rev=default` instead of `istio-injection=enabled` as a default injection label, we recommend to standardize around `istio-injection=enabled`. \n\n kubectl label namespace \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e istio-injection=enabled istio.io/rev- --overwrite\n\n| **Note:** You can ignore the message `\"istio-injection not found\"` in the output. That means that the namespace didn't previously have the `istio-injection` label, which you should expect in new installations of Cloud Service Mesh or new deployments.\n\n### Revision labels\n\nLike other Kubernetes labels, a revision label is a key-value pair.\nThe key in a revision label is always `istio.io/rev`, but the value varies.\nTo select a release channel, you apply one of the follow revision names\nto your namespaces:\n\nFor example, to apply the Regular release channel to a namespace: \n\n kubectl label namespace \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e istio.io/rev=asm-managed --overwrite\n\nWe recommend that you use the same release channel that the cluster uses.\n\nTo see what release channel a namespace is using: \n\n kubectl get namespace \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e -o jsonpath='{.metadata.labels.istio\\.io/rev}{\"\\n\"}'\n\n### Update unmanaged proxies\n\nAfter each Cloud Service Mesh release, restart the unmanaged proxies for your\nservices and gateways. Although the service mesh is fine when the\ncontrol plane and proxies are at different versions, we recommend that you\nupdate the proxies so that they are configured with the new Cloud Service Mesh\nversion.\n\n1. Check the\n [control plane and proxy version](/service-mesh/docs/managed/provision-managed-anthos-service-mesh#verify_control_plane_metrics).\n\n2. If the control plane version is newer than the proxy version, restart\n the unmanaged proxies for your services and gateways.\n\n kubectl rollout restart deployment -n \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e"]]
