이 페이지에서는 Cloud Service Mesh 업그레이드를 계획하는 데 도움이 되는 정보를 제공합니다. Istio 업그레이드 노트를 검토하는 것도 좋습니다.
카나리아 업그레이드 정보
먼저 새로운 컨트롤 플레인의 카나리아 배포를 실행하여 Cloud Service Mesh를 업그레이드하는 것이 좋습니다. 카나리아를 업그레이드하면 asmcli는 이전 컨트롤 플레인과 함께 컨트롤 플레인의 새 버전을 설치합니다. 이전 컨트롤 플레인과 새 컨트롤 플레인 모두 revision 라벨이 지정되며 이 라벨은 컨트롤 플레인의 식별자 역할을 합니다.
새 컨트롤 플레인으로 워크로드를 마이그레이션하려면 다음 안내를 따르세요.
새 컨트롤 플레인의 revision 라벨을 네임스페이스 중 하나에 설정합니다.
지속적 재시작을 수행합니다. 재시작하면 프록시가 새 컨트롤 플레인을 사용하도록 사이드카 프록시가 포드에 다시 삽입됩니다.
업그레이드가 워크로드에 미치는 영향을 모니터링합니다. 애플리케이션 테스트에 필요하면 이전 단계를 반복합니다.
애플리케이션 테스트가 완료되면 모든 트래픽을 새 컨트롤 플레인으로 마이그레이션하거나 이전 컨트롤 플레인으로 롤백할 수 있습니다.
카나리아 업그레이드는 새로운 컨트롤 플레인이 이전 컨트롤 플레인을 대체하는 인플레이스(In-Place) 업그레이드보다 훨씬 안전합니다. 자세한 단계는 새로운 컨트롤 플레인으로 전환을 참조하세요.
제어 영역 맞춤설정
이전 설치를 맞춤설정한 경우 Cloud Service Mesh를 업그레이드할 때 동일한 맞춤설정이 필요합니다. --set values 플래그를 istioctl install에 추가하여 설치를 맞춤설정한 경우 오버레이 파일이라고 부르는 IstioOperator YAML 파일에 이러한 설정을 추가해야 합니다. asmcli를 실행할 때 해당 파일 이름으로 --custom_overlay 옵션을 사용해서 오버레이 파일을 지정합니다.
asmcli install을 사용하여 Cloud Service Mesh를 설치할 때 --option 또는 --custom_overlay로 하나 이상의 오버레이 파일을 지정할 수 있습니다.
anthos-service-mesh 저장소의 파일을 변경할 필요가 없는 경우 --option을 사용할 수 있으며 스크립트가 자동으로 GitHub에서 파일을 가져옵니다. 그렇지 않으면 오버레이 파일을 변경한 후 --custom_overlay 옵션을 사용하여 asmcli에 전달할 수 있습니다.
인증 기관 선택
현재 Cloud Service Mesh 설치에서 Cloud Service Mesh 인증 기관을 상호 TLS(mTLS) 인증서 발급을 위한 인증 기관(CA)으로 사용하는 경우 Cloud Service Mesh 인증 기관을 계속 사용하는 것이 좋습니다. 그 이유는 다음과 같습니다.
Cloud Service Mesh 인증 기관은 동적으로 확장된 워크로드에 최적화된 안정성과 확장성이 뛰어난 서비스입니다.
Google은 Cloud Service Mesh 인증 기관을 통해 CA 백엔드의 보안 및 가용성을 관리합니다.
Cloud Service Mesh 인증 기관을 사용하면 여러 클러스터에서 신뢰할 수 있는 단일 루트를 사용할 수 있습니다.
현재 Cloud Service Mesh 설치에서 Istio CA(이전의 'Citadel')를 사용하는 경우 업그레이드할 때 Cloud Service Mesh 인증 기관으로 전환할 수 있지만 다운타임 일정이 필요합니다. 업그레이드 중에는 모든 워크로드가 Cloud Service Mesh 인증 기관과 함께 새 컨트롤 플레인을 사용하도록 전환될 때까지 mTLS 트래픽이 중단됩니다.
Cloud Service Mesh 인증 기관의 인증서에는 애플리케이션 서비스에 대한 다음 데이터가 포함됩니다.
Google Cloud 프로젝트 ID
GKE 네임스페이스
GKE 서비스 계정 이름
CA 확인
asmcli install을 실행하여 업그레이드할 때는 asmcli가 새 컨트롤 플레인에서 사용 설정해야 하는 CA를 지정합니다.
CA를 변경하면 새 컨트롤 플레인에 워크로드를 배포할 때 다운타임이 발생합니다. 다운타임을 예약할 수 없으면 새 컨트롤 플레인에 대해 이전 컨트롤 플레인에 사용되는 것과 동일한 CA를 지정합니다. 메시에 사용 설정된 CA가 확실하지 않으면 다음 명령어를 실행합니다.
네임스페이스 중 하나에서 포드 목록을 가져옵니다.
kubectl get pods -n NAMESPACE
다음 명령어에서 POD_NAME을 포드 중 하나의 이름으로 바꿉니다.
kubectl get pod POD_NAME -n NAMESPACE -o yaml | grep CA_ADDR -A 1
Cloud Service Mesh 인증 기관이 네임스페이스에서 사용 설정되면 다음 출력이 표시됩니다.
- name: CA_ADDR
value: meshca.googleapis.com:443
게이트웨이 구성 준비
Cloud Service Mesh는 서비스 메시의 일부로 게이트웨이를 배포 및 관리하는 옵션을 제공합니다. 게이트웨이는 들어오거나 나가는 HTTP/TCP 연결을 수신하는 메시지의 에지에서 작동하는 부하 분산기를 설명합니다. 게이트웨이는 메시로 들어오고 나가는 트래픽을 미세하게 제어할 수 있는 Envoy 프록시입니다.
asmcli는 istio-ingressgateway를 설치하지 않습니다. 컨트롤 플레인과 게이트웨이를 개별적으로 배포하고 관리하는 것이 좋습니다. 자세한 내용은 게이트웨이 설치 및 업그레이드를 참조하세요.
플랫폼 업그레이드(선택사항)
Cloud Service Mesh를 현재 플랫폼도 지원하는지원되는 최신 버전으로 업그레이드하는 것이 좋습니다. 그런 다음 지원되는 플랫폼 및 Kubernetes 버전 범위 내에 있도록 환경을 업그레이드합니다.
마지막으로 필요한 경우 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-08-20(UTC)"],[],[],null,["Plan an upgrade **Note:** This guide only supports Cloud Service Mesh with Istio APIs and does not support Google Cloud APIs. For more information see, [Cloud Service Mesh overview](/service-mesh/docs/overview).\n\nThis page provides information to help you plan a Cloud Service Mesh upgrade. We\nrecommend that you also review the\n[Istio upgrade notes](https://istio.io/latest/news/releases/1.26.x/announcing-1.26/upgrade-notes/).\n\nAbout canary upgrades\n\nWe recommend that you upgrade Cloud Service Mesh by first running a canary deployment\nof the new control plane. With a canary upgrade, `asmcli` installs a new\n[revision](/service-mesh/docs/revisions-overview#what_is_a_revision) of the control\nplane alongside the old control plane. Both the old and new control planes\nare labeled with a `revision` label, which serves as an identifier for the\ncontrol planes.\n\nTo migrate workloads to the new control plane:\n\n1. Set the new control plane's `revision` label on one of your namespaces.\n\n2. Perform a rolling restart. The restart re-injects the sidecar proxies in the\n Pods so that the proxies use the new control plane.\n\n3. Monitor the effect of the upgrade on the workloads. If needed to test your\n application, repeat the previous steps.\n\n4. After testing your application, you can migrate all traffic to the new\n control plane or rollback to the old control plane.\n\nA canary upgrade is much safer than doing an in-place upgrade where the new\ncontrol plane replaces the old control plane. For detailed steps, see\n[Switch to the new control plane](/service-mesh/docs/upgrade/upgrade#switch_to_the_new_control_plane).\n| **Caution:** In-place upgrades are not supported and doing an in-place upgrade to version 1.24 will cause downtime due to a breaking change in the pilot cert provider. If you do in-place upgrade, all workloads will need to be redeployed post upgrade to connect to the control plane.\n\nCustomize the control plane\n\nIf you customized the previous installation, you need the same customizations\nwhen you upgrade Cloud Service Mesh. If you customized the installation by adding\nthe `--set values` flag to `istioctl install`, you must add those settings to\nan `IstioOperator` YAML file, referred to as an overlay file. You specify the\noverlay file by using the `--custom_overlay` option with the filename when you\nrun `asmcli`.\n| **Caution:** Omitting the overlay file results in a successful installation. However, your service mesh has a different configuration than you intended because the omitted values are reset back to the defaults when the control plane is redeployed.\n\nThe\n[`asmcli` directory](https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages/tree/release-1.25/asm/istio/options)\nin GitHub contains many overlay files. These files contain common customizations\nto the default configuration. You can use these files as they are, or you can\nmake additional changes to them as needed. Some of the files are required to\n[enable optional Cloud Service Mesh features](/service-mesh/docs/onboarding/kubernetes-off-gcp/install/options/all-install-options).\nThe `anthos-service-mesh` package is downloaded when you run `asmcli` to\n[validate your project and cluster](/service-mesh/docs/onboarding/kubernetes-off-gcp/install/install-dependent-tools#validate_project_and_cluster).\n\nWhen you install Cloud Service Mesh using `asmcli install`, you\ncan specify one or more overlay files with the `--option` or `--custom_overlay`.\nIf you don't need to make any changes to the files in the `anthos-service-mesh`\nrepository, you can use `--option`, and the script fetches the file from GitHub\nfor you. Otherwise, you can make changes to the overlay file, and then use the\n`--custom_overlay` option to pass it to the `asmcli`.\n\nChoose a certificate authority\n\nIf your current Cloud Service Mesh installation uses\nCloud Service Mesh certificate authority as the certificate authority (CA) for issuing\n[mutual TLS (mTLS)](/service-mesh/docs/security/security-overview#mutual_tls)\ncertificates, we recommend that you continue to use Cloud Service Mesh certificate authority\nfor the following reasons:\n\n- Cloud Service Mesh certificate authority is a highly reliable and scalable service that is optimized for dynamically scaled workloads.\n- With Cloud Service Mesh certificate authority, Google manages the security and availability of the CA backend.\n- Cloud Service Mesh certificate authority lets you rely on a single root of trust across clusters.\n\nIf your current Cloud Service Mesh installation uses [Istio CA](https://istio.io/latest/docs/tasks/security/cert-management/plugin-ca-cert/)\n(previously called \"Citadel\"), you can switch to Cloud Service Mesh certificate authority when\nyou upgrade, but you need to schedule downtime. During the upgrade, mTLS traffic\nis interrupted until all workloads are switched to using the new control plane\nwith Cloud Service Mesh certificate authority.\n\n\n| **Platform note:** CA Service is only supported on the following platforms: GKE clusters on Google Cloud, Google Distributed Cloud (software only) for VMware, and Distributed Cloud. If you run `asmcli install` and specify `--ca gcp_cas` on other platforms, the installation appears successful, but your workloads will fail to start.\n\n\u003cbr /\u003e\n\nCertificates from Cloud Service Mesh certificate authority include the following data about\nyour application's services:\n\n- The Google Cloud project ID\n- The GKE namespace\n- The GKE service account name\n\n| **Important:** The certificates issued by Cloud Service Mesh certificate authority should only be used to enable secure service-to-service communication within your service mesh, and not be used for any other purpose. These certificates are sent whenever services attempt to communicate with each other using mutual TLS. Make sure that you don't inadvertently expose confidential information by using these certificates when communicating outside your service mesh.\n\nIdentifying your CA\n\nWhen you run `asmcli install` to upgrade, you specify the CA that `asmcli`\nshould enable on the new control plane.\n\nChanging CAs causes downtime when your deploy workloads to the new\ncontrol plane. If you can't schedule downtime, make sure to specify that same CA\nfor the new control plane that the old control plane uses. If you aren't sure\nwhich CA is enabled on your mesh, run the following commands:\n\n1. Get a list of Pods from one of your namespaces:\n\n kubectl get pods -n \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e\n\n2. Replace \u003cvar translate=\"no\"\u003ePOD_NAME\u003c/var\u003e with the name of one of your Pods in\n the following command:\n\n kubectl get pod \u003cvar translate=\"no\"\u003ePOD_NAME\u003c/var\u003e -n \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e -o yaml | grep CA_ADDR -A 1\n\n If Cloud Service Mesh certificate authority is enabled on the namespace, you see the\n following output: \n\n - name: CA_ADDR\n value: meshca.googleapis.com:443\n\nPrepare gateway configuration\n\nCloud Service Mesh gives you the option to deploy and manage gateways as part of your\nservice mesh. A gateway describes a load balancer operating at the edge of the\nmesh receiving incoming or outgoing HTTP/TCP connections. Gateways are Envoy\nproxies that provide you with fine-grained control over traffic entering and\nleaving the mesh.\n\n`asmcli` doesn't install the `istio-ingressgateway`. We recommend that you\ndeploy and manage the control plane and gateways separately. For more\ninformation, see [Installing and upgrading gateways](/service-mesh/docs/operate-and-maintain/gateways).\n\nUpgrade your platform (optional)\n\nAs a best practice, you should upgrade Cloud Service Mesh to the latest\n[supported version](/service-mesh/versions)\n*that also supports your current platform* . Then, upgrade your environment so\nthat it is within the range of\n[supported platforms and Kubernetes versions](/service-mesh/docs/supported-platforms).\nLastly, if needed, upgrade to the latest\n[supported version](/service-mesh/versions) of Cloud Service Mesh.\n\nWhat's next?\n\n- [Install dependent tools and validate clusters](/service-mesh/docs/onboarding/kubernetes-off-gcp/install/install-dependent-tools)"]]
