Learn OpenClaw - Multi-cluster & Hybrid Environments

#Introduction

In episode 16 you extended OpenClaw with custom modules, external data sources, and evaluation hooks. Now imagine an organization that no longer has a single cluster: the European team runs EKS on AWS, the Asian team runs GKE on Google Cloud, and there's one on-premise data center for sensitive data. One policy must govern all of them, without colliding duplicates.

Episode 17 covers the biggest stage: cross-cluster policy management, gateway routing for multi-cluster traffic, and hybrid cloud networking considerations. After this episode, your OpenClaw becomes the policy brain for the entire landscape, not just one cluster.

#Managing Policies Across Clusters

The clearest model for multi-cluster is hub-and-spoke: one central control plane (hub) holds global policies, while each local cluster (spoke) has its own specific policies. You register each cluster with the hub:

openclaw cluster join prod-eu --hub https://hub.example.com
openclaw cluster list
openclaw cluster status prod-eu

Policies are then differentiated into two levels. Global policies apply in every cluster and are managed only from the hub — a deny rule for sensitive data, for example, must apply everywhere. Local policies apply only in the cluster where they're defined, so each region's team keeps room to maneuver without changing central policy:

apiVersion: openclaw.io/v1
kind: GlobalPolicy
metadata:
  name: deny-pci-egress
  namespace: openclaw-system
spec:
  clusters:
    - prod-eu
    - prod-asia
    - onprem-core
  rules:
    - action: deny
      destination:
        port: 22
      source:
        scope: mesh
  conflictResolution: globalWins

The conflictResolution: globalWins field is the key: if global and local policies conflict, the global one wins. Without this rule, two teams could write policies that cancel each other out and the whole multi-cluster exercise turns to chaos. Change synchronization is enforced through GitOps — the source of truth stays in the repo, and the hub pulls from it periodically.

#Gateway Routing for Multi-cluster Traffic

With cross-cluster policies settled, it's traffic's turn. To use traffic spread across several clusters, you need a multi-cluster gateway: a gateway that knows where services live and can route requests to any cluster. This provides global load balancing — a user in Asia is served by the Asia cluster — plus failover when one cluster goes down.

The multi-cluster gateway configuration combines cross-cluster service discovery and a failover policy set:

apiVersion: openclaw.io/v1
kind: GatewayConfig
metadata:
  name: global-gateway
  namespace: openclaw-system
spec:
  listen:
    - port: 443
      tls:
        minVersion: "1.3"
  clusters:
    - name: prod-eu
      weight: 40
    - name: prod-asia
      weight: 40
    - name: onprem-core
      weight: 20
  failover:
    healthCheckIntervalSeconds: 10
    whenUnhealthy: routeToHealthy
  localityAware: true

With localityAware: true, the gateway prefers the cluster closest to the user; weight controls the load proportion; and whenUnhealthy: routeToHealthy ensures requests are redirected to a healthy cluster as soon as the origin cluster fails its health check. This combination makes one cluster's failure invisible to users:

openclaw gateway health global-gateway
openclaw gateway route global-gateway --trace t-77aa-9e12

#Hybrid Cloud Networking Considerations

Connecting clusters across clouds and on-premise isn't as easy as within one VPC. Four things must be decided deliberately:

Private connectivity. Traffic between clusters shouldn't cross the public internet. AWS provides transit gateways, Google has cross-region VPC peering, and on-premise connects via IPsec VPN or Direct Connect. OpenClaw only enforces policy; the underlying connectivity is a foundation you must build first.

Latency. Every inter-region hop adds time. For policy decisions that call data sources in another cluster, put a local cache or data replica in each region. A policy evaluation waiting on a cross-continent round-trip will make latency balloon many times over.

Trust domain and identity. Each cluster has its own trust domain, e.g. spiffe://aws-prod and spiffe://onprem. The same identity in two domains is still considered two different identities. When a service in AWS talks to a service on-premise, the policy must mention the trust domain explicitly:

apiVersion: openclaw.io/v1
kind: Policy
metadata:
  name: onprem-db-access
  namespace: openclaw-system
spec:
  scope: mesh
  source:
    trustDomain: spiffe://aws-prod
    workloadLabels:
      app: analytics
  destination:
    trustDomain: spiffe://onprem
    workloadLabels:
      app: postgres
  allow:
    - port: 5432
  defaultAction: deny

Data residency. A policy that enforces where data must be stored is a feature, not a hindrance: an egress deny rule for workloads holding sensitive data means that data will never be sent across borders without approval — exactly the context touched on in episodes 6 and 12 about boundaries and trust domains.

#Wrap-Up

Episode 17 closes Phase 5 and takes OpenClaw to organizational scale: global and local policies managed through the hub-and-spoke model with a clear conflict winner, multi-cluster gateways directing traffic with locality-aware routing and automatic failover, and hybrid cloud considerations — private connectivity, latency, trust domains, and data residency — handled explicitly in policy. The whole landscape now has one coherent policy.

Key takeaways:

• Separate global policies (from the hub) and local policies (per cluster), and set conflictResolution so no conflict cancels another out.
• Register each cluster with openclaw cluster join and keep the source of truth via GitOps.
• Multi-cluster gateways provide locality-aware routing and automatic failover between clusters.
• Build private connectivity between clouds and on-premise before putting policies on top of it.
• State trust domains explicitly for cross-domain communication, and use policies to enforce data residency.

The multi-cluster landscape is under control, but disasters can still arrive — major failures, cut connections, a lost cluster. In episode 18 we prepare the emergency kit: Disaster Recovery & Failover — configuration backup and restore, control plane failover strategies, and handling network partitions. See you there!