Belajar OpenClaw - Multi-cluster & Hybrid Environments

#Pendahuluan

Di episode 16 kalian memperluas OpenClaw dengan modul kustom, data source eksternal, dan hook evaluasi. Sekarang bayangkan organisasi yang tidak lagi punya satu cluster: tim Eropa memakai EKS di AWS, tim Asia memakai GKE di Google Cloud, dan satu data center on-premise untuk data sensitif. Satu policy harus mengatur semuanya, tanpa duplikasi yang saling bertabrakan.

Episode 17 membahas panggung terbesar: manajemen policy lintas cluster, gateway routing untuk traffic multi-cluster, dan pertimbangan networking hybrid cloud. Setelah episode ini, OpenClaw kalian menjadi otak kebijakan untuk seluruh lanskap, bukan hanya satu cluster.

#Mengelola Policy Lintas Cluster

Model paling jelas untuk multi-cluster adalah hub-and-spoke: satu control plane pusat (hub) memegang kebijakan global, sementara setiap cluster lokal (spoke) punya policy khususnya sendiri. Kalian mendaftarkan setiap cluster ke hub:

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

Policy kemudian dibedakan menjadi dua level. Policy global berlaku di semua cluster dan dikelola hanya dari hub — aturan deny untuk data sensitif, misalnya, harus berlaku di mana pun. Policy lokal berlaku hanya di cluster tempat dia didefinisikan, sehingga tim per region tetap punya ruang gerak tanpa mengubah kebijakan pusat:

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

Field conflictResolution: globalWins adalah kunci: jika policy global dan lokal bertentangan, global menang. Tanpa aturan ini, dua tim bisa menulis policy yang saling membatalkan dan seluruh latihan multi-cluster menjadi kacau. Sinkronisasi perubahan ditegakkan lewat GitOps — source of truth tetap di repo, dan hub menariknya berkala.

#Gateway Routing untuk Traffic Multi-cluster

Dengan policy lintas cluster beres, giliran trafiknya. Untuk memakai traffic yang tersebar di beberapa cluster, kalian butuh gateway multi-cluster: gateway yang tahu service ada di mana-mana dan bisa mengarahkan request ke cluster mana pun. Ini menyediakan global load balancing — user di Asia dilayani cluster Asia — sekaligus failover ketika satu cluster tumbang.

Konfigurasi gateway multi-cluster menyatukan service discovery lintas cluster dan set kebijakan failover:

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

Dengan localityAware: true, gateway mengutamakan cluster yang paling dekat dengan pengguna; weight mengatur proporsi beban; dan whenUnhealthy: routeToHealthy memastikan request dialihkan ke cluster sehat begitu cluster asal gagal health check. Kombinasi ini membuat kegagalan satu cluster tidak terasa oleh pengguna:

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

#Pertimbangan Networking Hybrid Cloud

Menghubungkan cluster lintas cloud dan on-premise tidak semudah di satu VPC. Ada empat hal yang harus diputuskan secara sadar:

Konektivitas privat. Traffic antar cluster sebaiknya tidak menyeberang internet publik. AWS menyediakan transit gateway, Google punya VPC peering antar region, dan on-premise terhubung lewat VPN IPsec atau Direct Connect. OpenClaw hanya menegakkan policy; konektivitas dasar adalah fondasi yang harus kalian bangun lebih dulu.

Latensi. Setiap hop antar region menambah waktu. Untuk keputusan policy yang memanggil data source di cluster lain, letakkan cache lokal atau replika data di tiap region. Evaluasi policy yang menunggu round-trip lintas benua akan membuat latensi membengkak berkali lipat.

Trust domain dan identitas. Setiap cluster punya trust domain sendiri, misalnya spiffe://aws-prod dan spiffe://onprem. Identity yang sama di dua domain tetap dianggap identitas berbeda. Saat service di AWS bicara ke service di on-premise, policy harus menyebutkan trust domain secara eksplisit:

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. Policy yang menegakkan tempat data harus disimpan adalah fitur, bukan hambatan: aturan deny egress untuk workload yang memegang data sensitif berarti data itu tidak akan pernah dikirim lintas batas tanpa persetujuan — persis konteks yang disinggung di episode 6 dan 12 tentang batas dan trust domain.

#Penutup

Episode 17 menutup Fase 5 dan membawa OpenClaw ke skala organisasi: policy global dan lokal diatur lewat model hub-and-spoke dengan konflik yang jelas pemenangnya, gateway multi-cluster mengarahkan traffic dengan locality-aware routing dan failover otomatis, dan pertimbangan hybrid cloud — konektivitas privat, latensi, trust domain, dan data residency — ditangani secara eksplisit di policy. Seluruh lanskap kini punya satu kebijakan yang koheren.

Inti yang harus dibawa pulang:

• Pisahkan policy global (dari hub) dan policy lokal (per cluster), dan tetapkan conflictResolution agar tidak ada konflik yang membatalkan.
• Daftarkan setiap cluster dengan openclaw cluster join dan jaga source of truth lewat GitOps.
• Gateway multi-cluster memberi locality-aware routing dan failover otomatis antar cluster.
• Bangun konektivitas privat antar cloud dan on-premise sebelum menaruh policy di atasnya.
• Sebutkan trust domain eksplisit untuk komunikasi lintas domain, dan gunakan policy untuk menegakkan data residency.

Lanskap multi-cluster sudah terkendali, tapi bencana tetap bisa datang — kegagalan besar, koneksi putus, cluster hilang. Di episode 18 kita menyiapkan perangkat daruratnya: Disaster Recovery & Failover — backup dan restore konfigurasi, strategi failover control plane, dan penanganan network partitions. Sampai jumpa di sana!