Learn Multigress - Multi-Cluster & Hybrid Deployments

#Introduction

Large teams rarely rely on a single cluster. Episode 17 covers multi-cluster and hybrid deployments with Multigress: cross-cluster ingress routing, patterns for exposing services spread across many clusters, and networking considerations for hybrid cloud environments.

Managing several clusters adds a new layer of complexity: DNS, network connectivity, and configuration consistency must be handled with discipline.

Consistency of configuration across clusters is an absolute prerequisite. Manifests that differ between regions only add reasons for incidents when failover runs.

#Cross-Cluster Ingress and Gateway Routing

#The Same Entry Point in Every Cluster

The most common pattern is opening an identical gateway in each region, with global DNS steering users to the nearest gateway. Multigress runs normally in every cluster; what gets standardized is its configuration.

kubectl config use-context cluster-primary
kubectl get gateway -A
kubectl config use-context cluster-secondary
kubectl get gateway -A

The two kubectl config use-context commands alternately check the gateways in cluster-primary and cluster-secondary. Identical configuration on both sides makes routing behavior independent of region.

#Failover Between Clusters

When one cluster dies, healthy DNS only points to the live cluster. Multigress stays ready to receive because its manifests are maintained with GitOps, and the load balancer health checks cut off the failed region's address.

To test failover readiness, shut down a listener in one region during an agreed window and make sure users are redirected smoothly to another region without manual intervention. Repeat until this process becomes a habit, not a surprise.

#Multi-Cluster Service Exposure Patterns

#ServiceImport with Multi-Cluster Service

The pattern for exposing services across clusters is standardized by the Multi-Cluster Service API. A service you want to share is exported as a ServiceExport and consumed as a ServiceImport.

apiVersion: multicluster.x-k8s.io/v1alpha1
kind: ServiceImport
metadata:
  name: api-svc
  namespace: platform
spec:
  type: ClusterSetIP
  ports:
    - port: 8080
      protocol: TCP

ServiceImport makes the api-svc service accessible from any cluster in one cluster set. The original endpoints stay in the cluster where the service runs.

#Gateway Routing to Cross-Cluster Services

Once the ServiceImport is available, an HTTPRoute can point to the same service name without knowing its physical location.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
  namespace: platform
spec:
  parentRefs:
    - name: multigress-gateway
  hostnames:
    - api.example.com
  rules:
    - backendRefs:
        - name: api-svc
          port: 8080

backendRefs points to api-svc, imported via ServiceImport, not a pod address. Routing becomes portable: the same code runs in any cluster unchanged.

#Hybrid Cloud Networking Considerations

#Connectivity Between Clouds

Cross-cloud routing only works if the networks are connected. Use a site-to-site VPN or transit gateway so pods in cloud A can reach pods in cloud B with private addresses.

kubectl get serviceimport -A --context cluster-primary
kubectl get serviceexport -A --context cluster-secondary

The output of kubectl get serviceimport -A shows the services accessible across clusters. If the list is empty, check the network connectivity between the clouds first before blaming the route configuration.

#Latency, Topology, and Backend Connections

Don't let requests cross continents without a reason. Keep routes pointed at backends in the same region, and use cross-region failover only when truly necessary.

If an application forces a cross-region call, make sure the path is short and stable: choose paired regions that are close to each other, and document which paths are allowed. An unmapped network is a source of latency that's hard to trace.

#Closing

Episode 17 extended the gateway's reach: identical configuration across clusters for failover, ServiceImport for multi-cluster service exposure, and planned connectivity and topology for hybrid cloud.

The key takeaways:

• Identical gateways in each region with global DNS as the decider.
• Cross-cluster configuration is kept consistent with GitOps.
• ServiceImport exposes services across clusters within one set.
• HTTPRoute can point to a service without knowing its physical location.
• Connectivity between clouds must be built before routing works.
• Keep traffic in-region and use failover wisely.

In the next episode 18 we'll discuss high availability & disaster recovery — gateway redundancy and failover, configuration backup and restore, and recovery drills for interruptions. The multi-cluster topology you built will be tested for resilience.