這項異動只會影響 Google Cloud 叢集。Google Cloud 叢集會繼續照常使用 asmcli。
Cloud Service Mesh 版本經常更新，藉以提供安全性更新、修正已知問題及推出新功能。發布版本可在穩定性與 Cloud Service Mesh 版本的功能組合之間取得平衡。Cloud Service Mesh 版本管道與 Google Kubernetes Engine (GKE) 版本管道相關聯。Google 會自動管理各發布版本的版本和升級頻率。
本文件將比較各個發布管道，並說明如何更新未管理的 Proxy。
可用的發布版本
您可以使用下列發布版本。每個管道都會在功能可用性和更新流失率之間做出取捨。每個頻道的功能都有不同的成熟度等級。所有發布版本都會收到重要的安全性修補程式，藉以保護您的叢集與 Google 的基礎架構。
管道
新推出的代管 Cloud Service Mesh 可用性
資源
快速
每次發布 Cloud Service Mesh 後
盡早取得最新的 Cloud Service Mesh 版本，並在新功能納入版本後立即使用。控制層會經常更新，以便維持最新可用的修補程式版本，並提供較新的功能。搶鮮版最適合在試產環境中測試較新的 Cloud Service Mesh 版本和 API。
一般
Rapid 已升級為 Regular*
在 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"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[],[],null,["Managed Cloud Service Mesh release channels **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\nAvailable 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\n| **Channel** | **New managed Cloud Service Mesh availability** | **Properties** |\n|-------------|-------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Rapid | After each Cloud Service Mesh release | Get the latest Cloud 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 Cloud Service Mesh versions and APIs on pre-production environments. |\n| Regular | Rapid is promoted to Regular\\* | Access Cloud 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. |\n| 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. |\n| \\*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 [Cloud Service Mesh release notes](/service-mesh/docs/release-notes) to your [feed reader](https://wikipedia.org/wiki/Comparison_of_feed_aggregators), or add the feed URL directly: `https://cloud.google.com/feeds/servicemesh-release-notes.xml` |||\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| GKE Channel | Cloud Service Mesh Channel |\n|--------------|----------------------------|\n| Rapid | Rapid |\n| Regular | Regular |\n| Stable | Stable |\n| (no channel) | Regular |\n\nCloud 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| Channel | Cloud Service Mesh Version |\n|---------|----------------------------|\n| Rapid | 1.21 |\n| Regular | 1.20 |\n| Stable | 1.19 |\n\nDefault 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\nInjection 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\nDefault 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\nRevision 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\n| Revision name | Channel |\n|----------------------|---------|\n| `asm-managed` | Regular |\n| `asm-managed-rapid` | Rapid |\n| `asm-managed-stable` | Stable |\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\nUpdate 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"]]
