Istio 1.23 changes ambient coverage and installation ownership

Istio 1.23 expands ambient's practical coverage while narrowing the installation mechanisms maintained inside the project. The August 14 announcement adds waypoint support for DestinationRule and DNS ServiceEntries, among other changes. It also deprecates the in-cluster operator. These developments concern different parts of the system, but both clarify where an administrator should expect a particular responsibility to live.

Ambient's new capabilities address requirements left outside its first beta scope. The operator change addresses a privileged controller whose main purpose is installing the mesh components. One expands a supported operating model and the other begins retiring an installation option. Neither means that existing applications must immediately stop using their current proxies or that every IstioOperator YAML file becomes obsolete.

I regard both changes through the cost of operating the mesh. Ambient needs enough compatibility and traffic-management coverage to justify a change in data plane. Installation tooling needs a clear owner and a useful continuing responsibility. A controller should not remain in the cluster solely because installing another controller once seemed like the natural way to manage Kubernetes software.

Waypoint coverage becomes more useful

The release adds DestinationRule support in waypoint proxies. It also adds DNS ServiceEntry support in both waypoints and ztunnel. These are important distinctions because ambient divides traffic handling between components with different responsibilities. A capability in the sidecar model does not automatically exist in each ambient component merely because the configuration API is familiar.

The announcement additionally supports sharing waypoints across namespaces. That expands the relationship between the traffic-processing component and the resources using it. A waypoint need not have a scope identical to the namespace containing every application it serves. This makes explicit attachment and ownership more important, because the administrative boundary and traffic-processing boundary can differ.

The release adds support for the Service trafficDistribution field as well. Its purpose includes keeping traffic within local zones or regions. This is another case in which a Kubernetes resource expresses routing intent that the selected mesh implementation must understand.

Dual-stack and IPv6 cluster support also appears among the highlights. The announcement names pod-startup fixes and improvements for Services without selectors. Those details are useful evidence of the compatibility work behind the release. Supporting a real installation involves lifecycle and Service-discovery arrangements in addition to the most visible routing features.

Istio reports throughput improvements of up to 50 percent over 1.22 in its tests. That is a project-reported result with a particular comparison, not a universal prediction for every workload. The release's more general architectural consequence is broader ambient applicability. The installed topology and the traffic functions enabled still determine the work each proxy performs.

DNS allocation becomes persistent state

The release introduces a new DNS address-allocation implementation. Allocated addresses are persisted in ServiceEntry status rather than depending on the older arrangement, which could occasionally reshuffle allocations. The announcement describes the new storage of allocation results as a reliability improvement and a way to make the feature work with ambient.

Persisting the result changes the information available to an operator. The allocation has an API representation attached to the resource it describes. That is easier to inspect than reconstructing why an internal allocation process currently associates a name with an address. The stored status also gives the implementation a stable result to preserve across later processing.

The feature remains off by default in 1.23. The announcement names PILOT_ENABLE_IP_AUTOALLOCATE=true as the enablement setting. Availability of the new implementation should therefore not be described as automatic migration for every upgraded cluster. An operator chooses to adopt it and needs the surrounding DNS-proxy configuration that makes the allocation relevant.

I prefer the explicit status representation because it exposes a decision that affects routing. A generated address is part of how clients reach the intended service. If that decision changes unexpectedly, the operator needs a concrete object state to inspect. Persisting the allocation makes the implementation's current result part of the resource model.

Retry preview addresses connection reuse

The announcement also introduces an optional inbound retry improvement. Historically, retries occurred on outbound traffic, where another attempt could select a different pod. The identified gap occurs when the application has closed a connection the proxy kept alive and attempts to reuse. The release adds detection and retry for that scenario.

This is a specific transport failure, rather than a general instruction to retry every unsuccessful application operation. The setting is ENABLE_INBOUND_RETRY_POLICY=true, and it is a preview in this release. The project expects it to reduce a common source of 503 responses, but the announcement does not make it the default in 1.23.

The distinction between outbound and inbound behavior is operationally useful. Choosing another pod and recovering from a locally stale connection solve different problems. Both may appear to a client as an unsuccessful request, but the location of the retry and the information available to make it differ. The release describes the latter case as a targeted addition.

The operator deprecation targets a running controller

The deprecation announcement states that the change affects the in-cluster operator. Users who run istioctl install with an IstioOperator YAML file are not affected by that deprecation. The configuration format and the controller consuming it are separate things, even though their names invite confusion.

The in-cluster operator is a high-privilege controller that installs mesh components. The announcement contrasts that task with operators responsible for ongoing application administration, such as database backups. Istio does not require those database-style activities for its own control plane. The controller's continuing privilege therefore needs to be evaluated against the narrower work it actually performs.

Its introduction also had a historical context. The project introduced istioctl and the operator in 1.4 amid problems with Helm v2. Helm v3 arrived around the same time and addressed the earlier concerns, with Istio support added in 1.8. The deprecation account explains why a mechanism created for an older packaging problem became less compelling as the alternatives improved.

The project had already discouraged the operator for new installations. Formal deprecation in 1.23 begins the final transition toward other installation mechanisms. The release announcement tells users they must migrate before upgrading to 1.24 or later. As of August, that future release is a planned boundary, not an event that has already happened.

Installation still requires an owner

Helm and istioctl remain supported by the Istio project. Moving to either changes how installation and upgrades are invoked, but it does not remove the need to maintain the desired configuration. The relevant question is which tool applies it and which process is responsible for keeping the installed components aligned with it.

The deprecation announcement notes that installing an operator already requires managing the installation of something. The operator introduces another level of configuration and another privileged component. That can be justified when the controller automates valuable ongoing behavior. For Istio's installer, the project concludes that supporting the simpler established mechanisms is a better maintenance arrangement.

There are ecosystem operator alternatives for users who need that pattern. The announcement distinguishes those projects from support by Istio core. An operator-style interface can remain available without its implementation and maintenance commitment belonging to the main project. That distinction is part of selecting an installation mechanism, not just choosing a familiar YAML kind.

API consumers have a separate upgrade concern

The 1.23 upgrade notes consolidate duplicate protobuf definitions across API versions. Kubernetes YAML users are unaffected. Go users generally retain compatibility through type aliases, while reflection-heavy code can observe differences. Direct protobuf consumers of newer duplicated versions have a different impact because those definitions are no longer included in the same form.

This change is separate from API version support through Kubernetes. It concerns the code and protobuf representation used by software importing Istio's API packages. A manifest can continue using a served API while a custom tool needs attention to its generated-type assumptions. The upgrade notes preserve that distinction explicitly.

The release consequently asks for several different kinds of ownership to be understood. Waypoints and ztunnel gain specific traffic capabilities, DNS allocation gains persistent API state, and installation moves away from the in-cluster controller. The affected configuration and its consumer determine the transition required. That is a more useful account of 1.23 than treating every change as one general ambient upgrade.