Belajar Kubernetes Block Storage RWO - StorageClass & Dynamic Provisioning Volume

#Pendahuluan

Longhorn sudah terpasang di episode 4. Sekarang kalian punya StorageClass longhorn bawaan — tapi untuk production kita biasanya butuh lebih dari satu StorageClass untuk workload berbeda: satu untuk database (HA, strict), satu untuk app (cost-efficient). Episode 5 membahas cara membuat StorageClass kustom dan bagaimana dynamic provisioning bekerja dari PVC hingga PV Bound.

Mengapa penting? Karena keputusan numberOfReplicas, dataLocality, dan fsType menentukan biaya, performa, dan toleransi kegagalan setiap volume. Salah memilih = disk cepat penuh atau volume lambat.

#StorageClass Longhorn Dasar

#Manifest StorageClass Kustom

yaml

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

Perhatikan bahwa semua parameter wajib string — itulah kenapa numberOfReplicas dan nilai numerik lain diberi tanda kutip.

#Parameter Penting

#numberOfReplicas

Jumlah salinan block data. Range 1–5, default 3.

Replica	Pemakaian Disk	Toleransi node mati
1	1×	Tidak ada
2	2×	1 node
3	3×	1 node (kuorum 2)
5	5×	2 node (kuorum 3)

Aturan praktis: produksi = 3. Minimal 2 jika disk terbatas tapi tetap ingin HA node tunggal. Untuk dev bisa 1.

#dataLocality

Mengontrol preferensi lokasi data relatif terhadap node tempat volume aktif:

disabled: Longhorn bebas menaruh replica di node mana pun.
best-effort: mencoba menaruh replica di node yang menjalankan volume (rendah latency), tapi tetap pindah bila diperlukan.
strict-local: semua replica harus di node yang sama dengan volume (latency terendah, tetapi tidak ada replikasi cross-node — HA hilang).

Untuk database di 2 worker: best-effort adalah kompromi bagus — replica aktif lokal, replika lainnya di node kedua.

#fsType

Filesystem yang dibuat di atas volume block: ext4 (default) atau xfs. Keduanya mendukung online resize (dibutuhkan untuk episode 20). Untuk database PostgreSQL, ext4 cukup; xfs unggul pada beban file besar.

#fromBackup

Saat dipakai provision, Longhorn bisa langsung restore dari backup. Kita bahas detail di episode 15-16.

#Membuat PVC dan Verifikasi

#Manifest PVC

yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-postgres
  namespace: default
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn-ha
  resources:
    requests:
      storage: 10Gi

#Apply dan Cek Status

Buat PVC & cek status

kubectl apply -f pvc-postgres.yaml
kubectl get pvc pvc-postgres

Harusnya dalam hitungan detik status menjadi Bound:

text

NAME           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-postgres   Bound    pvc-5f4d9a2c-...                           10Gi        RWO            longhorn-ha    12s

#Baca PV yang Ter-provisi

Deskripsikan PV

kubectl describe pv pvc-5f4d9a2c-...

Perhatikan field:

Capacity: 10Gi
Access Modes: ReadWriteOnce
StorageClass: longhorn-ha
Source: Longhorn (kubernetes.io/pv-name) — menunjuk ke volume Longhorn di belakangnya.

Di balik layar, driver driver.longhorn.io memanggil Longhorn Volume CRD untuk membuat engine + replica, lalu CSI provisioner menciptakan PV.

#UI Longhorn: Volume Baru

Buka dashboard → menu Volume. Kalian akan melihat pvc-postgres atau volume yang tersamarkan nama (misal pvc-5f4d...).

Panel volume menampilkan:

State: Attached (saat dipakai Pod) atau Detached.
Engine & Replica: status health, jumlah replica, dan lokasi.
Monitoring I/O: grafik read/write IOPS dan throughput.
Schedules: create snapshot / backup.

Note

Volume Pending di Longhorn ≠ PVC Pending. Sebuah volume Longhorn bisa Detached (sehat tapi tidak dipakai Pod), sedangkan PVC Pending berarti StorageClass mismatch atau driver belum siap. Cek log longhorn-csi-plugin bila PVC tak kunjung Bound.

#Penutup

Inti yang harus dibawa pulang:

StorageClass mengontrol numberOfReplicas, dataLocality, fsType — semua nilai harus string.
PVC request 10Gi dengan StorageClass longhorn-ha → PV Bound otomatis (dynamic provisioning).
3 replica = 3× disk; dataLocality best-effort menyeimbangkan latency pergi dan HA.
Dashboard Longhorn memberi visibility engine, replica, dan I/O setiap volume.

Di episode 6 selanjutnya kita akan menyusun StatefulSet PostgreSQL di atas Longhorn — volumeClaimTemplates, setelan fsGroup dan securityContext untuk akses data, lalu uji persistensi dengan delete Pod. Sampai jumpa di episode 6!