Istio 1.29 brings ambient multicluster to beta
Ambient multicluster reaches beta with work on attribution and recovery. New defaults for DNS capture and network-rule reconciliation also change what an ambient upgrade does to existing workloads.
An ambient mesh crossing network boundaries needs to explain who sent a request even when a gateway sits between the workloads. That attribution problem is a substantial part of Istio 1.29's ambient multicluster beta. The announcement identifies missing peer information and confusing waypoint labels as areas addressed during the transition. A connection reaching its destination is only part of making the topology usable for operators.
My interest in Istio starts with identity attached to workloads instead of addresses. After five years with it, that remains its strongest justification for me. The cost is another distributed system whose behavior sometimes requires reading Envoy configuration. Multicluster support needs understandable telemetry if it is going to justify extending that operating burden across networks.
This release also changes ambient networking defaults and promotes Gateway API Inference Extension support to beta. The beta labels do not imply identical enablement. Several supporting capabilities remain opt-in or experimental. The detailed change notes are necessary to understand which behavior arrives through an upgrade and which behavior needs an explicit setting.
Attribution has to cross the gateway
The release announcement describes earlier cases where waypoints were incorrectly reported in layer-four metrics and where requests traversing east-west gateways lacked complete peer information. Those deficiencies matter because an operator needs to distinguish the forwarding component from the application workload. Traffic totals with incomplete identity labels provide a narrower explanation of the system than the mesh's policy model suggests.
Istio 1.29 adds an alpha baggage-based telemetry system for ambient mesh. The change notes distinguish ztunnel-generated baggage from waypoint-generated baggage. Ztunnel already sends baggage, while the pilot flag AMBIENT_ENABLE_BAGGAGE enables the additional waypoint behavior. The feature is especially relevant to attribution across networks.
This is a useful example of why feature maturity needs to be read at the capability level. Multi-network multicluster is beta, but the announcement explicitly says some telemetry improvements may require this flag. A mesh can adopt the topology without automatically enabling every new attribution mechanism. The resulting observability depends on the selected settings as well as the release number.
Tracing gains source and destination workload identification at waypoints. The change notes name tags including istio.source_workload and istio.destination_namespace. They also add a gauge, istiod_remote_cluster_sync_status, for synchronization status. These changes give operators information about both the traffic path and the control plane's relationship with remote clusters.
Those two observations answer different questions. A trace can identify the workloads involved in one request. Synchronization status concerns the control plane's current knowledge of a remote cluster. Putting both in the operating model helps distinguish a traffic-policy issue from incomplete or incorrect remote-cluster information.
Existing pods now receive network-rule reconciliation
The upgrade notes describe a change that directly affects existing ambient pods. Iptables reconciliation is now enabled by default. When a new istio-cni DaemonSet pod starts, it inspects previously enrolled ambient pods and updates their in-pod iptables or nftables rules when the current rules differ from the desired state.
Previously, receiving changed networking configuration could require restarting application pods. The new behavior makes the CNI upgrade responsible for reconciling the enrolled population. That changes the scope of an infrastructure upgrade even when the application templates have not changed. The network configuration of an already-running pod can now converge through the CNI lifecycle.
The relevant chart setting is explicit:
cni:
ambient:
reconcileIptablesOnStartup: true
dnsCapture: true
These are the chart-value names documented in the release notes. They represent the new defaults in the appropriate installation values. The actual installation procedure still determines how those values reach the CNI chart. An existing explicit false value is a configuration decision that needs to be considered alongside the changed default.
DNS capture is also enabled by default for ambient workloads. New pods receive it directly. Existing pods need a restart or the reconciliation behavior described above. The two default changes therefore interact. Reconciliation supplies a path for bringing existing pods into the new DNS configuration without treating a control-plane upgrade as evidence that every pod already changed.
This is the kind of operational detail that shapes my view of ambient adoption. Removing a sidecar from each workload does not remove the need to understand how traffic capture changes over time. The CNI and node-level components now carry more of that lifecycle responsibility, and this release makes part of that responsibility automatic.
A dry-run policy can become enforcement under skew
The most consequential upgrade note concerns experimental dry-run AuthorizationPolicy support in ztunnel. Before 1.29, istiod did not send dry-run policies to ztunnel. The new feature uses a new xDS field, enabled with AMBIENT_ENABLE_DRY_RUN_AUTHORIZATION_POLICY=true. A ztunnel older than 1.29 does not understand that field.
The documented consequence is unexpected enforcement. Older ztunnels receiving those policies fully enforce them, even though the operator intended a dry run. This makes component compatibility part of the feature's semantics. The name of a policy mode cannot protect an installation whose receiving data plane lacks the field that expresses the mode.
The feature remains disabled by default. Enabling it requires all ztunnels connecting to that istiod to be new enough to interpret the policy correctly. This is a narrower and more actionable requirement than assuming a healthy control plane establishes compatibility. The relevant population is the set of connected ztunnels that will receive the new field.
For a mesh whose purpose includes uniform policy, the distinction is fundamental. A declared authorization rule and a data-plane interpretation must agree about whether enforcement is active. Experimental dry-run support introduces a new interpretation requirement, so it belongs in the component upgrade sequence before the flag changes.
Identity controls and inference support have separate switches
Ztunnel gains certificate revocation list support for plugged-in certificate authorities. The change notes describe istiod distributing CRLs when a ca-crl.pem file is provided. This extends the certificate-validation behavior for deployments that bring their own CA material. It does not mean every installation automatically has a revocation list to distribute.
Debug endpoints on port 15014 also receive namespace-based authorization by default. Non-system namespaces are restricted to specific endpoints and same-namespace proxies. The upgrade notes identify Kiali and custom monitoring tools as possible affected consumers. A restriction on diagnostic access can be a deliberate security improvement while still requiring a change to the tools that previously relied on broader access.
Gateway API Inference Extension support reaches beta but remains off by default. The announcement identifies conformance with extension version 1.0.1 and describes the InferencePool resource alongside Gateway and HTTPRoute. The pilot environment variable ENABLE_GATEWAY_API_INFERENCE_EXTENSION enables the integration. Its graduation concerns Istio's support for that extension, not automatic conversion of existing gateways into inference-aware deployments.
These capabilities have different prerequisites because they solve different problems. Revocation depends on CA material. Diagnostic authorization depends on caller identity and namespace. Inference support depends on the extension's resources and explicit enablement. Combining them under a general claim of stronger defaults would lose information that an operator needs.
Pilot can now filter the resources it watches through PILOT_IGNORE_RESOURCES, with PILOT_INCLUDE_RESOURCES for explicit inclusion. The change notes describe using this to operate Istio as a Gateway API-only controller or with a narrower resource subset. That is a separate way to limit the responsibility assigned to a deployment. An installation interested only in gateway management need not express the same resource-watching intent as a full mesh control plane, although the selected filter must still include the resources its configured role requires.
Beta includes the behavior around failure
The release fixes ambient multicluster registry instability that could push incorrect configuration to proxies. It also improves remote trust-domain handling by watching remote mesh configuration. These are changes to the control plane's continuing interpretation of a multicluster environment. They matter after initial installation, when configuration changes and components recover from interruptions.
The beta announcement is most persuasive where it explains those continuing operations. Cross-network attribution, existing-pod rule reconciliation, and remote configuration updates all address states that persist beyond a successful demonstration request. They make the supported topology more understandable over its operating lifetime.
For my use, ambient multicluster's value depends on preserving the workload identity model across the network boundary without making diagnosis depend on undocumented forwarding details. Istio 1.29 supplies more of that explanation through telemetry and synchronization state. Its upgrade notes also make the remaining component-version requirements concrete, particularly for policy fields whose meaning changes under skew.