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