Belajar Velero - Migrasi Antar Cluster

#Pendahuluan

Hingga episode 10, backup dan restore kalian masih dalam "dunia yang sama" — cluster yang sama atau namespace yang sama. Episode 11 melepas batasan itu: memindahkan workload lengkap dengan datanya dari cluster A ke cluster B. Ini yang membuat Velero begitu digemari: migrasi lintas cluster tanpa menyalin YAML manual dan tanpa kehilangan data volume.

Anggap dua cluster seperti dua rumah. Backup di cluster A adalah "kontainer berisi seluruh isi rumah". Restore di cluster B adalah "menurunkan kontainer di rumah baru". Tantangannya bukan memindahkan — tapi memastikan kontainer muat: rak (storage class), ruangan (namespace), dan koneksi listrik (service/ingress) di rumah baru harus cocok.

#Prasyarat dan Persiapan

#BSL Bersama

Kunci migrasi: kedua cluster memakai BSL yang sama — bucket yang sama, region yang sama, credential yang sama. Backup dibuat di cluster A, dan cluster B (dengan Velero terinstall) akan melihat backup tersebut:

velero backup get
velero backup describe my-backup --details

Jika kedua cluster berada di cloud berbeda (AWS → GCP), pastikan plugin masing-masing terpasang dan BSL menunjuk ke bucket yang dapat diakses kedua cloud (misal bucket S3 yang dibaca GCP via interop, atau sebaliknya).

#Perbedaan yang Harus Dicatat Sebelum Migrasi

Buat daftar perbedaan sebelum restore agar tidak kaget:

• Storage class: gp2 (A) vs gp3 atau standard-rwo (B).
• Ingress/Service type: LoadBalancer akan mendapatkan IP/URL baru.
• Node selector / toleration: mungkin cluster B punya label node berbeda.
• Namespace: biasanya sama, tapi bisa dipetakan (--namespace-mappings).

#Workflow Migrasi

#1. Backup di Cluster A

Sebelum migrasi, buat checkpoint akhir — backup fresh yang menangkap state terkini:

velero backup create pre-migration \
  --include-namespaces app \
  --ttl 720h

Jika storage class kedua cluster berbeda, pilih file-level backup (kopia) agar data volume portable:

velero backup create pre-migration \
  --include-namespaces app \
  --default-volumes-to-fs-backup

#2. Restore di Cluster B

velero restore create migration-restore \
  --from-backup pre-migration \
  --storage-class-mappings gp2:gp3

--storage-class-mappings gp2:gp3 memetakan PVC dari storage class cluster A ke storage class cluster B (fitur Velero 1.17+).

#3. Verifikasi di Cluster B

kubectl get deploy,pvc -n app
kubectl exec -n app deploy/nginx -- cat /usr/share/nginx/html/index.html
kubectl get svc -n app

Poin verifikasi penting: pod Running, PVC Bound, dan data terbaca. Catat IP Service yang baru — DNS di cluster A tidak ikut bermigrasi.

#Best Practice Migrasi

#Validasi di Staging Dulu

Jangan langsung cutover. Restore dulu ke namespace staging di cluster B, verifikasi data, baru restore ke namespace produksi:

velero restore create staging-test \
  --from-backup pre-migration \
  --namespace-mappings app:app-staging \
  --storage-class-mappings gp2:gp3

Ini menjawab pertanyaan "bakal jalan nggak?" tanpa risiko. Setelah staging terbukti, lakukan restore final ke namespace aslinya.

#Cutover yang Terencana

Migrasi produksi biasanya mengikuti urutan:

1. Freeze penulisan: arahkan traffic ke mode read-only atau berhenti, lalu buat backup final.
2. Restore di cluster B dengan storage class mapping yang tepat.
3. Switch traffic (DNS/Ingress) ke cluster B.
4. Observasi beberapa jam sebelum menonaktifkan cluster A.

velero backup create final-cutover --include-namespaces app --default-volumes-to-fs-backup

#Checklist Post-Migration

• PVC semua Bound — bukan Pending
• Data volume terbaca (bukan kosong)
• Service/Ingress punya alamat baru dan DNS ter-update
• Secret/ConfigMap tersedia (pod jalan tanpa error ImagePullBackOff/CreateContainerConfigError)
• Backup lama masih utuh di cluster A (jangan dihapus sebelum masa observasi selesai)

#Penutup

Inti yang harus dibawa pulang:

• Migrasi = backup di cluster A + restore di cluster B dengan BSL bersama.
• Backup file-level (kopia) wajib saat storage class/cloud berbeda; snapshot cloud hanya untuk migrasi di cloud yang sama.
• --storage-class-mappings gp2:gp3 menyesuaikan PVC di cluster tujuan.
• Validasi di staging dulu, baru restore final; catat IP Service baru.
• Checklist pasca-migrasi: PVC Bound, data terbaca, DNS ter-update, backup lama disimpan sementara.

Di episode 12 selanjutnya kita merangkum semuanya ke level strategis: Disaster Recovery Plan — menentukan RPO/RTO, backup off-site ke region lain, menyusun runbook restore, dan melatih DR drill dengan menghapus cluster lalu merestore ke cluster baru.