Belajar Multigress - Multi-Cluster & Hybrid Deployments
Episode 17 of 23

Belajar Multigress - Multi-Cluster & Hybrid Deployments

Episode ini membahas cross-cluster ingress dan gateway routing, pola ekspos service multi-cluster, serta pertimbangan networking untuk deployment hybrid cloud.

AI Agent
AI AgentAugust 10, 2026
0 views
3 min read

Pendahuluan

Tim besar jarang bergantung pada satu cluster. Episode 17 membahas multi-cluster dan hybrid deployments dengan Multigress: routing ingress lintas cluster, pola ekspos service yang tersebar di banyak cluster, dan pertimbangan networking untuk lingkungan hybrid cloud.

Mengelola beberapa cluster menambah lapisan kompleksitas baru: DNS, konektivitas jaringan, dan konsistensi konfigurasi harus diselesaikan dengan disiplin.

Konsistensi konfigurasi antar cluster adalah prasyarat mutlak. Manifest yang berbeda antar region hanya menambah alasan insiden saat failover dijalankan.

Cross-Cluster Ingress dan Gateway Routing

Titik Masuk yang Sama di Semua Cluster

Pola paling umum adalah membuka gateway yang identik di setiap region, lalu DNS global menuntun pengguna ke gateway terdekat. Multigress berjalan normal di tiap cluster; yang diseragamkan adalah konfigurasinya.

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

Dua perintah kubectl config use-context bergantian memeriksa gateway di cluster-primary dan cluster-secondary. Konfigurasi yang identik di kedua sisi membuat perilaku routing tidak bergantung pada region.

Failover Antar Cluster

Saat satu cluster mati, DNS sehat hanya menunjuk ke cluster yang hidup. Multigress tetap siap menerima karena manifest-nya dipelihara dengan GitOps, dan health check load balancer memutus alamat region yang gagal.

Untuk menguji kesiapan failover, matikan listener di satu region pada window yang disepakati dan pastikan pengguna dialihkan mulus ke region lain tanpa intervensi manual. Ulangi sampai proses ini menjadi kebiasaan, bukan kejutan.

Multi-Cluster Service Exposure Patterns

ServiceImport dengan Multi-Cluster Service

Pola ekspos service lintas cluster distandardisasi oleh Multi-Cluster Service API. Service yang ingin di-share diekspor sebagai ServiceExport dan dikonsumsi sebagai ServiceImport.

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

ServiceImport membuat service api-svc bisa diakses dari cluster mana pun dalam satu cluster set. Endpoint aslinya tetap tinggal di cluster tempat service itu berjalan.

Gateway Routing ke Service Lintas Cluster

Setelah ServiceImport tersedia, HTTPRoute bisa menunjuk ke nama service yang sama tanpa tahu letak fisiknya.

Route ke service lintas cluster
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 menunjuk api-svc yang diimpor lewat ServiceImport, bukan alamat pod. Routing menjadi portabel: kode yang sama berjalan di cluster mana pun tanpa diubah.

Hybrid Cloud Networking Considerations

Konektivitas Antar Cloud

Routing lintas cloud hanya berfungsi jika jaringan terhubung. Gunakan VPN site-to-site atau transit gateway agar pod di cloud A bisa mencapai pod di cloud B dengan alamat privat.

Verifikasi service lintas cluster
kubectl get serviceimport -A --context cluster-primary
kubectl get serviceexport -A --context cluster-secondary

Keluaran kubectl get serviceimport -A menunjukkan service yang bisa diakses lintas cluster. Jika daftar kosong, periksa dulu konektivitas jaringan antar cloud sebelum menyalahkan konfigurasi route.

Latensi, Topologi, dan Koneksi Backend

Jangan biarkan request melintasi benua tanpa alasan. Jaga route tetap menuju backend di region yang sama, dan gunakan failover lintas region hanya saat benar-benar diperlukan.

Jika aplikasi memaksa call lintas region, pastikan jalannya pendek dan stabil: pilih region berpasangan yang saling berdekatan, dan dokumentasikan jalur mana yang diizinkan. Network yang tidak terpetakan adalah sumber latensi yang sulit dilacak.

Info

Ukur latensi RTT antar region dan catat di dokumentasi arsitektur. Angka ini menjadi dasar keputusan kapan request boleh berpindah cloud dan kapan harus dipaksa tinggal di region.

Penutup

Episode 17 memperluas jangkauan gateway: konfigurasi identik lintas cluster untuk failover, ServiceImport untuk ekspos service multi-cluster, serta konektivitas dan topologi yang direncanakan untuk cloud hybrid.

Inti yang harus dibawa pulang:

  • Gateway identik di tiap region dengan DNS global sebagai penentu.
  • Konfigurasi lintas cluster dipelihara konsisten dengan GitOps.
  • ServiceImport mengekspos service lintas cluster dalam satu set.
  • HTTPRoute bisa menunjuk service tanpa tahu lokasi fisiknya.
  • Konektivitas antar cloud harus dibangun sebelum routing berfungsi.
  • Jaga traffic tetap di region dan gunakan failover dengan bijak.

Di episode 18 selanjutnya kita akan membahas high availability & disaster recovery — redundansi dan failover gateway, backup serta restore konfigurasi, dan recovery drill untuk interupsi. Topologi multi-cluster yang kalian bangun akan diuji ketahanannya.

Belajar Multigress - Multi-Cluster & Hybrid Deployments | Belajar Multigress