Migrating from Istio to Anthos Service Mesh takes some planning. This page provides information to help you prepare for the migration.
Reviewing the profiles
The configuration profiles that Anthos Service Mesh provides are different from Open Source Istio. When you install Anthos Service Mesh, you use a configuration profile that is suitable for your environment:
asm-gcp: Use this profile for installations on GKE on Google Cloud for a mesh containing either a single cluster or multiple clusters that are in the same Cloud project.
asm-gcp-multiprojectbeta: Use this profile for installations on GKE on Google Cloud with clusters in different Cloud projects.
asm-multicloud: Use this profile for installations on the following environments:
- GKE on-prem
- GKE on AWS
- Amazon Elastic Kubernetes Service (Amazon EKS)
- Microsoft Azure Kubernetes Service (Microsoft AKS)
The supported Anthos Service Mesh features differ between the profiles. Review the Supported features for the profile that is right for your configuration.
You can compare the configuration profile that you used to install Istio with Anthos Service Mesh profile that you plan to use:
Follow the steps in Downloading the installation file to download the installation and signature files, extract the contents, and set the path to use the version of
istioctlfrom the download file.
Generate a manifest for the Anthos Service Mesh profile you plan to use:
istioctl manifest generate -f manifests/profiles/ASM_PROFLE > a.yaml
Locate the profile that you used to install Istio. Because profiles can change between Istio versions, you need the profile from the installation package that matches your version of Istio.
Generate a manifest for the profile that you used to install Istio:
istioctl manifest generate -f ISTIO_PROFILE > b.yaml
Compare the manifests:
istioctl manifest diff a.yaml b.yaml
Preparing configuration files
customized the Istio installation,
you need the same customizations when you migrate to Anthos Service Mesh. If you
customized the installation by adding the
--set values flag, we recommend
that you add those settings to an
configuration file. You specify the configuration file by using the
with the configuration file when you run the
istioctl install command.
Choosing a certificate authority
You can continue to use
(now incorporated in
istiod) as the certificate authority (CA) for issuing
mutual TLS (mTLS) certificates, or
you can choose to migrate to Anthos Service Mesh certificate authority (Mesh CA).
We generally recommend that you use Mesh CA for the following reasons:
- Mesh CA is a highly reliable and scalable service that is optimized for dynamically scaled workloads on Google Cloud.
- With Mesh CA, Google manages the security and availability of the CA backend.
- Mesh CA lets you rely on a single root of trust across clusters.
However, there are cases where you might want to consider using Citadel, such as the following:
- If you have a custom CA.
- You can't schedule downtime for the migration to Mesh CA. Although we recommend that you use Mesh CA, you need to schedule downtime for the migration because mTLS traffic fails until you restart all Pods in all namespaces.
Reviewing the migration process
To migrate from Istio, you follow the
dual control plane upgrade process
(referred to as canary upgrades in the Istio documentation). With a dual control
plane upgrade, you install a new version of the control plane alongside the
existing control plane. When installing the new version, you include a
revision label that identifies the version of the new control plane. Each
revision is a full Anthos Service Mesh control plane implementation with its own
Deployment and Service.
You then migrate to the new version by setting the same
revision label on your
workloads to point to the new control plane and performing a rolling restart to
re-inject the proxies with the new Anthos Service Mesh version. With this approach,
you can monitor the effect of the upgrade on a small percentage of your
workloads. After testing your application, you can migrate all traffic to the
new version. This approach is much safer than doing an in-place upgrade where a
new control plane immediately replaces the previous version of the control
Unless you have a load balancer or router setup for blue-green deployments, we recommend that you test the migration and restarting Pods in a staging environment to verify that your services can handle any potential traffic interruption.