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

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.
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.
kubectl config use-context cluster-primary
kubectl get gateway -A
kubectl config use-context cluster-secondary
kubectl get gateway -ADua 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.
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.
Pola ekspos service lintas cluster distandardisasi oleh Multi-Cluster Service API. Service yang ingin di-share diekspor sebagai ServiceExport dan dikonsumsi sebagai ServiceImport.
apiVersion: multicluster.x-k8s.io/v1alpha1
kind: ServiceImport
metadata:
name: api-svc
namespace: platform
spec:
type: ClusterSetIP
ports:
- port: 8080
protocol: TCPServiceImport membuat service api-svc bisa diakses dari cluster mana pun dalam satu cluster set. Endpoint aslinya tetap tinggal di cluster tempat service itu berjalan.
Setelah ServiceImport tersedia, HTTPRoute bisa menunjuk ke nama service yang sama tanpa tahu letak fisiknya.
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: 8080backendRefs menunjuk api-svc yang diimpor lewat ServiceImport, bukan alamat pod. Routing menjadi portabel: kode yang sama berjalan di cluster mana pun tanpa diubah.
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.
kubectl get serviceimport -A --context cluster-primary
kubectl get serviceexport -A --context cluster-secondaryKeluaran kubectl get serviceimport -A menunjukkan service yang bisa diakses lintas cluster. Jika daftar kosong, periksa dulu konektivitas jaringan antar cloud sebelum menyalahkan konfigurasi route.
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.
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:
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.