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
IstioOperator configuration file.
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
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
option with the file.
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. 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