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 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 for a mesh containing either a single cluster or multiple clusters that are in the same Google Cloud project.

  • asm-gcp-multiproject beta: Use this profile for installations on GKE with clusters in different Google Cloud projects.

  • asm-multicloud: Use this profile for installations on the following environments:

    • GKE on VMware
    • 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.

Compare profiles

You can compare the configuration profile that you used to install Istio with Anthos Service Mesh profile that you plan to use:

  1. 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 istioctl from the download file.

  2. Generate a manifest for the Anthos Service Mesh profile you plan to use:

    istioctl manifest generate -f manifests/profiles/ASM_PROFLE > a.yaml
  3. 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.

  4. Generate a manifest for the profile that you used to install Istio:

    istioctl manifest generate -f ISTIO_PROFILE > b.yaml
  5. Compare the manifests:

    istioctl manifest diff a.yaml b.yaml
    

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 configuration file. You specify the configuration file by using the -f flag with the configuration file when you run the istioctl install command.

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. 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 plane.

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.