|
| 1 | +--- |
| 2 | +title: Introducing multicluster support for ambient mode (alpha) |
| 3 | +description: Istio 1.27 adds alpha ambient multicluster support, extending ambient's familiar lightweight, modular architecture to deliver secure connectivity, discovery and load balancing across clusters. |
| 4 | +date: 2025-08-04 |
| 5 | +attribution: Jackie Maertens (Microsoft), Keith Mattix (Microsoft), Mikhail Krinkin (Microsoft), Steven Jin (Microsoft) |
| 6 | +keywords: [ambient,multicluster] |
| 7 | +--- |
| 8 | + |
| 9 | +Multicluster has been one of the most requested features of ambient -— and as of Istio 1.27, it is available in alpha status! |
| 10 | +We sought to capture the benefits and avoid the complications of multicluster architectures while using the same modular design that ambient users love. |
| 11 | +This release brings the core functionality of a multicluster mesh and lays the groundwork for a richer feature set in upcoming releases. |
| 12 | + |
| 13 | +## The Power & Complexity of Multicluster |
| 14 | + |
| 15 | +Multicluster architectures increase outage resilience, shrink your blast radius, and scale across data centers. |
| 16 | +That said, integrating multiple clusters poses connectivity, security, and operational challenges. |
| 17 | + |
| 18 | +In a single Kubernetes cluster, every pod can directly connect to another pod via a unique pod IP or service VIP. |
| 19 | +These guarantees break down in multicluster architectures; |
| 20 | +IP address spaces of different clusters might overlap, |
| 21 | +and even without overlap, the underlying infrastructure would need configuration to route cross-cluster traffic. |
| 22 | + |
| 23 | +Cross-cluster connectivity also presents security challenges. |
| 24 | +Pod-to-pod traffic will leave cluster boundaries and pods will accept connections from outside their cluster. |
| 25 | +Without identity verification at the edge of the cluster and strong encryption, |
| 26 | +an outside attacker could exploit a vulnerable pod or intercept unencrypted traffic. |
| 27 | + |
| 28 | +A multicluster solution must securely connect clusters and do so |
| 29 | +through simple, declarative APIs that keep pace with dynamic environments where clusters are frequently added and removed. |
| 30 | + |
| 31 | +## Key Components |
| 32 | + |
| 33 | +Ambient multicluster extends ambient with new components and minimal APIs to |
| 34 | +securely connect clusters using ambient's lightweight, modular architecture. |
| 35 | +It builds on the {{< gloss "namespace sameness" >}}namespace sameness{{< /gloss >}} model |
| 36 | +so services keep their existing DNS names across clusters, allowing you to control cross-cluster communication without changing application code. |
| 37 | + |
| 38 | +### East-West Gateways |
| 39 | + |
| 40 | +Each cluster has an east-west gateway with a globally routable IP acting as an entry point for cross-cluster communication. |
| 41 | +A ztunnel connects to the remote cluster's east-west gateway, identifying the destination service by its namespaced name. |
| 42 | +The east-west gateway then load balances the connection to a local pod. |
| 43 | +Using the east-west gateway's routable IP removes the need for inter-cluster routing configuration, |
| 44 | +and addressing pods by namespaced name rather than IP eliminates issues with overlapping IP spaces. |
| 45 | +Together, these design choices enable cross-cluster connectivity without changing cluster networking or restarting workloads, |
| 46 | +even as clusters are added or removed. |
| 47 | + |
| 48 | +### Double HBONE |
| 49 | + |
| 50 | +Ambient multicluster uses nested [HBONE](/docs/ambient/architecture/hbone) connections to efficiently secure traffic traversing cluster boundaries. |
| 51 | +An outer HBONE connection encrypts traffic to the east-west gateway and allows the source ztunnel and east-west gateway to verify each other's identity. |
| 52 | +An inner HBONE connection encrypts traffic end-to-end, which allows the source ztunnel and destination ztunnel to verify each other's identity. |
| 53 | +At the same time, the HBONE layers allow ztunnel to effectively reuse cross-cluster connections, minimizing TLS handshakes. |
| 54 | + |
| 55 | +{{< image link="./mc-ambient-traffic-flow.png" caption="Istio ambient multicluster traffic flow" >}} |
| 56 | + |
| 57 | +### Service Discovery and Scope |
| 58 | + |
| 59 | +Marking a service global enables cross-cluster communication. |
| 60 | +Istiod configures east-west gateways to accept and route global service traffic to local pods and |
| 61 | +programs ztunnels to load balance global service traffic to remote clusters. |
| 62 | + |
| 63 | +Mesh administrators define the label-based criteria for global services via the `ServiceScope` API, |
| 64 | +and app developers label their services accordingly. |
| 65 | +The default `ServiceScope` is |
| 66 | + |
| 67 | +{{< text yaml >}} |
| 68 | +serviceScopeConfigs: |
| 69 | + - servicesSelector: |
| 70 | + matchExpressions: |
| 71 | + - key: istio.io/global |
| 72 | + operator: In |
| 73 | + values: ["true"] |
| 74 | + scope: GLOBAL |
| 75 | +{{< /text >}} |
| 76 | + |
| 77 | +meaning that any service with the `istio.io/global=true` label is global. |
| 78 | +Although the default value is straightforward, the `ServiceScope` API can express complex conditions using a mix of ANDs and ORs. |
| 79 | + |
| 80 | +By default, ztunnel load balances traffic uniformly across all endpoints --even remote ones--, |
| 81 | +but this is configurable through the service's `trafficDistribution` field to only cross cluster boundaries when there are no local endpoints. |
| 82 | +Thus, users have control over whether and when traffic crosses cluster boundaries with no changes to application code. |
| 83 | + |
| 84 | +## Limitations and Roadmap |
| 85 | + |
| 86 | +Although the current implementation of ambient multicluster has the foundational features for a multicluster solution, |
| 87 | +there is still a lot of work to be done. |
| 88 | +We are looking to improve the following areas |
| 89 | + |
| 90 | +* Service and waypoint configuration must be uniform across all clusters. |
| 91 | +* No cross-cluster L7 failover (L7 policy is applied at the destination cluster). |
| 92 | +* No support for direct pod addressing or headless services. |
| 93 | +* Support only for multi-primary deployment model. |
| 94 | +* Support only for one network per cluster deployment model. |
| 95 | + |
| 96 | +We are also looking to improve our reference documentation, guides, testing, and performance. |
| 97 | + |
| 98 | +If you would like to try out ambient multicluster, please follow [this guide](/docs/ambient/install/multicluster). |
| 99 | +Remember, this feature is in alpha status and not ready for production use. |
| 100 | +We welcome your bug reports, thoughts, comments, and use cases -- you can reach us on [GitHub](https://github.com/istio/istio) or [Slack](https://istio.slack.com/). |
0 commit comments