Upgrading Istio on GKE

This guide contains upgrade notes for any releases that have specific upgrade instructions. You don't need to do anything for upgrades that aren't mentioned in this guide.

Upgrading from Istio 1.1.3

The Istio on GKE add-on version 1.1.3-gke.0 has PodDisruptionBudget (PDB) definitions that require the minimum number of available replicas to be at least 1. As of version 1.1.7-gke.0, the add-on no longer has this requirement. However, once this PDB is installed, it prevents upgrading to any other version if it violates the PDB. This means that to upgrade from 1.1.3-gke.0 to any higher version 1.1.x (such as 1.1.7-gke.0), it's necessary to first increase the minReplicas value for all Istio HorizontalPodAutoscaler resources to at least 2, otherwise the upgrade will fail due to PodDisruptionBudget violation.

Upgrading to Istio 1.1

Before upgrading a GKE cluster from 1.0.x to 1.1.x, you should ensure that your configuration is compatible with 1.1. The following changes in Istio 1.1 are potentially backwards incompatible and might require you to update your configuration to avoid breaking or unexpected behavior. We recommend you run our upgrade script to help you check your configuration.

TLS behavior override via annotations

In 1.0, you modify TLS policy through annotations. In 1.1 these annotations don't work and require that you configure a Policy and DestinationRule instead. See the Istio doc for details.

Upgrade process

Replace the annotations with a Policy and DestinationRule, according to the Istio docs. This change doesn't break your 1.0 configuration. After you upgrade to 1.1, the old annotations won't have any effect, so you can delete the old annotations or leave them in place.

RbacConfig to ClusterRbacConfig renaming

RbacConfig CRD is renamed to ClusterRbacConfig. The schema is unchanged.

Upgrade process

Create an identical ClusterRbacConfig CR for every RbacConfig CR.

Destination rule precedence

During sidecar routing to a service, destination rules for the target service in the same namespace as the sidecar take precedence, followed by destination rules in the service's namespace, and finally followed by destination rules in other namespaces, if applicable.

Upgrade process

Check your DestinationRules to see if they have rules in multiple namespaces for the same target service. If so, examine the rules closely to see how they overlap, and make sure that the correct precedence applies for your desired behavior.

Was this page helpful? Let us know how we did:

Send feedback about...

Istio on GCP