This page explains how to run the script to upgrade Anthos Service Mesh from 1.7.3+ or a 1.8 patch release to version 1.8.3 on a GKE cluster for a mesh containing one or more clusters that are in the same Cloud project.
This page is for upgrading Anthos Service Mesh. For information on running the script for new installations and migrations from Istio, see the following:
Before you begin
Before you begin the upgrade, make sure that you have:
- Reviewed the requirements
- Registered your cluster
- Installed the required tools
- Downloaded the script
The script requires that you have the
required permissions, or that you
include either the
to allow the script to enable the permission for you. Similarly, to allow the
script to enable the
and update your cluster,
--enable_all flag or the more granular
Preparing for the upgrade
If you customized the previous installation, you need the same customizations
when you upgrade to Anthos Service Mesh. If you customized the installation by adding
--set values flag to
istioctl install, you must add those settings to an
IstioOperator overlay file. You specify the overlay file by using the
--custom_overlay option with the filename when you run the script.
The script follows the
revision upgrade process (referred to as
"canary" upgrades in the Istio documentation). With a revision upgrade, the
script installs a new version of the control plane (
istiod) alongside the
existing control plane. When installing the new version, the script include 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
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
Upgrading Anthos Service Mesh
Set the options and specify the flags to run the script. You always include the following options:
The following section provides typical examples for running the script. See the navigation bar on the right for a list of the examples. For a complete description of the script's arguments, see Option and flags.
To complete setting up Anthos Service Mesh, you need to enable automatic sidecar injection and deploy or redeploy workloads.
This section shows examples of running the script for upgrades and some additional arguments that you might find useful. See the navigation bar on the right for a list of the examples.
The following example shows running the script with the
option. With this option, the script doesn't make any changes to your project or
cluster, and it doesn't install Anthos Service Mesh. When you specify
--only_validate,the script fails if you include any of the
The script validates that:
- Your environment has the required tools.
- You have the required permission on the specified project.
- The cluster meets the minimum requirements.
- The project has all the required Google APIs enabled.
By default, the script downloads and extracts the installation file and
configuration package from GitHub to a temp directory. Before exiting,
the script outputs a message that provides the name of the temp directory.
You can specify an existing directory for the downloads with the
--output_dir DIR_PATH option. The
option makes it convenient for you to use the
istioctl command-line tool
if you need it. Additionally, the configuration files to enable optional
features are included in the
Run the following command to validate your configuration and download the
installation file and
asm package to the
./install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --mode upgrade \ --output_dir DIR_PATH \ --only_validate
On success, the script outputs the following:
./install_asm \ install_asm: Setting up necessary files... install_asm: Creating temp directory... install_asm: Generating a new kubeconfig... install_asm: Checking installation tool dependencies... install_asm: Downloading ASM.. % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 57.0M 100 57.0M 0 0 30.6M 0 0:00:01 0:00:01 --:--:-- 30.6M install_asm: Downloading ASM kpt package... fetching package /asm from https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages to asm install_asm: Checking for project PROJECT_ID... install_asm: Confirming cluster information... install_asm: Confirming node pool requirements... install_asm: Fetching/writing GCP credentials to kubeconfig file... Fetching cluster endpoint and auth data. kubeconfig entry generated for cluster-1. install_asm: Checking Istio installations... install_asm: Checking required APIs... install_asm: Successfully validated all requirements to install ASM from this computer.
If one of the tests fails the validation, the script outputs an error message. For example, if your project doesn't have all of the required Google APIs enabled, you see the following error:
ERROR: One or more APIs are not enabled. Please enable them and retry, or run the script with the '--enable_gcp_apis' flag to allow the script to enable them on your behalf.
If you got an error message about needing to run the script with an
you can include the specific flag from the error message or the
flag when running the script without
--only_validate. If you prefer, you can
update your project and cluster yourself before running the script as described
in the Setting up your project and
Setting up your cluster sections of the
Multi-project installation guide.
The following command runs the script to upgrade. The script doesn't allow
you to change to another CA, so you don't need to include the
./install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --mode upgrade \ --enable_all
Upgrading with an with an overlay file
An overlay file is a YAML file containing an
IstioOperator custom resource
(CR) that you pass to
install_asm to configure the control plane. You can
override the default control plane configuration and
enable an optional feature by passing
the YAML file to
install_asm. You can layer on more overlays, and each overlay
file overrides the configuration on the previous layers.
If you specify more than one CR in a YAML file,
install_asm splits the file
into multiple temporary YAML files, one for each CR. The script splits the
CRs into separate files because
istioctl install only applies the first CR in
a YAML file containing more than one CR.
The following example does an upgrade and includes an overlay file to customize
the control plane configuration. In the following command, change
OVERLAY_FILE to the name of the YAML file.
./install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --mode upgrade \ --enable_all \ --custom_overlay OVERLAY_FILE
Upgrading with an option
The following example does an upgrade and includes the
egressgateways.yaml file from the
package, which enables an egress gateway. Note that you don't include the
.yaml extension. The script fetches the file for you so you don't have to
asm package first.
./install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --mode upgrade \ --enable_all \ --option egressgateways
You can use
enable an optional feature. If you
need to make modifications to any of the files in the
directory in the
asm package, download the
asm package, make your changes,
and include the file using
To download the
asm package to the current working directory so you can
make modifications to the files:
kpt pkg get \ https://github.com/GoogleCloudPlatformemail@example.com asm
If you ran the Only validate example where you specified
--output_dir option, then the configuration files are in the specified
output directory under
Deploying and redeploying workloads
Your installation isn't complete until you enable automatic sidecar proxy
injection (auto-injection). Migrations from OSS Istio and upgrades follow the
revision-based upgrade process (referred to as "canary upgrades" in the Istio
documentation). With a revision-based upgrade, the new version of
installed alongside the existing
istiod. You then move some of your workloads
to the new version, which lets you monitor the effect of the upgrade with a
small percentage of the workloads, before migrating all of the traffic to the
The script adds a revision label in the
istiod. To enable auto-injection,
add a matching revision label to your namespace(s). The revision label is used
by the sidecar injector webhook to associate injected sidecars with a particular
istiod revision. After adding the label, restart the Pods in the namespace for
sidecars to be injected.
Follow these steps to enable auto-injection.
Set the current context for
gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID
Use the following command to locate the revision label on
kubectl -n istio-system get pods -l app=istiod --show-labels
The output from the command is similar to the following. Note that the output for migrations is slightly different than for upgrades. The following example output is from a migration.
NAME READY STATUS RESTARTS AGE LABELS istiod-7744bc8dd7-qhlss 1/1 Running 0 49m app=istiod,istio.io/rev=default,istio=pilot,pod-template-hash=7744bc8dd7 istiod-asm-183-2-85d86774f7-flrt2 1/1 Running 0 26m app=istiod,istio.io/rev=asm-183-2,istio=istiod,pod-template-hash=85d86774f7 istiod-asm-183-2-85d86774f7-tcwtn 1/1 Running 0 26m app=istiod,istio.io/rev=asm-183-2,istio=istiod,pod-template-hash=85d86774f7
In the output, under the
LABELScolumn, note the value in the
istiodrevision label for the new version, which follows the prefix
istio.io/rev=. In this example, the value is
Also note the value in the revision label for the old
istiodversion. You need this to delete the old version of
istiodwhen you finish moving workloads to the new version. In the example output, the value in the revision label for the old version of
Add the revision label to a namespace and remove the
istio-injectionlabel (if it exists). In the following command, change
REVISIONto the value that matches the new revision of
kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite
If you see
"istio-injection not found"in the output, you can ignore it. That means that the namespace didn't previously have the
istio-injectionlabel. Because auto-injection fails if a namespace has both the
istio-injectionand the revision label, all
kubectl labelcommands in the Anthos Service Mesh documentation include removing the
Restart the Pods to trigger re-injection.
kubectl rollout restart deployment -n NAMESPACE
Verify that your Pods are configured to point to the new version of
kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION
Test your application to verify that the workloads are working correctly.
If you have workloads in other namespaces, repeat the steps to label the namespace and restart Pods.
If you are satisfied that your application is working as expected, continue with the steps to transition to the new version of
istiod. If there's an issue with your application, follow the steps to rollback.
Complete the transition
If you are satisfied that your application is working as expected, remove the old control plane to complete the transition to the new version.
Delete the old version of
istiod. In the following command, replace
OLD_REVISIONwith the revision label for the previous version of
kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
Remove the old version of the
kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
The expected output is similar to the following:
istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
If you encountered an issue when testing your application with the new version of
istiod, follow these steps to rollback to the previous version:
Relabel your namespace to enable auto-injection with the previous version of
istiod. The command that you use depends on whether you used a revision label or
istio-injection=enabledwith the previous version.
If you used a revision label for auto-injection:
kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
If you used
kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
Confirm that the revision label on the namespace matches the revision label on the previous version of
kubectl get ns NAMESPACE --show-labels
Restart the Pods to trigger re-injection so the proxies have the previous version:
kubectl rollout restart deployment -n NAMESPACE
Redeploy the previous version of the
kubectl -n istio-system rollout undo deploy istio-ingressgateway
Expected output on success:
deployment.apps/istio-ingressgateway rolled back
Remove the new version of
istiod. Make sure that the value of
REVISIONin the following command is correct.
kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
Remove the new version of the
kubectl delete IstioOperator installed-state-REVISION -n istio-system
Expected output is similar to the following:
istiooperator.install.istio.io "installed-state-REVISION" deleted
If you didn't include the
--disable_canonical_serviceflag, the script enabled the Canonical Service controller. We recommend that you leave it enabled, but if you need to disable it, see Enabling and disabling the Canonical Service controller.
Viewing the Anthos Service Mesh dashboards
After you have workloads deployed on your cluster with the sidecar proxies injected, you can explore the Anthos Service Mesh pages in the Cloud Console to see all of the observability features that Anthos Service Mesh offers. Note that it takes about one or two minutes for telemetry data to be displayed in the Cloud Console after you deploy workloads.
Access to Anthos Service Mesh in the Cloud Console is controlled by Identity and Access Management (IAM). To access the Anthos Service Mesh pages, a Project Owner must grant users the Project Editor or Viewer role, or the more restrictive roles described in Controlling access to Anthos Service Mesh in the Cloud Console.
In the Google Cloud Console, go to Anthos Service Mesh.
Select the Cloud project from the drop-down list on the menu bar.
If you have more than one service mesh, select the mesh from the Service Mesh drop-down list.
To learn more, see Exploring Anthos Service Mesh in the Cloud Console.
In addition to the Anthos Service Mesh pages, metrics related to your services (such as the number of requests received by a particular service) are sent to Cloud Monitoring, where they appear in the Metrics Explorer.
To view metrics:
In the Google Cloud Console, go to the Monitoring page:
Select Resources > Metrics Explorer.
For a full list of metrics, see Istio metrics in the Cloud Monitoring documentation.