Istio 1.20 Upgrade Notes
Important changes to consider when upgrading to Istio 1.20.
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
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
ExternalName support changes
The following information describes upcoming changes to
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.
Services allow users to create new DNS entries. For example, you can create an
that points to
example.com. This is implemented by a DNS
In Istio, the implementation of
ExternalName, historically, was substantially different. Each
represented its own
service, and traffic matching the service was sent to the configured DNS name.
This caused a few issues:
- Ports are required in Istio, but not in Kubernetes. This can result in broken traffic if ports are not configured as Istio expects, despite them working without Istio.
- Ports not declared as
HTTPwould match all traffic on that port, making it easy to accidentally send all traffic on a port to the wrong place.
- Because the destination DNS name is treated as opaque, we cannot apply Istio policies to it as expected. For example,
if an external name points to another in-cluster Service (for example,
example.default.svc.cluster.local), mTLS would not be.
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:
portsfield is no longer needed, matching Kubernetes behavior. If it is set, it will have no impact.
VirtualServicesthat match on an
ExternalNameservice will generally no longer match. Instead, the match should be rewritten to the referenced service.
DestinationRulecan no longer apply to
ExternalNameservices. Instead, create rules where the
hostreferences the service.
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:
- Metadata Exchange
- CUSTOM Authz
- WASM Authn
- WASM Authz
- WASM Stats
- WASM unspecified
This changes the following areas:
- Inbound TCP filters now place Metadata Exchange before Authn.
- Gateway TCP filters now place stats after Authz, and CUSTOM Authz before Authn.
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