Version 1.8

Preparing to migrate from Istio

Migrating from Istio to Anthos Service Mesh takes some planning. This page provides information to help you prepare for the migration.

Reviewing the supported features

The features Anthos Service Mesh supports differ between platforms. Review the Supported features to see which features are available for your platform. Some features are enabled by default, and others you can optionally enable by creating an IstioOperator configuration file.

Preparing configuration files

If you 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 IstioOperator YAML file. You specify the file by using the -f flag with the file when you run the istioctl install command. If you are using the Google-provided install_asm script to migrate to Anthos Service Mesh, you can specify the --custom-overlay option with the file.

Choosing a certificate authority

You can continue to use Citadel (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. If you choose Citadel, there's little downtime because mTLS traffic isn't interrupted during the migration. If you choose Mesh CA, you need to schedule downtime for the migration because the root of trust changes from Citadel to Mesh CA. To complete the migration to the Mesh CA root of trust, you need to restart all Pods in all namespaces. During this process, the old Pods cannot establish mTLS connections with the new Pods.

Reviewing the migration process

To migrate from Istio, you follow the revision upgrade process, (referred to as "canary" upgrades in the Istio documentation). With a revision upgrade, you install a new version of the control plane (istiod) alongside the existing control plane. When installing the new version, you include (or the install_asmscript includes) a revision label that identifies the version of the new control plane. Each revision is a full 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 plane.