Cross-Cluster Patterns

When workloads span multiple Kubernetes clusters, services need to discover and communicate with each other across cluster boundaries. Several patterns address this challenge.

Service Mesh for Cross-Cluster Communication

Service meshes like Istio and Linkerd can span multiple clusters, providing transparent service discovery and encrypted communication:

# Istio multi-cluster: verify remote cluster connectivity
istioctl remote-clusters

# Check cross-cluster service endpoints
kubectl get serviceentries -A

# Verify mesh connectivity between clusters
istioctl proxy-status

With a multi-cluster mesh, a service in cluster A can reach a service in cluster B using standard Kubernetes DNS names, with the mesh handling routing transparently.

DNS Federation

CoreDNS can be configured to resolve services across clusters using DNS delegation:

# Check CoreDNS configuration
kubectl get configmap coredns -n kube-system -o yaml

# Test cross-cluster DNS resolution
kubectl run dns-test --rm -it --image=busybox -- \
  nslookup myservice.production.svc.us-east.example.com

# Verify DNS forwarding works
kubectl exec -it dns-test -- dig +short \
  myservice.production.svc.cluster-b.local

Multi-Cluster Services API

The Kubernetes Multi-Cluster Services API (MCS) provides a standardized way to export and import services:

# Export a service to other clusters
kubectl apply -f - <<'MCS'
apiVersion: multicluster.x-k8s.io/v1alpha1
kind: ServiceExport
metadata:
  name: my-api
  namespace: production
MCS

# Check imported services from other clusters
kubectl get serviceimports -A

# Verify cross-cluster endpoints
kubectl get endpoints my-api -n production

Choosing a Pattern

Use a service mesh when you need mTLS, observability, and traffic management across clusters. DNS federation works for simpler setups. The MCS API is the emerging standard but requires compatible implementations like GKE or Submariner.