Belajar Kubernetes Shared Filesystem RWX - Membuat StorageClass & Dynamic Provisioning

#Pendahuluan

Driver sudah terpasang, tetapi belum berguna — belum ada StorageClass yang menghubungkan driver dengan NFS server kita. StorageClass adalah resep yang dipakai Kubernetes saat membuat PV secara dinamis. Tanpa resep ini, PVC yang kalian buat akan selamanya Pending.

Episod ini menandai momen "bekerja": setelah StorageClass dibuat, kalian bisa membuat volume berapa pun dengan satu perintah kubectl apply. Ini adalah dynamic provisioning — jantung produktivitas storage di Kubernetes.

#Membuat StorageClass NFS

Manifest berikut mendefinisikan StorageClass nfs-rwx untuk driver kita:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-rwx
provisioner: nfs.csi.k8s.io
parameters:
  server: 192.168.10.20
  share: /srv/k8s-shared
  subDir: dynamic/${pvc.namespace}/${pvc.name}
mountOptions:
  - nfsvers=4.2
  - hard
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true

Terapkan dan verifikasi:

Apply StorageClass

kubectl apply -f storageclass-nfs-rwx.yaml
kubectl get sc

Parameter penting:

• server dan share — alamat NFS server beserta direktori export-nya.
• subDir — template path sub-direktori di dalam share. dynamic/${pvc.namespace}/${pvc.name} menghasilkan path unik per PVC, sehingga data antar aplikasi terisolasi.

• mountOptions — opsi mount yang dipakai semua Pod: nfsvers=4.2 (protokol) dan hard (retry tanpa batas saat NFS down — aman untuk data, detail di episode 16).
• reclaimPolicy: Delete — saat PVC dihapus, PV dan datanya ikut terhapus. Hati-hati!
• volumeBindingMode: Immediate — PV langsung diprovision saat PVC dibuat (tanpa menunggu Pod).

#Dynamic Provisioning

Sekarang buat PVC. Driver membaca StorageClass, memanggil csi-provisioner, dan membuat subdirektori di NFS server:

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

Buat PVC dan cek status

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

Karena volumeBindingMode: Immediate, status seharusnya langsung Bound — tidak perlu Pod dulu.

#Melakukan Verifikasi Volume

#Dari Sisi Kubernetes

Cek PVC dan PV

kubectl get pvc rwx-media
kubectl get pv
kubectl get pv -o jsonpath='{.items[*].spec.nfs}{"\n"}'

PV yang terbentuk akan memakai volumeSource bertipe NFS (dibuat oleh driver), bukan hostPath.

#Dari Sisi NFS Server

Buka shell di NFS server dan lihat direktori yang dibuat driver:

ls -la /srv/k8s-shared/dynamic/default/rwx-media/
sudo mkdir -p /srv/k8s-shared/dynamic/default/rwx-media/.probe

Direktori provisioanl muncul otomatis — bukti driver berkomunikasi dengan server.

#Volume Expansion & Reclaim

Dua atribut StorageClass yang memengaruhi siklus hidup volume:

• allowVolumeExpansion: true — mengizinkan resize PVC secara online tanpa downtime. Kalian cukup mengubah spec.resources.requests.storage lewat kubectl edit pvc. Implementasi penuhnya (termasuk persyaratan ruang di server) kita bedah di episode 16.
• reclaimPolicy: Delete — menghapus PV dan data saat PVC dibuang. Praktis untuk lab, tetapi pastikan kalian paham konsekuensinya sebelum menghapus PVC yang berisi data penting.

#Penutup

Pada episode 5 ini, kalian telah membangun jalur dynamic provisioning:

Inti yang harus dibawa pulang:

• StorageClass nfs-rwx menghubungkan driver nfs.csi.k8s.io dengan server/share NFS.
• subDir template memberi isolasi per-PVC: dynamic/${pvc.namespace}/${pvc.name}.
• PVC Bound langsung karena volumeBindingMode: Immediate.
• Verifikasi dari dua arah: kubectl get pv dan ls /srv/k8s-shared/dynamic/....
• allowVolumeExpansion: true untuk resize online; reclaimPolicy: Delete berarti data hilang saat PVC dihapus.

Di episode 6 selanjutnya kita akan belajar Persistent Volume (PV) statis dan volume attach: membuat PV manual untuk data yang sudah ada, aturan binding PV-PVC, perbedaan dynamic vs static provisioning, dan StorageClass default. Sampai jumpa di episode 6!