Dora NodaIstio's ambient mode has been able to mesh a single cluster without sidecars since GA in late 2024. As of Istio 1.29, released February 18, 2026, it can mesh multiple clusters across separate networks — and the feature got its moment on stage at KubeCon + CloudNativeCon Europe 2026 in Amsterdam, where the CNCF announced Ambient Multicluster reaching Beta alongside Gateway API Inference Extension and an experimental Agentgateway.
The verdict, before the mechanics: for a Cluster API fleet spread across Hetzner's genuinely separate locations, Beta is worth piloting on a non-critical pair of clusters now. It is not yet worth trusting as the default cross-location networking layer — the cross-cluster path costs real, quantified latency on top of ambient's usual overhead, and the feature ships with five specific gaps a status page won't mention. Here's the actual math and the actual gap list.
What This Replaces
A Cluster API fleet on Hetzner isn't hypothetically multi-location — Hetzner runs six physically distinct sites (Falkenstein and Nuremberg in Germany, Helsinki in Finland, Ashburn and Hillsboro in the US, and Singapore), each on its own network. Spreading a fleet across even two of those locations for fault-domain isolation means every cross-cluster call already has to cross a network boundary. That's the specific case Ambient Multicluster targets, and — non-obviously — it's the harder of the two multicluster cases Istio supports, not the easier one. More on that below.
Before this Beta, a Cluster API operator wanting mTLS and L7 policy across Hetzner-location clusters had two options, both worse than what's now available:
- Sidecar-based Istio multicluster. Works today, but pays the sidecar tax on every pod in every cluster — a cost this list has already quantified at roughly 70% higher memory than ambient mode, now doubled or tripled across however many clusters the fleet spans.
- No mesh at all. Manual Kubernetes Services plus hand-rolled routing between clusters, no uniform mTLS, no L7 policy that spans a cluster boundary — the fault-domain spreading happens, but the security and traffic-management story stops at each cluster's edge.
Ambient Multicluster Beta is a third option: mTLS and L7 policy that spans clusters, without a sidecar proxy anywhere in the path.
Put a number on the sidecar option to see why it stops being attractive at fleet scale. Ambient's own GA-era benchmarks put a 70-pod cluster at roughly 14 vCPU of sidecar overhead versus about 5 vCPU for the ztunnel DaemonSets doing the same job — a single-cluster comparison already covered elsewhere. Spread that same workload across three Hetzner-location clusters instead of one, and sidecar-based multicluster doesn't just keep that 14-vs-5 ratio — it pays it three times over, once per cluster, on top of whatever the east-west gateways and cross-cluster control-plane machinery cost either architecture.
Ambient's per-cluster overhead stays flat at roughly 5 vCPU plus one east-west gateway; sidecar's per-cluster overhead is 14 vCPU, full stop, regardless of how many clusters get added. The gap that ambient mode already closed inside one cluster reopens, unclosed, at every additional cluster a sidecar-based fleet spans — exactly the multiplier a Hetzner-spanning fleet needs closed, since fault-domain spreading only pays off if adding a third or fourth location doesn't also triple the mesh's resource bill.
The Mechanism: ztunnel, Waypoint, and Double HBONE
Ambient mode already splits the data plane in two. ztunnel is a lightweight, node-level proxy running as a DaemonSet — one instance per node, shared by every pod on it — handling mTLS, telemetry, and L4 routing. Waypoint proxies are optional, deployed only where a workload actually needs L7 traffic management (retries, header-based routing, fine-grained authorization). Everything moves over HBONE, Istio's HTTP-based overlay network protocol.
Crossing a cluster boundary adds one layer. Traffic destined for a remote cluster hits an east-west gateway — a dedicated Istio gateway deployed at each cluster's edge — which opens what Istio's own docs call a "double HBONE" tunnel: an outer mTLS connection authenticates the source ztunnel to the east-west gateway, and a second, inner mTLS connection carries the request end-to-end to the destination ztunnel. Neither side ever needs to know the other cluster's pod IPs directly. Cross-cluster telemetry — letting waypoint and ztunnel on each side see peer metadata for the other cluster's endpoints — is gated behind a feature flag, AMBIENT_ENABLE_BAGGAGE, that has to be explicitly turned on; it isn't default behavior yet.
The Real Cost: What Crossing a Cluster Boundary Adds
This is the number that actually answers "how far is Beta from default," and it's not the same figure ambient's single-cluster GA already established. Istio's own ambient multicluster performance testing measured the marginal cost of the double-HBONE hop directly, cluster-to-cluster:
| Same-cluster | Cross-cluster | Overhead | |
|---|---|---|---|
| New connection | baseline | +2.2 ms | 346% |
| Existing (reused) connection | baseline | +0.13 ms | 72% |
The gap between those two rows is the whole story: a fresh cross-cluster connection pays a real, three-and-a-half-times latency tax from the double mTLS handshake, but ztunnel reuses established HBONE tunnels aggressively, so a workload making repeated calls to the same remote service settles down to a fraction of a millisecond of added overhead per request — genuinely negligible next to the inter-datacenter transit time between, say, Nuremberg and Ashburn. The practical implication: connection churn matters more than raw call volume. A service that opens a fresh connection per request to a remote cluster feels this; one that holds a long-lived connection pool mostly doesn't.
Control-plane cost scales the same way — per cluster added, not per pod. Testing at 300 services and 4,000 endpoints per cluster, across 10 clusters, put the cost of tracking each additional remote cluster at roughly 1% of a CPU core and 180 MB of memory on istiod. And the east-west gateway itself is a standard Envoy-based Istio gateway, sized like any other: Istio's general guidance is 500m CPU / 256Mi memory as a request baseline, scaling to 2 vCPU / 1Gi under load, with autoscaling typically configured for 2–5 replicas — a fixed, known cost per cluster, not something that grows with fleet-wide traffic in a way that's hard to plan for.
None of these numbers are large in absolute terms. What they establish is that the cost of Ambient Multicluster is concentrated in connection setup, not steady-state throughput — which is exactly the profile that makes it fine to pilot on latency-tolerant, low-connection-churn traffic first, and risky to put in front of anything spinning up short-lived connections at high rate across a Hetzner-location boundary.
To make that concrete: say a checkout service running in a Falkenstein cluster calls an inventory service in a Helsinki cluster, roughly 900 km and single-digit milliseconds of raw network transit apart. The first request opens a fresh HBONE tunnel — outer mTLS to Helsinki's east-west gateway, inner mTLS to the inventory service's ztunnel — and eats the full 2.2 ms handshake tax on top of that transit time.
If checkout holds that connection open and reuses it for the next thousand requests, each one only pays the 0.13 ms reused-connection overhead — a rounding error next to the Falkenstein-to-Helsinki round trip itself. The same call pattern written to open a new connection per request, a common default in code that was never written with cross-cluster calls in mind, pays the 2.2 ms tax every single time. Nothing about Ambient Multicluster fixes that; it just makes the cost of getting it wrong visible in a benchmark instead of invisible in production latency.
The Catch List: How Far Beta Actually Is From "Just Turn It On"
Beta status means specific, documented gaps — not a vague "not GA yet" hedge:
- Same-network multicluster is still Alpha — less mature than the cross-network case. This is the counterintuitive part. Ambient multicluster within a single flat network (clusters that can already route to each other directly, no east-west gateway needed) hasn't reached Beta; the cross-network case — the harder one, and the one a Hetzner-location-spanning fleet actually needs — got there first. Don't assume "multicluster" is a single maturity level.
- East-west gateway load balancing has a known skew. Istio's own release notes flag that the gateway "may give preference to a specific endpoint during a certain time span" — traffic to a remote cluster isn't guaranteed to distribute evenly across that cluster's replicas in the short term.
- An east-west gateway is one more thing to run, per cluster. Every location in the fleet now needs its own gateway deployed, sized, and kept patched — a new operational surface, not a config flag.
- No GA timeline has been announced. Istio's KubeCon EU announcement introduced the Beta with no committed date for graduation.
- It's feature-flagged, not default-on. Cross-cluster telemetry specifically requires
AMBIENT_ENABLE_BAGGAGE; nothing about this rolls out automatically to an existing ambient mesh.
The Verdict for a Cluster API Fleet
Pilot Ambient Multicluster on a non-critical pair of Hetzner locations — pick two clusters, route a service with long-lived, low-churn connections between them, and watch the east-west gateway's load distribution and the control-plane overhead directly rather than trusting the published numbers to hold at a different scale. Keep whatever cross-cluster routing already handles the fleet's critical paths — manual Services, or a Cilium ClusterMesh-style L3/L4 layer if the need is pure connectivity without L7 policy — as the fallback until Beta graduates and the same-network case catches up to it.
That's a materially better position than sidecar-based multicluster or no mesh at all, and it's exactly the kind of build-vs-adopt call a self-hosted PaaS's own control-plane layer has to make constantly. Cluster API already decides how bex provisions and manages nodes across a fleet — adopting a still-Beta networking primitive underneath it is a decision to make deliberately, cluster pair by cluster pair, not one to inherit by default just because it shipped at KubeCon.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with Cluster API managing the fleet underneath. Star the repo on GitHub or deploy your first app today.
Sources
- Istio — Ambient multi-network multicluster support is now Beta
- Istio — Ambient Multicluster Performance
- CNCF — Istio Brings Future Ready Service Mesh to the AI Era with New Ambient Multicluster, Gateway API Inference Extension and More
- Istio — Introducing multicluster support for ambient mode (alpha)
- Istio — Install ambient multi-primary on different networks
- Solo.io — Cut Service Mesh Costs by 92% with Ambient Mesh
- cluster-api-provider-hetzner (CAPH)
- Hetzner Cloud Developer Hub
