Istio 1.30 adds agentgateway as an experimental gateway data plane

Istio 1.30 introduces an experimental gateway that uses agentgateway in place of Envoy on the gateway pod. The integration targets AI-agent and MCP-server traffic. Its significance is the separation it makes visible between the controller interpreting Gateway API resources and the proxy executing the resulting traffic behavior.

The initial role is deliberately narrow. Agentgateway is available through the istio-agentgateway GatewayClass and is supported only as a Gateway API gateway. It is not a sidecar or waypoint implementation in this release. The pilot flag PILOT_ENABLE_AGENTGATEWAY=true enables the experimental integration. Installing Istio 1.30 does not automatically replace existing Envoy data planes.

My interest in Istio comes from applying identity and traffic policy consistently across a polyglot fleet. After five years with it, the additional distributed system remains a cost that needs a concrete justification. A specialized proxy behind a familiar configuration model is interesting, but a shared API does not establish identical implementation behavior. The narrow experimental role makes the actual adoption decision easier to describe.

A GatewayClass identifies an implementation choice

The release announcement says agentgateway replaces Envoy on the gateway pod when enabled. That is a change to the process handling the traffic, while Istio continues accepting Gateway API configuration for the integration. The change notes identify the feature as experimental and connect it to the control-plane feature flag.

This architecture allows the project to introduce a different proxy without requiring every mesh workload to change its data plane. A gateway has an explicit configured role. A sidecar or ambient waypoint has another role, with different integration requirements. The announcement's exclusions matter because support for the first role cannot be generalized to the others.

The release does not provide a basis for claiming that the new proxy improves every workload or replaces ordinary gateway operation. It identifies the traffic category the implementation is built for and labels the support early access. That leaves room for a focused evaluation of the specialized gateway while the rest of the mesh continues using its established components.

A common Gateway API resource model can reduce configuration novelty. It does not eliminate the need to understand which resources and behaviors a given implementation supports. The controller must translate the declarations into a data plane's own capabilities. The experimental integration is the place where that translation is being introduced in Istio.

Existing gateways need the new CRD versions too

The Istio 1.30 upgrade notes describe a prerequisite that affects existing Gateway API users independently of agentgateway. Istio updates its dependency to Gateway API 1.5.1. It reads TLSRoute and ReferenceGrant from the Standard channel's gateway.networking.k8s.io/v1 version.

If the cluster's CRDs are not upgraded to 1.5.x, those resources become invisible to istiod. The notes describe existing TLS passthrough listeners reporting zero attached routes and not receiving a programmed Envoy listener. This is a concrete example of a controller upgrade depending on an API installation managed elsewhere in the cluster.

The declared route can still exist while the upgraded controller no longer reads the expected version. Looking only for the resource would therefore miss the reason traffic configuration stopped appearing. The required sequence includes installing compatible Gateway API CRDs before upgrading Istio. The controller and extension API cannot be treated as unrelated version choices.

This requirement applies whether or not the installation uses the new experimental proxy. Agentgateway is an opt-in capability, while the CRD dependency concerns the resource versions Istio 1.30 consumes. Combining those into one general gateway-upgrade decision would hide a mandatory compatibility step behind an optional feature evaluation.

Ambient identity can be represented in XFCC

The release adds optional synthesis of x-forwarded-client-cert at ambient waypoints. With ambient.istio.io/xfcc-include-client-identity: "true" on a waypoint Gateway or its GatewayClass, the waypoint creates an XFCC value from the source workload SPIFFE identity supplied by ztunnel. The change notes explicitly say that any inbound XFCC value is replaced.

That replacement is an important part of the mechanism. A header arriving from the caller is different evidence from a header constructed using the identity supplied by the mesh. The release describes overwriting the former with the latter. Upstream applications can then receive the originating client identity through the synthesized header rather than whatever header content arrived with the request.

The annotation is opt-in, and unannotated waypoints retain their existing behavior. The change is also separate from agentgateway's experimental gateway role. It concerns the established ambient waypoint path in this release. The shared word gateway should not obscure which process and traffic path implements the feature.

For me, this is a useful extension of the workload-identity model when an application needs an explicit representation of the original client. Its value depends on preserving the provenance described in the change notes. The application should interpret the header in the context of the actual waypoint path, with the configuration defining where synthesis occurs.

CIDR routes reduce endpoint enumeration

Ambient ServiceEntry resources can now contain CIDR addresses propagated to ztunnel. The notes describe longest-prefix-match routing for traffic destined to address ranges. That allows configuration to describe a range without enumerating each address as a separate workload endpoint.

The configuration becomes more compact because the routing model now recognizes the range directly. This also means the range itself becomes a consequential policy input. An operator needs to understand which addresses a ServiceEntry covers when several ranges are present, because longest-prefix matching determines the more specific routing choice.

HBONE CONNECT clusters gain configurable initial HTTP/2 stream and connection windows through pilot flags. The release identifies these for waypoints and east-west gateways and discusses reducing unwanted buffering. They are traffic-transport controls with a different purpose from CIDR selection. The former governs the connection's flow behavior, while the latter identifies how destinations enter the routing configuration.

The release also adds a WaypointBound condition to WorkloadEntry status. That makes a workload's attachment to its waypoint observable as a resource state. It is useful evidence about binding configuration without substituting for the identity and routing decisions implemented after attachment.

Helm support includes field ownership

Istio 1.30 supports Helm v4 and server-side apply. The change notes explain a webhook failurePolicy ownership conflict behind earlier upgrade failures. The webhook controller sets that field at runtime, while the rendered configuration could attempt to manage it during an upgrade. Two actors then claimed responsibility for the same value.

The correction omits failurePolicy from the webhook template during upgrades for tools respecting .Release.IsUpgrade, including Helm 4 and Flux. Tools using helm template with server-side apply have separate guidance to set base.validationFailurePolicy: Fail. The difference follows the rendering path's ability to express that an operation is an upgrade.

This is more specific than simply making a chart compatible with a new Helm version. The fix clarifies ownership between installation tooling and the running controller. A generated manifest can have a plausible value and still conflict with the actor intended to maintain that value. Server-side apply exposes that disagreement through field ownership.

The CNI agent now respects excluded namespaces consistently with the CNI plugin. The upgrade notes say already-enrolled pods in excluded namespaces are unenrolled, and new ambient-labeled pods there are not enrolled. This is an existing-workload behavior change. A namespace label alone no longer describes enrollment when the namespace also appears in the exclusion configuration.

Resource selection also changes for existing sidecars

The upgrade notes change how sidecars choose a service when one hostname exists across multiple namespaces. Kubernetes Service resources now take precedence, with the oldest non-Kubernetes service as the fallback. The previous choice used the first visible namespace alphabetically. Identical configuration can therefore route to a different service instance after the upgrade.

That change demonstrates why adoption cannot be described solely through newly added capabilities. An installation that never enables agentgateway still receives compatibility-relevant changes in resource selection. The notes provide PILOT_SIDECAR_PICK_BEST_SERVICE_NAMESPACE=false or a suitable compatibility version to restore the earlier choice where required.

The May release broadens the implementations and configuration paths available to Istio. My preference is to judge each against the responsibility it actually assumes. Agentgateway adds a specialized experimental gateway. Existing Envoy and ambient paths receive their own routing and identity changes. The CRD and Helm requirements explain how the control plane continues to receive and own the configuration those paths depend on.