[[["易于理解","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-19。"],[],[],null,["# Plan an upgrade\n===============\n\n| **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---------------------\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---------------------------\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------------------------------\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\n### Identifying 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-----------------------------\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--------------------------------\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\n- [Install dependent tools and validate clusters](/service-mesh/docs/onboarding/kubernetes-off-gcp/install/install-dependent-tools)"]]