The recent release of Istio v1.27 (August 2025) brought with it an initial alpha implementation of multicluster support for ambient mode.
This article provides an overview and comparison of Istio's alpha multicluster feature with Gloo Mesh's multicluster peering feature, with the aim of providing clarity on how the two implementations are similar and where they differ. Here's an overview of the differences, read on for more detail on each area:
Istio's new ambient multicluster feature
In Istio version 1.27, the feature is considered alpha and, as the blog announcing the feature states, lays the groundwork for a richer feature set in upcoming releases.
The general idea behind Istio multicluster is to run a single service mesh spanning more than a single cluster. Istio has had multicluster support in sidecar mode for some time. The announced feature is an effort to provide a multi-cluster solution in ambient mode.
The implementation brings with it the following concepts:
- Namespace sameness: helps determine whether workloads residing on different clusters belong to the same service, or whether they are distinct.
- East-west gateways: help establish a cross-cluster communication channel for control plane and/or data plane traffic.
- Nested HBONE connections: accommodates the need for encrypted and authenticated communication to the east-west gateway while still supporting the end-to-end encrypted and authenticated communication between the services.
The documentation provides instructions for trying out the feature with Istio version 1.27.
One important aspect of how multicluster works in Istio, common to both sidecar and ambient mode, has to do with service discovery: an istiod running in one cluster communicates with the Kubernetes API server on a remote cluster to discover remote workloads and services. Secrets are deposited in one cluster in order to permit the communication to the remote Kubernetes API server. Pod creation, deletion, and update event notifications are what informs the Istio control plane's service registry.
The illustration below shows how 12 secrets (4x3) need to be maintained to support service discovery in a 4-cluster mesh.
Figure: Istio Control Planes use secrets to communicate with Kubernetes API Server on remote clusters for service discovery.
This can be problematic from a security point of view, in that access credentials to clusters reside across multiple clusters. Second, those credentials are in the form of a permanent access token that does not have expiration. Another concern is the constant pressure on the Kubernetes API server to send service discovery updates, which become a bottleneck at scale.
Gloo Mesh's multicluster peering feature
Released in January of 2025 (GA) after the release of Istio 1.24, Solo.io's Gloo Mesh product introduced a new ambient multi-cluster mode (known as "multicluster peering") that is simpler, safer, and more scalable than previous multi-cluster service mesh architectures.
One way to view Gloo's multicluster implementation is as an extension of the principles of simplicity and efficiency that ambient mesh brought to Istio.
Multicluster peering is mature and production-ready. It supports clusters that reside on separate networks just as well as a deployment model where the clusters are part of a flat network. Istio is installed on every single cluster, and linked clusters exchange discovery information securely.
Security
Solo's solution does not require accessing the Kubernetes API server on remote clusters in order to discover remote services. The process is called multicluster peering, whereby Istio control planes exchange discovery information with each other via east-west gateways.
From a security standpoint, the communication between Istio control planes is secured through mutual TLS and the shared root of trust that is configured across the clusters. There is no need to deposit cluster credentials in one cluster in order for the control plane to access other clusters.
Resilience
Multicluster peering is resilient in that it was designed to tolerate downtime between clusters. This is an improvement over open-source multicluster Istio, where control planes depend on all other control planes being available in order to start. Any issues preventing that communication would result in startup delays of the control planes.
Scale
The solution scales to thousands of clusters, millions of pods. For details, see John Howard's posts Introducing Gloo Mesh Ambient multicluster and the follow-up post on The 100 Million Pod Mesh. This accomplishment is a direct testament to the design and implementation of multicluster peering to allow the solution to scale. The service mesh is no longer the bottleneck to being able to scale.
Cluster onboarding
Onboarding clusters is simple: other than provisioning the cluster and installing Istio, onboarding involves:
- Exposing the cluster by deploying an east-west gateway, and
- Linking the cluster to other clusters.
The second step is becoming redundant with the introduction of automatic cluster linking (still in beta at the time of writing).
Solo.io's distribution of Istio provides a version of the CLI that supports these activities through the istioctl multicluster subcommands: expose, link, and check.
Global services
The feature supports the same concept of namespace sameness, with similar conventions for marking services as "Global" (i.e. spanning multiple clusters), in this case, by labeling the service in each cluster with solo.io/service-scope=global.
Global services are assigned a distinct hostname that follows the naming convention <name>.<namespace>.mesh.internal, which avoids conflict with the Kubernetes convention for a single cluster, and provides more control.
Management plane
Beyond basic multi-cluster support, Gloo Mesh also comes with a management plane that provides synchronization across clusters, as well as multi-cluster telemetry aggregation and observability dashboards.
Here is a video walkthrough by Ram Vennam, Solutions Architect Director at Solo.io, demonstrating the configuration of a two-cluster mesh using Gloo Mesh's multicluster peering capability. The complete instructions for installing Istio ambient multicluster with Gloo Mesh can be found in the Gloo Mesh documentation.
Comparisons
Similarities
Both solutions have design similarities. Both use the concept of "namespace sameness" for global services, and both use similar conventions of labeling a service to designate it as global, spanning multiple clusters. Both employ east-west gateways, and both use nested HBONE connections that allow the termination of the outer HBONE tunnel at the east-west gateway.
East-West gateways
Gloo east-west gateway is an efficient ztunnel component, while the open-source solution employs an Envoy proxy. ztunnel is ambient mesh's Rust-based Layer 4 proxy. One advantage of ztunnel based east-west gateways is a reduced attack surface, as no layer 7 capabilities are exposed.
Service discovery
For discovery, Gloo's solution uses an efficient and scalable peering mechanism, whereas the Istio open-source solution relies on giving istiod access to a remote Kubernetes cluster's API server via a secret. The latter approach is not only less secure, but also has implications on the ability to scale the solution. As the number of clusters grows, maintaining and updating the secrets provisioned in each cluster (to access the remote API servers) becomes an operational problem, which grows with the square of the number of clusters. For example, given a multicluster mesh consisting of a dozen clusters, each cluster needs to maintain secrets for the other eleven, 132 secrets in total.
Extra features
Gloo provides conveniences in the form of istioctl commands to expose east-west gateways, and to link clusters to one another. Gloo also provides the ability to collect and aggregate telemetry from multiple clusters to the Gloo management plane. This supports observability in a multi-cluster context.
Sidecar interoperability
Another important distinction is support for interoperability between sidecar and ambient modes. In a multicluster environment with mixed modes, the Istio open-source product does not provide this interoperability. The implication is the possibility of mesh policies being bypassed in situations for example, where a sidecar-based client is calling an ambient service that is fronted by a waypoint. A migration of a system of microservices from sidecar mode to ambient requires a piecemeal approach, where teams have the autonomy to migrate their services independently of other teams, on their own schedule. Without interoperability, migrations become a very risky "all or none" proposition.
Cross-cluster routing from ingress
Another important gap at the data plane level is that both solutions can route requests between microservices across clusters, but the ability to route cross-cluster from ingress is not supported in the open-source solution. Top-level services in a microservices call graph should also be configurable as global services, for purposes of redundancy and availability. Not having the flexibility to route a request from the gateway to an instance residing on a remote cluster when no local instances are available is problematic, to say the least.
Other multicluster routing related issues exist in Istio open source. For example, waypoints cannot fail over to a workload in another cluster. Waypoints in open-source Istio also do not have access to outlier detection information to base decisions regarding which cluster to target.
Summary
While some aspects of both solutions are similar, each solution has a different design, and a different approach for dealing with service discovery.
The open-source solution will mature over the coming releases of Istio. Multicluster peering also continues to evolve. After actively working with our large enterprise customers running ambient in production and listening to their feedback, Solo.io is adding various capabilities such as support multi-tenancy in a multicluster context. Separately, through the use of service discovery plugins, Gloo Mesh can accommodate mesh expansion to workloads running in different environments, such Amazon ECS and EC2, with a plan of supporting additional integrations in the future.
To learn more about ambient mesh or Gloo Mesh, check out the free, hands-on labs listed below:
%20a%20Bad%20Idea.png)
%20For%20More%20Dependable%20Humans.png)
