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 기능은 처음 소개된 후 비교적 곧바로 액세스할 수 있지만 조금 더 긴 시간 동안 검증된 버전으로 액세스할 수 있습니다. 사용 가능한 기능과 출시 안정성의 균형이 유지되며, 대부분의 사용자에게 권장됩니다.
안정화
일반에서 공개 버전으로 승격*
새로운 기능보다 안정성을 우선시합니다. 이 채널의 변경사항 및 새 버전은 신속 채널 및 일반 채널에 출시된 후 가장 마지막으로 출시되므로 더 오랜 기간 동안 검증됩니다.
*다음 채널의 승격 일정은 오픈소스 Istio 출시, Anthos 출시, 패치 일정을 비롯한 여러 요소에 따라 달라지므로 변경될 수 있습니다. 최신 정보를 받아보려면 Cloud Service Mesh 출시 노트 URL을 피드 리더에 추가하거나 피드 URL을 다음과 같이 직접 추가하세요. https://cloud.google.com/feeds/servicemesh-release-notes.xml
관리형 Cloud Service Mesh의 부 버전에 사용량이 충분하고 신속 채널에서 안정성이 보인 경우 일반 채널로 승격됩니다. 결국 부 버전은 공개 버전 채널로 승격되어 중요도가 높은 업데이트 및 보안 패치만 수신합니다. 각 승격은 버전을 실행하는 컨트롤 플레인의 성능을 기준으로 단계적 안정성과 프로덕션 준비 상태를 나타냅니다.
모든 채널은 일반 안정화(GA) 출시 버전을 기반으로 합니다(단, 표시된 대로 개별 기능이 항상 GA로 간주되지는 않음). 새 Cloud Service Mesh 버전은 신속 채널에 먼저 출시되며 시간이 지남에 따라 일반 및 공개 버전 채널로 승격됩니다. 이렇게 하면 비즈니스, 안정성, 기능 요구사항을 충족하는 채널을 선택할 수 있습니다.
클러스터의 Cloud Service Mesh 채널은 GKE 클러스터 채널에 따라 결정됩니다.
GKE 채널
Cloud Service Mesh 채널
신속
신속
일반
일반
안정화
안정화
(채널 없음)
일반
채널별 Cloud Service Mesh 버전
Cloud Service Mesh 채널은 관리형 Cloud Service Mesh를 프로비저닝할 때 GKE 클러스터 채널에 따라 결정됩니다. 나중에 GKE 클러스터 채널을 변경해도 원래 Cloud Service Mesh 채널은 유지됩니다.
다음 표에서는 현재 채널의 Cloud Service Mesh 버전 매핑을 보여줍니다.
채널
Cloud Service Mesh 버전
신속
1.21
일반
1.20
안정화
1.19
기본 채널
클러스터에 단일 관리 채널이 설치되어 있는 새로 설치된 Cloud Service Mesh에서 이 채널은 해당 클러스터의 기본 채널이 됩니다.
기존 Istio 또는 Cloud Service Mesh가 설치된 클러스터에 기본 태그가 구성된 경우 관리형 버전에 연결되어야 합니다.
그렇지 않으면 별도의 조치는 필요하지 않습니다.
istio-injection=enabled 라벨을 채널에 사용하는 다른 라벨(예: 기본 버전)에 대한 삽입을 가리키는 별칭으로 사용할 수 있습니다. 이 문서에서는 istio.io/rev 네임스페이스 라벨을 사용하여 삽입하도록 표시되지만 istio-injection=enabled 라벨을 사용할 수도 있습니다.
삽입 라벨
Cloud Service Mesh를 사용하여 지정된 네임스페이스에서 워크로드를 관리할 수 있지만 설치된 채널에 따라 네임스페이스에 라벨을 지정해야 합니다.
관리형 Cloud Service Mesh는 두 가지 유형의 라벨을 지원합니다.
표준 버전 라벨, 즉 채널 stable, regular, rapid에 해당하는 asm-managed-stable, asm-managed, asm-managed-rapid
기본 삽입 라벨(예: istio-injection=enabled)은 해당 클러스터의 기본 채널에 해당합니다. 기본 삽입 라벨을 사용하면 버전 간 마이그레이션이 간소화됩니다. 예를 들어 Istio OSS 또는 비관리형 Cloud Service Mesh에서 관리형 Cloud Service Mesh로 마이그레이션할 때는 각 네임스페이스에 개별적으로 다시 라벨을 지정할 필요가 없습니다. Cloud Service Mesh 문서에서는 istio.io/rev 네임스페이스 라벨을 사용하여 삽입하도록 표시되지만 istio-injection=enabled 라벨을 사용할 수도 있습니다.
삽입 라벨의 다른 예시로는 sidecar.istio.io/inject(일반적으로 게이트웨이에 사용됨) 및 istio.io/rev(네임스페이스 및 워크로드 모두에서 사용됨)로 워크로드에 라벨을 지정하는 작업이 있습니다.
Cloud Service Mesh가 출시될 때마다 서비스와 게이트웨이의 비관리형 프록시를 다시 시작합니다. 제어 영역과 프록시의 버전이 서로 달라도 서비스 메시에는 문제가 없지만 새 Cloud Service Mesh 버전으로 구성되도록 프록시를 업데이트하는 것이 좋습니다.
[[["이해하기 쉬움","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(UTC)"],[],[],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"]]
