Istio 1.20 Upgrade Notes

Important changes to consider when upgrading to Istio 1.20.

Nov 14, 2023

When you upgrade from Istio 1.19.x to Istio 1.20.x, you need to consider the changes on this page. These notes detail the changes which purposefully break backwards compatibility with Istio 1.19.x. The notes also mention changes that preserve backwards compatibility while introducing new behavior. Changes are only included if the new behavior would be unexpected to a user of Istio 1.19.x.

Upcoming ExternalName support changes

The following information describes upcoming changes to ExternalName.

In this release, there are no behavioral changes by default. However, you can explicitly opt in to the new behavior early if desired, and prepare your environments for the upcoming change.

Kubernetes ExternalName Services allow users to create new DNS entries. For example, you can create an example service that points to example.com. This is implemented by a DNS CNAME redirect.

In Istio, the implementation of ExternalName, historically, was substantially different. Each ExternalName represented its own service, and traffic matching the service was sent to the configured DNS name.

This caused a few issues:

ExternalName support has been revamped to fix these problems. ExternalNames are now simply treated as aliases. Wherever we would match Host: <concrete service> we will additionally match Host: <external name service>. Note that the primary implementation of ExternalName DNS is handled outside of Istio in the Kubernetes DNS implementation, and remains unchanged.

If you are using ExternalName with Istio, please be advised of the following behavioral changes:

These changes are off-by-default in this release, but will be on-by-default in the near future. To opt in early, the ENABLE_EXTERNAL_NAME_ALIAS=true environment variable can be set.

Envoy filter ordering

This change impacts internal implementation of how Envoy filters are ordered. These filters run in order to implement various functionality.

The ordering is now consistent across inbound, outbound, and gateway proxy modes, as well as HTTP and TCP protocols:

This changes the following areas:

startupProbe added to sidecar by default

The sidecar container now comes with a startupProbe enabled by default. Startup probes run only at the start of the pod. Once the startup probe completes, readiness probes will continue.

By using a startup probe, we can poll for the sidecar to start more aggressively, without polling as aggressively throughout the entire pod’s lifecycle. On average, this improves pod startup time by roughly one second.

If the startup probe does not pass after 10 minutes, the pod will be terminated. Previously, the pod would never be terminated even if it was unable to start indefinitely.

If you do not want this feature, it can be disabled. However, you will want to tune the readiness probe accordingly.

The recommended values with the startup probe enabled (the new defaults):

readinessInitialDelaySeconds: 0
readinessPeriodSeconds: 15
readinessFailureThreshold: 4
startupProbe:
enabled: true
failureThreshold: 600

The recommended values to disable the startup probe (reverting the behavior to match older Istio versions):

readinessInitialDelaySeconds: 1
readinessPeriodSeconds: 2
readinessFailureThreshold: 30
startupProbe:
enabled: false