Istio 1.28 makes ambient networking upgrades more explicit

A mesh upgrade can change both the network rules that capture a connection and the API through which a gateway chooses its destination. Those changes do not have the same activation point. Istio 1.28 adds an optional ambient redirection backend while removing support for some early Gateway API resource versions.

The November 5 release announcement introduces native nftables in ambient mode and promotes dual-stack support to beta. It also adds InferencePool v1 and improves ambient waypoint routing across networks. The result is a broader set of supported mechanisms, with several distinct compatibility boundaries during upgrade.

I value Istio when identity and traffic policy are worth the additional distributed system. This release makes the implementation choices behind those policies more visible. The important question is which capture path and resource version the running workload actually uses, not merely whether the control plane has the latest minor version.

Native nftables reaches ambient capture

The release extends native nftables support from sidecar mode to ambient mode. This is the backend used for Istio's network redirection rules. It changes how the implementation expresses capture, while leaving the broader purpose of steering traffic through the mesh intact.

The announcement gives an explicit installation setting. This is a fragment for an existing installation command, and does not by itself describe a complete ambient deployment.

--set values.global.nativeNftables=true

The opt-in matters because capability and activation are separate. Upgrading the Istio version does not establish that every node or Pod has switched to native nftables. The installation values and the resulting redirection state determine that behavior.

It also remains separate from kube-proxy's Service implementation. A node may use one backend for Service forwarding and another for mesh interception. Both components can operate on network traffic without owning the same rules or expressing the same decisions. The word nftables needs to be associated with the component whose configuration is being described.

The detailed change notes also add FORCE_IPTABLES_BINARY for overriding iptables backend detection. That addresses the older command-based path. A configuration override for detecting an iptables binary should not be confused with opting into native nftables.

Dual-stack support reaches beta in the same release. That concerns operation with IPv4 and IPv6, which is another dimension of network behavior. Selecting a rule-management backend does not itself establish that both address families have been configured correctly. The release's maturity statement identifies progress in dual-stack support without making it synonymous with native nftables.

InferencePool stability removes earlier representations

InferencePool v1 arrives with the continued Gateway API Inference Extension integration. The upgrade notes explicitly remove support for alpha and release-candidate versions. This is a concrete compatibility change for early adopters, rather than an additive alias that preserves every previous manifest.

The notes identify a field change for users migrating from v1.0.0-rc.1. An endpoint-picker port now uses endpointPickerRef.port.number instead of endpointPickerRef.portNumber. The nested port is required when kind is omitted or set to Service, and the previous inferred value of 9002 is gone.

This is the relevant v1 field shape. It is a fragment of an InferencePool specification, with the endpoint-picker name chosen for illustration.

endpointPickerRef:
  name: endpoint-picker
  port:
    number: 9002

An older manifest that relied on omission now needs an explicit value. That is more than a renamed property because the defaulting behavior changes too. A conversion that only changes the API version without inspecting the endpoint-picker fields can leave an invalid or incomplete resource.

The endpoint picker is a service in the request path. Its address and port must identify the implementation that makes inference-aware selection decisions. A stable schema improves the contract for referring to it, but it does not create that service or verify the model metrics it consumes.

This makes the upgrade's required evidence specific. The new resource must use the supported API version and express a valid picker reference. The gateway then needs to resolve and use that reference. Accepting the manifest and successfully selecting an inference endpoint are successive observations, not one event.

Backend TLS policy also crosses a version boundary

Istio upgrades Gateway API support to v1.4 and supports BackendTLSPolicy v1. The upgrade notes remove the older v1alpha3 version. They also say the earlier alpha feature setting is no longer needed for the stable policy.

That changes both resource compatibility and activation assumptions. Before this release, a BackendTLSPolicy could be ignored unless PILOT_ENABLE_ALPHA_GATEWAY_API was explicitly true. With v1 support, relying on that old default-disabled behavior is no longer an accurate description of how the supported policy is handled.

The release adds ServiceEntry as a target reference and sectionName for port-specific policy. That lets TLS settings target an external service or a particular named Service port. A policy can therefore have a narrower purpose than applying one TLS choice to all traffic associated with a backend name.

The boundary is between transport configuration and destination discovery. A ServiceEntry identifies an external service to the mesh. BackendTLSPolicy expresses how a gateway should use TLS toward the selected target. Supporting both does not mean a policy can repair a destination that the data plane does not recognize.

Older ztunnels can reject a newly generated service type

The upgrade notes describe an ambient behavior change for ServiceEntries whose resolution is NONE. The corrected implementation treats these as PASSTHROUGH services, using the address the client called as the backend. Previously, the configuration could contain a virtual IP without endpoints and produce a no-healthy-upstream error.

Older ztunnel images do not understand the new service type and can reject the xDS update during a rolling upgrade. The notes identify this as expected until the data plane is updated. A control plane upgrade therefore creates an interval where valid new configuration is not yet understandable to every proxy.

The consequence depends on whether the service already exists. A rejected update can leave existing configuration unchanged. For a new service, the older data plane can behave as though the ServiceEntry is absent. The notes say that can prevent ztunnel from determining whether a waypoint is required.

This is more useful than describing every NACK as an unexplained synchronization failure. The rejected type identifies a concrete version mismatch. Updating ztunnel to a version that understands the type resolves that compatibility boundary. The observation also explains why control plane readiness alone cannot establish completion of this upgrade.

I consider this one of the more consequential details in the release. A destination's discovery representation participates in deciding whether it traverses a policy-enforcing waypoint. During version skew, inability to understand that representation can affect the path, not only a diagnostic status field.

Cross-network waypoint routing remains alpha

Ambient waypoints can now route to remote networks, enabling layer-seven policy and outlier detection for requests crossing those boundaries. The announcement explicitly retains ambient multicluster's alpha status and warns about known issues. More functionality does not itself promote the whole topology to beta or stable.

The release provides AMBIENT_ENABLE_MULTI_NETWORK_WAYPOINT=false as a way to disable the changed waypoint behavior if it causes problems. That is a control over the recent multicluster change. It does not switch off every ambient capability or turn the installation back into a sidecar topology.

The same announcement adds wildcard ServiceEntry hosts with DYNAMIC_DNS resolution, but only for HTTP traffic through an ambient egress waypoint. That condition matters because a wildcard hostname needs application-level context that a general layer-four connection cannot always provide. The feature should not be generalized to every TCP connection to an external address.

Installation ownership can also be divided more explicitly. The charts add resourceScope choices for namespace-scoped or cluster-scoped resources, while leaving the unset behavior equivalent to the earlier all-resources installation. This supports different administrators managing those scopes independently. For ztunnel the value is top-level, while other charts place it under global. That chart-specific location matters when sharing installation values. A value written at the wrong level would not reliably express the intended division, even if the administrator's desired ownership model is otherwise clear.

The release therefore needs a more precise description than improved ambient networking. Native nftables is an explicit capture choice, dual-stack has beta maturity, and cross-network waypoints remain alpha. InferencePool and BackendTLSPolicy move to stable API versions with migration requirements. Recording those choices alongside the data plane version makes the desired traffic path understandable during the interval when new configuration and old proxies coexist.