Istio extends 1.9 support to create a two-release upgrade window

A quarterly release schedule does not require every user to upgrade quarterly, but a supported path needs enough overlap between the releases involved. Istio's 3 September support announcement extends 1.9 support by six weeks, through 5 October, to create more time for that transition.

The project explicitly permits two destinations. Users can move from 1.9 to 1.10 or directly to 1.11. Overlapping support for 1.9 and 1.11 is intended to support a twice-yearly upgrade cadence for users moving across two minor versions.

I find Istio's operating cost significant, so reducing how often a fleet must coordinate upgrades is useful. The value depends on having a defined support interval and a clear account of what maintenance it includes. The announcement supplies both without declaring a new long-term-support product.

The extension has a narrow maintenance scope

During the extra support period, Istio 1.9 receives CVE and critical bug fixes only. The goal is migration time, not a promise that ordinary improvements or every reported defect will be backported.

That scope matters when deciding whether to remain temporarily on the release. An extended security-maintenance interval is different from continued feature development. A user waiting for a new capability still needs a release that includes it.

The end date is equally important. The project names 5 October as the boundary for this extension. A support announcement that adds six weeks should not be interpreted as an indefinite commitment to retain 1.9.

The twice-yearly cadence is an intended operating pattern. The source does not establish an immutable policy for every future version pair. It asks users whether two upgrades per year and a six-week window fit their needs.

This leaves quarterly upgrades available to users who prefer every minor release. The change offers another consumption pattern while the project continues to produce those releases.

Skipping an installation does not skip its changes

A direct move from 1.9 to 1.11 still encounters the behavior introduced between those versions. The extension reduces the number of coordinated upgrade events, but it does not remove the intermediate changes from the destination software.

The 1.10 announcement identifies inbound networking as one such change. Envoy sends traffic to the application on the Pod interface by default instead of redirecting it to loopback. Applications that deliberately bind to only one interface can observe a difference.

The same release introduces revision tags. These let namespaces refer to a stable alias whose target is a concrete control-plane revision. They reduce repeated namespace relabeling, but a direct upgrade still needs to understand how namespaces select the intended injector.

Those are substantive changes in the destination path even if 1.10 is never installed as a separate operational step. A two-release upgrade combines the changes that would otherwise be encountered in two stages.

The destination has explicit compatibility notes

The 1.11 upgrade notes describe differences relative to 1.10. They include changes to remote-control-plane installation and Prometheus host-header fallback, as well as lower-level EnvoyFilter matching.

The EnvoyFilter example is particularly instructive. Previously, each domain name had its own virtual host. An optimization can combine multiple domains into one virtual host, so a filter matching a specific virtual-host name may affect more domains.

That is a change in the generated configuration a low-level filter matches. The notes explicitly warn that EnvoyFilter matching depends on internal implementation details. A manifest remaining syntactically valid does not establish unchanged matching behavior.

The CNI DaemonSet also acquires a hostPath for collecting plugin logs. Clusters with a PodSecurityPolicy allowlist for that DaemonSet must include /var/run/istio-cni. The notes say CNI will not start without that policy adjustment where the restriction applies.

These examples make the support extension concrete. Extra time can be used to resolve known destination requirements instead of being spent merely waiting for a calendar date.

Release cadence and upgrade cadence are separate decisions

The project continues to describe quarterly releases for users wanting every feature as it arrives. The support overlap lets another group aim for fewer upgrades by selecting a supported destination two minor versions ahead.

This is useful because release production and deployment coordination have different costs. Upstream can ship improvements regularly while a fleet chooses when to absorb them, provided the support intervals leave a legitimate path.

My judgement is that the extension helps most by making that path explicit. It defines the temporary maintenance scope, names the deadline, and recognizes a direct 1.9-to-1.11 migration as an intended route.

For users remaining on 1.9 during the extension, CVE and critical fixes remain the available maintenance commitment. The destination can be 1.10 or 1.11, with the latter combining the intervening behavior changes into one coordinated upgrade before the extended support period ends.