Istio 1.20 makes ExternalName an explicit alias experiment

A DNS alias should not accidentally become a separate traffic-management identity with different policy behaviour. Istio's historical treatment of Kubernetes ExternalName services created that possibility. It represented each name as its own service and sent matching traffic to the configured DNS destination. The result differed from Kubernetes' simpler DNS alias model in ways that could affect routing and policy.

Istio 1.20, released on November 14, offers a revised alias implementation. The upgrade notes are explicit that it is disabled by default in this release. Users can opt in with ENABLE_EXTERNAL_NAME_ALIAS=true and prepare for a later default change. Installing 1.20 alone therefore does not select the new behaviour.

I value the ability to apply traffic and security policy consistently through a mesh. That requires the policy target to remain understandable when DNS names refer to the same destination. An alias that creates another policy interpretation adds complexity to a mechanism that applications often expect to be a straightforward name indirection.

A Kubernetes alias became an Istio service

The upgrade notes describe Kubernetes ExternalName as creating a DNS entry through a CNAME redirect. A Service named example can point to example.com. The Kubernetes DNS implementation handles that aliasing. Istio's revised behaviour does not change that DNS implementation.

Historically, Istio treated the ExternalName as its own service with traffic sent to the named destination. That introduced a requirement for ports even though Kubernetes did not require them for the same declaration. A resource that worked outside the mesh could therefore need additional configuration inside it.

The notes identify a broader matching problem as well. A port not declared as HTTP could match all traffic on that port, making it possible to redirect unrelated traffic to the wrong destination. The consequence came from constructing service-routing behaviour around the alias instead of preserving only the intended name relationship.

The target DNS name was also opaque to the historical implementation. Istio could not apply policies to it in the expected way. The upgrade notes give another in-cluster Service as an example where treating the target opaquely interfered with the expected mTLS behaviour. The alias introduced a different interpretation of a destination already known to the mesh.

These are semantic differences, not merely different ways to store the same DNS record. They affect which traffic matches and which service's policy can apply. That is why the release provides an explicit adoption flag and describes changes to existing VirtualService and DestinationRule configurations.

The new model follows the referenced service

With the new behaviour enabled, ExternalName resources are aliases. Where Istio would match a concrete service's host, it also matches the ExternalName service's host. The underlying service remains the target around which routing and policy are described.

Ports on the ExternalName resource are no longer required and have no effect if present. That aligns the relevant configuration requirement with Kubernetes' behaviour. A port list no longer constructs independent matching semantics for the alias, which also addresses the overly broad non-HTTP matching problem described in the notes.

The change affects policy definitions. VirtualServices matching an ExternalName service generally no longer match and should be rewritten to the referenced service. DestinationRules no longer apply to the ExternalName itself. Their host should identify the referenced service instead. Those instructions make the canonical policy target explicit.

An alias can consequently remain useful to an application without becoming an independent place to attach destination policy. The operator needs to connect the names when maintaining configuration, but the policy model follows the service being referenced. This reduces the chance that two names for one destination produce different security expectations.

The upgrade notes qualify the change as upcoming default behaviour. In 1.20, opting in is a deliberate configuration decision. Describing the release as immediately changing all ExternalName routing would misstate the migration boundary and could make an unchanged installation appear inconsistent with the documentation.

Stable Gateway API has a defined policy attachment

Istio 1.20 also supports the newly stable Kubernetes Gateway API. The announcement presents Istio as a fully conformant implementation of the stable feature set. That gives users a shared API for traffic management and ingress configuration, with the stability claim attached to the relevant Gateway API capabilities.

The release adds attachment of Istio AuthorizationPolicy, RequestAuthentication, Telemetry, and WasmPlugin resources to Kubernetes Gateway resources through targetRef. That makes the Gateway an explicit target for these Istio-specific policies and extensions. A common routing API can coexist with implementation capabilities that need their own configuration types.

The 1.20 change notes identify these attachments separately. That is useful for understanding the boundary between Gateway API conformance and additional Istio policy. Supporting the shared routing resources does not make every security or extension setting a field in those resources.

I find explicit targeting valuable for review. A policy attached to a named Gateway can state its intended enforcement location directly. The operator still needs to understand the selected policy's semantics, but the resource relationship no longer has to be inferred solely from conventions around the generated gateway workload.

That concern connects to ExternalName without making the two features identical. Both require a precise answer to which resource a policy describes. The alias change follows the underlying service, while Gateway attachment names the infrastructure resource where the policy should apply. In each case, configuration review benefits from an explicit target.

Filter ordering becomes consistent across proxy roles

The upgrade notes change Envoy filter ordering across inbound, outbound, and gateway modes, including HTTP and TCP. These filters execute in order, so the sequence is part of the implementation of authentication, authorisation, and statistics. A common set of configuration concepts can behave differently if those phases are ordered differently across paths.

The notes identify two changed areas in particular. Inbound TCP metadata exchange now precedes authentication. Gateway TCP statistics move after authorisation, and custom external authorisation moves before authentication. These are implementation-order changes with observable policy-processing implications, rather than additions to the application's DNS configuration.

The purpose stated by the release is consistency. An engineer investigating an inbound proxy and a gateway should have a common ordering model instead of discovering role-dependent differences in the same phases. That does not eliminate the need to inspect generated Envoy configuration, but it gives the inspection a clearer expected sequence.

The release also introduces network WasmPlugin support with type NETWORK. This extends the plugin mechanism beyond the previously familiar application-protocol use. Its placement within the documented ordering remains relevant because an extension's effect depends on when it processes traffic relative to the other filters.

Startup probes separate initial polling from steady-state checks

Sidecar containers receive a startup probe by default in 1.20. The upgrade notes explain that startup probes run during initial startup, after which readiness checks continue. This allows more aggressive initial polling without retaining that polling frequency throughout the pod's life.

The default configuration changes readiness polling to a fifteen-second period with a failure threshold of four and no initial delay. Startup probing is enabled with a failure threshold of six hundred. The notes describe a ten-minute startup limit, after which unsuccessful startup no longer leaves the pod waiting indefinitely as before.

The source reports an average startup improvement of roughly one second. That is the project's reported result, not a timing guarantee for every application or a measurement from my own environment. The mechanism is the separation of startup detection from the longer-lived readiness polling schedule.

Users can disable the startup probe, but the notes also supply different readiness settings for retaining the older behaviour. That relationship matters. Removing one check while retaining timings selected for its presence is a different configuration from reverting the previous checking model.

The same release supports traffic mirroring to multiple destinations in VirtualService. That is another independently selected routing capability. Its availability should be associated with the route that requests mirroring, rather than inferred from an ExternalName alias or a Gateway's existence.

Istio 1.20 is officially supported on Kubernetes 1.25 through 1.28. Its stable Gateway API integration, revised filter ordering, and default startup probe apply to different parts of the operating model. ExternalName aliasing has an additional explicit gate. The release provides enough detail to associate each behaviour with the actual configuration that selects it, including policy rewrites needed before enabling the new alias interpretation.