Belajar Kubernetes Shared Filesystem RWX - Persistent Volume (PV) Static & Volume Attach

#Pendahuluan

Dynamic provisioning di episode 5 membuat PV secara otomatis. Tetapi ada skenario di mana kalian tidak mau otomatis: data yang sudah ada di NFS — misalnya folder media lama berisi ribuan file dari server monolith, atau direktori yang harus dipertahankan apa adanya.

Dalam skenario itu, kita membuat PV statis: kalian (administrator) mendefinisikan sendiri volume yang menunjuk ke path NFS, lalu PVC dibinding ke PV itu secara manual. Di episode 6 ini kita pelajari caranya beserta aturan binding-nya.

#Membuat PV Statis (Manual)

Anggap di NFS server sudah ada folder /srv/k8s-shared/media berisi file media proyek lama. Untuk memakainya, kita buat PV yang menunjuk langsung ke path tersebut:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-static-media
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.10.20
    path: /srv/k8s-shared/media

Terapkan PV statis

kubectl apply -f pv-static-media.yaml
kubectl get pv

Catatan penting: karena PV pada dasarnya menunjuk ke path NFS yang TIDAK dibuat oleh driver, PVC di atasnya tidak akan memicu provisioning apa pun. PV menunggu PVC yang cocok.

Perhatikan bahwa spec.nfs (bukan spec.csi) — ini adalah volume NFS klasik yang sudah didukung Kubernetes sejak awal, tanpa perlu driver CSI. Bila kalian ingin memakai driver (dan fitur expand), bisa juga menggunakan PV berbasis CSI, tetapi untuk data statis sederhana pendekatan spec.nfs ini paling langsung.

#Binding PV-PVC

Agar PVC terikat ke PV, terjadi pencocokan (binding) berdasarkan kriteria:

1. Access mode — harus cocok (RWX ↔ RWX).
2. Kapasitas — request PVC harus dipenuhi PV (requests.storage ≤ capacity.storage).
3. StorageClassName — cocok atau keduanya kosong.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: media-static
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi

Apply PVC dan cek binding

kubectl apply -f pvc-media-static.yaml
kubectl get pvc media-static
kubectl describe pvc media-static

kubectl describe pvc segera menampilkan event Successfully bound persistentvolume "nfs-static-media". Jika ada lebih dari satu PV yang cocok, Kubernetes memilih yang paling sesuai — describe adalah cara kalian melihat keputusannya.

#Perbedaan Dynamic vs Static Provisioning

Mana yang dipakai? Untuk aplikasi baru: dynamic. Untuk data lama atau direktori bersama yang sudah dilaksanakan di luar Kubernetes: statis.

#Storage Class Default

Ketika PVC dibuat tanpa storageClassName, Kubernetes memakai StorageClass yang ditandai default. Tandai StorageClass nfs-rwx sebagai default jika kalian ingin semua PVC tanpa class otomatis memakai NFS:

Tandai StorageClass default

kubectl patch storageclass nfs-rwx -p \
  '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

Verifikasi

kubectl get sc

Output menampilkan (default) di kolom nama StorageClass.

#Penutup

Pada episode 6 ini, kalian telah menguasai provisioning statis:

Inti yang harus dibawa pulang:

• PV statis cocok untuk data yang sudah ada — manifest spec.nfs menunjuk langsung ke path.
• Binding mempertimbangkan access mode, kapasitas, dan StorageClass.
• Dynamic = otomatis via StorageClass; Static = manual dan eksplisit.
• StorageClass default dipakai untuk PVC tanpa class; berhati-hati menandai default di cluster dengan database.

Di episode 7 selanjutnya kita masuk ke dunia aplikasi: struktur storage Laravel dan persiapan build — folder mana yang harus di-share, mana yang baked ke image, dan bagaimana Laravel menulis/membaca file lewat Storage. Sampai jumpa di episode 7!