Belajar Kubernetes Block Storage RWO - Volume Expansion & allowVolumeExpansion (DB Growing)

#Pendahuluan

Di episode 19 kita membahas scaling dan kapan memperbesar disk. Episode 20 menyelami mekanisme intinya dengan cukup dalam: volume expansion — mengapa fitur yang tampak sepele ini bisa menjadi pembeda antara downtime dan jalan terus.

Mengapa penting? Database adalah binatang yang tidak pernah puas: log, index, dan data tumbuh seiring waktu. Jika volume "fixed" (tidak bisa di-expand), saat penuh kalian dipaksa migrasi volume — operasi berat berisiko downtime. Dengan allowVolumeExpansion + Longhorn, resizing adalah operasi online ringan. Sayangnya, fitur ini sering terlupakan saat StorageClass pertama dibuat.

#Masalah Volume Fixed di Produksi

#Skenario yang Terjadi Terus

Volume data-postgres-0 dibuat 10Gi. Enam bulan kemudian, tabel transaksi membengkak:

Volume hampir penuh

kubectl exec -it postgres-0 -- df -h /var/lib/postgresql/data

text

Filesystem      Size  Used Avail Use% Mounted on
/dev/vol-xxx    9.8G  9.3G  468M  95% /var/lib/postgresql/data

Jika StorageClass tidak mengaktifkan ekspansi, PVC tidak bisa diperbesar → database berhenti menulis (Postgres mengunci saat disk penuh), downtime mulai.

#Kesimpulan: Wajib Sejak Awal

allowVolumeExpansion: true harus ditetapkan di StorageClass sebelum membuat PVC. Mengubah StorageClass tidak mempengaruhi PVC yang sudah ada — jadi pastikan sejak pertama.

#Konsep Expansion di Longhorn

#Online Expansion

Longhorn mendukung online expansion:

Volume tetap ter-mount dan Pod terus jalan.
I/O tidak terputus.
Longhorn client melakukan resize block device dan filesystem secara bertahap.

Tidak seperti sebagian storage lain (yang mengunci volume saat expand), Longhorn melakukan capaian resize yang aman.

#Thin-Provisioning di Back-End

Kapasitas yang diminta PVC ≠ blok yang benar-benar dialokasi.
Longhorn mengalokasi blok dari pool saat diperlukan (thin-stage) — disk fisik baru benar-benar terpakai saat data ditulis.
Konsekuensi: sebelum expand, pastikan node tujuan punya ruang disk kosong yang cukup untuk blok yang akan dialokasi. Jika node penuh, resize bisa gagal atau tersendat.

#Manifest StorageClass

#StorageClass dengan allowVolumeExpansion

yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
  numberOfReplicas: "3"
  dataLocality: "best-effort"
  fsType: "ext4"

Field allowVolumeExpansion: true adalah kuncinya. Cek StorageClass yang sudah ada:

Cek allowVolumeExpansion

kubectl get storageclass longhorn -o jsonpath='{.allowVolumeExpansion}{"\n"}'

#Ekspansi PVC (Online)

#Edit PVC

Perbesar PVC data-postgres-0

kubectl edit pvc data-postgres-0

Ubah dari 10Gi menjadi 20Gi:

yaml

spec:
  resources:
    requests:
      storage: 20Gi

#Alur di Belakang

Operator Longhorn mendeteksi request resize.
Menambah size pada volume (engine + replica).
CSI csi-resizer memanggil NodeExpandVolume.
Longhorn me-resize block device dan kemudian filesystem (ext4/xfs) tanpa unmount — dukungan online resize filesystem bawaan.

#Verifikasi

Cek status PVC & df di Pod

kubectl get pvc data-postgres-0
kubectl exec -it postgres-0 -- df -h /var/lib/postgresql/data

Jika df -h menampilkan kapasitas baru, resize selesai. Selama proses, PVC bisa dikunjungi status FilesystemResizePending sesaat.

Important

Expansion tidak bisa dikurangi — hanya diperbesar. Rencanakan pertumbuhan (mis. tambah 50% dari yang diperkirakan) dan jangan lupa kapasitas fisik: 20Gi volume berarti butuh ruang 3× untuk replica (60Gi di pool), jadi pastikan node punya ruang.

#Catatan Operasional

Monitor penggunaan volume secara proaktif (episode 17) supaya resize dilakukan sebelum kritis.
Alerts: pasang alert disk >70% untuk men-trigger keputusan expand lebih awal.
Mulai resize di window sepi; umumnya instan tapi atur harapan pada volume besar.
Setelah resize, pertimbangkan juga memperbesar backup target (jika NFS terbatas).

#Penutup

Inti yang harus dibawa pulang:

Database tumbuh — wajib allowVolumeExpansion: true di StorageClass sejak awal.
Longhorn resize online: volume tetap mount, I/O tidak terputus.
Thin-provisioning: pastikan node punya ruang fisik sebelum expand.
Edit requests.storage di PVC → Longhorn resize block + filesystem → verifikasi dengan df -h.

Di episode 21 selanjutnya kita akan membahas upgrade Longhorn, non-disruptive release & compatibility matrix — strategi upgrade dua langkah, prosedur helm upgrade aman, tinjauan breaking changes, rollback, dan matriks kompatibilitas versi di 2026. Sampai jumpa di episode 21!