Learn Istio - Multi-cluster & Mesh Federation

#Introduction

Large-scale applications rarely live in a single cluster: failure zones, regional latency, and quota limits force you to spread across several clusters. Episode 16 covers how to build one mesh across clusters with Istio — the available topologies, the role of the east-west gateway, and how identity and trust are unified.

#Multi-cluster Topologies

#Primary-Remote (Shared Control Plane)

The most common pattern: one primary cluster runs istiod; remote clusters use that istiod without running their own control plane. Remote clusters install the remote profile:

istioctl install --context=cluster-remote --set profile=remote --set values.global.remotePilotAddress=<IP_primary>

--set profile=remote makes the remote cluster connect to istiod in the primary cluster. Advantage: a single control point, uniform configuration. Drawback: istiod becomes a single point of failure — make sure its availability is solid (episode 14).

#Replicated Control Plane

Each cluster runs its own istiod, and each istiod manages configuration for the entire mesh:

• Every cluster has an istiod serving its local workloads.
• All istiods are connected and share service state from every cluster.
• If one istiod dies, its cluster can still be recovered by its neighbors.

#External Control Plane

The control plane runs in a separate cluster, not where the workloads run. This suits cases where the platform team and workloads must be isolated. All three use the same configuration pattern for cross-cluster discovery.

#The East-west Gateway and Service Routing

#The Role of the East-west Gateway

For inter-cluster traffic, Istio uses a dedicated gateway called the east-west gateway (istio-eastwestgateway). It exposes the mTLS port and makes remote services reachable:

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: eastwest-gateway
  namespace: istio-system
spec:
  selector:
    istio: eastwestgateway
  servers:
  - port:
      number: 15443
      name: tls
      protocol: TLS
    tls:
      mode: AUTO_PASSTHROUGH
    hosts:
    - "*.local"

tls.mode: AUTO_PASSTHROUGH forwards mTLS traffic to the destination service based on SNI without inspecting its contents. This enables global load balancing across clusters with mTLS kept intact.

#Routing and Service Export

By default, services are not visible across clusters. Configure the export with a ServiceEntry and export labels:

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: productpage-remote
spec:
  hosts:
  - productpage.remote-ns.svc.cluster.local
  location: MESH_INTERNAL
  resolution: DNS
  addresses:
  - 240.0.0.1
  endpoints:
  - address: <IP_eastwest_remote>
    ports:
      tls: 15443

This kind of ServiceEntry is installed in all clusters so each one knows how to reach services in a remote cluster through the east-west gateway.

#Multi-cluster DNS

Each cluster has its own CoreDNS, so the svc.cluster.local names are not automatically known across clusters. The solutions:

• Istio DNS proxy: answers resolution for names exported from other clusters.
• Global DNS: setting up a global kube-dns that federates all clusters.

To use the Istio DNS proxy, enable it on istiod:

spec:
  meshConfig:
    defaultConfig:
      proxyMetadata:
        ISTIO_META_DNS_CAPTURE: "true"
        ISTIO_META_DNS_AUTO_ALLOCATE: "true"

ISTIO_META_DNS_CAPTURE: "true" makes Envoy resolve remote service names locally, reducing dependency on cluster DNS. The 240.0.0.0/8 address range is used for automatic allocation of remote endpoints.

#Trust and Security Across Clusters

#A Consistent Trust Domain

Identity across all clusters comes from the trust domain and a common root CA:

• All clusters must use the same trustDomain and meshID.
• Workload certificates must be signed by a consistent root CA.
• Verification from one cluster against another uses the cluster.local/ns/.../sa/... identity.

Set it in MeshConfig:

spec:
  meshConfig:
    meshID: mesh-produksi
    trustDomain: cluster.local

meshID: mesh-produksi identifies the mesh in telemetry and service export. If two meshes want to call each other without fully merging, use mesh-to-mesh federation with mutually recognized trust domains — a rarer and more complex case.

#Summary

Episode 16 united many clusters into one mesh: primary-remote, replicated, and external control plane topologies; the east-west gateway with AUTO_PASSTHROUGH mode; cross-cluster service export and DNS; and the consistent trust domain needed for security.

Key takeaways:

• Primary-remote centralizes istiod; replicated distributes it.
• The east-west gateway handles inter-cluster traffic with mTLS intact.
• Services must be explicitly exported to be visible across clusters.
• The Istio DNS proxy helps resolve remote service names.
• The trust domain and meshID must be consistent across all clusters.
• Full federation only when trust between meshes is explicitly built.
• Multi-cluster adds complexity; make sure the regional need is real.

In the next episode, episode 17, we will discuss a new, maturing mode: ambient mesh and sidecar-less patterns — the concepts of ztunnel and waypoint proxies, the security and observability differences from the sidecar model, and its stability status in Istio releases.