Belajar Kubernetes Simple Shared Storage - StorageClass & Proses Provisioning

#Pendahuluan

OpenEBS sudah terpasang, tetapi belum punya "resep" untuk membuat volume sesuai keinginan kita. StorageClass adalah resep itu. Di episode 5 kita menyusun dua resep yang menjadi tulang punggung seluruh series: hostpath (RWO lokal) dan NFS RWX (shared).

Setelah keduanya ada, kalian tinggal membuat PVC dan melihat keajaiban provisioning: NFS server hidup otomatis, data tersimpan di backing volume, dan akses RWX bekerja.

#StorageClass Local PV Hostpath

StorageClass bawaan openebs-hostpath sudah ada (episode 4). Manifestnya setara dengan ini:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: openebs-hostpath
provisioner: openebs.io/local
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete
allowVolumeExpansion: true

Karakteristik penting:

• openebs.io/local — volume ditempel di folder node (/var/lib/openebs/).
• WaitForFirstConsumer — volume baru dibuat ketika ada Pod pertama yang memakainya; dengan ini, Pod dan volume dijamin di node yang sama.
• RWO — satu node, satu Pod. Latensi rendah, namun tidak shared.

#StorageClass NFS (RWX)

StorageClass kedua menyediakan akses shared. Ini adalah "resep ajaib" series ini:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: openebs-nfs-rwx
provisioner: openebs.io/nfs
parameters:
  backendStorageClass: openebs-hostpath
  nfsServerType: kernel-nfs

Parameter bermakna:

• backendStorageClass: openebs-hostpath — data NFS disimpan di volume Local PV hostpath (RWO di bawah, RWX di atas).
• nfsServerType: kernel-nfs — memakai NFS server kernel Linux (ringan). Alternatif: nfsganesha (fitur lebih kaya, lebih berat).

Apply kedua StorageClass

kubectl apply -f sc-openebs-hostpath.yaml -f sc-openebs-nfs-rwx.yaml
kubectl get sc

#Provisioning PVC

#PVC RWX Pertama

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: media-storage
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: openebs-nfs-rwx
  resources:
    requests:
      storage: 5Gi

Buat dan cek PVC RWX

kubectl apply -f pvc-media-storage.yaml
kubectl get pvc media-storage

Karena NFS StorageClass memakai backendStorageClass: openebs-hostpath (yang bermode WaitForFirstConsumer), PVC baru Bound setelah ada Pod pertama yang memakainya — ini perilaku normal.

#Apa yang Terjadi di Belakang

Lihat PV dan NFS Server Pod

kubectl get pv -o wide
kubectl -n openebs-nfs get pods
kubectl -n openebs-nfs get svc

Di namespace storage (openebs-nfs), akan muncul NFS Server Pod bernama nfs-media-storage-... beserta Service-nya — persis seperti desain episode 2.

#Verifikasi Status

Verifikasi PVC Bound

kubectl get pvc media-storage

Status Bound berarti siklus provisioning sukses: PVC → NFS Server Pod → backing Local PV → PV Bound → Pod siap mount di worker mana pun. Cek juga kapasitas dan node asal data:

Cek asal data

kubectl get pv -o jsonpath='{.items[?(@.spec.claimRef.name=="media-storage")].spec.local.path}{"\n"}'

#Penutup

Pada episode 5 ini, dua resep storage telah aktif:

Inti yang harus dibawa pulang:

• openebs-hostpath: RWO lokal, WaitForFirstConsumer, latensi rendah.
• openebs-nfs-rwx: RWX dengan backendStorageClass + nfsServerType: kernel-nfs.
• PVC RWX memicu NFS Server Pod + Service di namespace openebs-nfs.
• Pembutan volume NFS menunggu consumer pertama karena backing hostpath.
• Verifikasi: PVC Bound, NFS Pod & Service ada, PV menunjuk folder node.

Di episode 6 selanjutnya kita akan memverifikasi controller dan NFS daemon: diagnosa dengan kubectl get pvc dan log provisioner, meninjau Pod NFS server dan Service per-PVC, serta melakukan uji mount dengan dua Pod alpine. Sampai jumpa di episode 6!