Belajar Kubernetes Block Storage RWO - Migrations, Seeds & Data Lifecycle
Mengelola siklus hidup data di workload stateful: menjalankan migration dan seed pada environment berbeda, memanfaatkan snapshot Longhorn untuk rollback cepat, menyetel backup target S3/NFS dengan recurring schedule, serta aturan emas agar tidak ada data tak persisten yang bocor ke emptyDir.
#Pendahuluan
Di episode 7 kita berhasil menghubungkan Laravel ke PostgreSQL dan menjalankan migrasi. Sekarang kita memperluas cakupan: bagaimana mengelola seluruh siklus hidup data — dari schema yang berubah (migration), data contoh (seed), hingga snapshot & backup sebagai jaringan pengaman.
Mengapa episode ini penting? Data di production jarang statis: tim menambah kolom, aplikasi diganti, atau eksperimen salah. Kalian perlu workflow yang aman untuk mengubah data tanpa menembak kaki sendiri, dan safety net (snapshot & backup) untuk kembali ke keadaan yang baik.
#Migration & Seed dalam Stateful Workload
#Environment Development: migrate:fresh --seed
Ketika bekerja di lab, sering lebih cepat memulai ulang kehidupan data:
kubectl exec -it deploy/laravel -- php artisan migrate:fresh --seedmigrate:fresh menghapus semua tabel lalu menjalankan migrasi lagi, kemudian --seed mengisi data contoh. Ini sangat destruktif — hanya pantas di dev/staging, atau di cluster lab kita.
#Environment Production: migrate --force dengan Job
Production tidak boleh di-fresh. Gunakan pola Job dari episode 7:
kubectl create job --from=cronjob/migrate migrate-$(date +%s) -n productionIntinya: jangan pernah migrate:fresh di production — data tidak bisa diganti dari seed.
| Environment | Strategy Migration & Seed | Kapan Memakai |
|---|---|---|
| Dev/Lab | migrate:fresh --seed | Setiap kali schema berubah drastis |
| Staging | migrate --force via Job | Setelah deploy tinggal |
| Production | migrate --force via Job/pipeline | Setiap rilis, uji backward compat |
#Data Backup dalam Longhorn
#Snapshot: Cadangan Lokal untuk Rollback Cepat
Snapshot Longhorn adalah gambar konsisten volume di lokasi yang sama (di node). Bukan cadangan off-site, tetapi sangat berguna untuk rollback saat operasi berubah schema atau upgrade gagal.
Longhorn UI → Volume data-postgres-0 → Create SnapshotBeri nama yang bermakna: pre-migrate-20260125, before-upgrade-20. Longhorn menyimpan snapshot sebagai chain — setiap snapshot kecil sepanjang data yang berubah. Episode 14 membahas restore & clone dari snapshot.
#Backup ke S3/NFS Target
Backup adalah salinan yang dikirim ke luar cluster — S3, NFS, atau SFTP. Berbeda dengan snapshot, backup survive kehilangan semua node.
Untuk episode ini, cukup pahami alurnya:
- Set backup target di UI →
Setting → BackupTarget. - Longhorn meng-upload blok yang berubah ke target.
- Backup diperlakukan sebagai entitas independent yang bisa di-restore ke volume baru.
Detail lengkap backup dan recurring schedule ada di episode 15.
#Recurring Snapshot & Backup
Longhorn memiliki RecurringJob — tugas terjadwal otomatis:
| Recurring Job | Jadwal Contoh | Retensi |
|---|---|---|
| Snapshot harian | 0 2 * * * | simpan 7 |
| Backup mingguan | 0 3 * * 0 | simpan 4 |
Kita praktikkan lengkap di episode 15; di sini cukup mengetahui bahwa snapshot/backup bisa dijadwalkan — tidak harus manual.
#Data Lifecycle: Anti-Pattern dan Aturan Emas
#Anti-Pattern: Data State di emptyDir
Perhatikan error klasik berikut:
volumes:
- name: cache
emptyDir: {}emptyDir selalu dihapus ketika Pod mati. Data di sana hidup selama Pod hidup — jika developer mengira "cache" cocok, mungkin benar. Tapi jika ada yang menaruh upload, session, atau log yang justru penting di sana, itu bencana.
Aturan emas di Kubernetes:
- emptyDir: untuk data sementara (cache, scratch), layak hilang.
- hostPath: jarang dipakai, tidak portable, tidak HA.
- PersistentVolumeClaim (Longhorn): untuk data yang harus bertahan — database, file upload, log yang diretain.
#Anti-Pattern: Replica Menambal dengan Local Disk
Beberapa tim "solutif" menambahkan disk lokal node (hostPath) sebagai tempat database saat PVC penuh. Ini membuat data terkunci di satu node — mati node, mati data. Jika disk penuh, solusi yang benar: expand PVC (episode 20) atau pindah ke volume lebih besar.
#Siklus Hidup yang Sehat
| Fase | Tool | Tujuan |
|---|---|---|
| Ubah schema | php artisan migrate --force | Struktur DB baru |
| Isi sampel | db:seed (hanya non-prod) | Data contoh |
| Jaga titik kembali | Longhorn Snapshot | Rollback cepat |
| Cadangkan off-site | Longhorn Backup ke S3/NFS | Bertahan kehilangan cluster |
Important
Bedakan snapshot (lokal, instan, hemat, tapi mati bersama node) dan backup (off-site, lambat, tapi selamat dari kiamat node). Keduanya wajib dimiliki workload database. Snapshot untuk operasi harian, backup untuk DR.
#Penutup
Inti yang harus dibawa pulang:
- Dev boleh
migrate:fresh --seed; production--forcelewat Job saja. - Snapshot Longhorn = rollback cepat lokal; backup = asuransi off-site.
- Recurring job bisa otomatiskan snapshot & backup dengan retensi.
- Jangan pernah menyimpan data state di emptyDir — hanya volume persisten yang layak dipercaya.
Di episode 9 selanjutnya kita akan membahas replikasi data & high availability — perilaku replica (kuorum, degraded, offline), proses rebuild, peran data locality & performa, plus simulasi kegagalan node dengan cordon dan drain. Sampai jumpa di episode 9!