Belajar Kubernetes Shared Filesystem RWX - Mengapa Aplikasi Web Butuh Shared Filesystem

#Pendahuluan

Setelah di episode 0 kita menyiapkan environment — cluster 5 node, kubectl, Helm, dan NFS server terpisah — pada episode ini kita membahas pertanyaan yang paling mendasar: mengapa aplikasi web butuh shared filesystem? Ini bukan pertanyaan akademis; jawabannya adalah akar dari semua desain yang akan kita bangun di episode-episode berikutnya.

Bayangkan aplikasi Laravel yang menjual jasa fotografi: user meng-upload hasil foto ke galerinya. Saat traffic naik, kita menambah replica Pod dari 1 menjadi 3. Tanpa shared storage, fitur paling dasar aplikasi tersebut — upload — langsung rusak. Di episode ini kita bongkar kenapa, lalu mengenalkan access modes Kubernetes sebagai bahasa untuk mendiskusikan solusinya.

#Kasus: Berbagi Gaya Monolith Laravel

Laravel, seperti framework web klasik lainnya, menyimpan banyak hal sebagai file di direktori storage/:

Saat aplikasi diskalakan ke banyak replica Pod, file yang ditulis oleh Pod A harus bisa dibaca oleh Pod B. Session yang dibuat di Pod A harus dikenali ketika request berikutnya masuk ke Pod B. Upload user yang disimpan di Pod A harus tampil ketika Pod B melayani request.

#Masalah Tanpa Shared Storage

Apa yang terjadi jika setiap Pod menyimpan file di filesystem lokalnya sendiri?

Upload masuk via LoadBalancer → random ke Pod A atau Pod B
Pod A: file tersimpan di disk Pod A
Pod B: file TIDAK ADA

Tiga masalah konkret yang muncul:

• Upload tak terlihat antar Pod. Load balancer mengarahkan request secara acak. User upload lewat Pod A, lalu membuka halaman yang dilayani Pod B — file tidak ditemukan.
• Data hilang saat Pod restart/redeploy. Filesystem lokal Pod bersifat ephemeral. Pod restart karena crash, upgrade, atau rollout restart? Data ikut hilang.
• emptyDir tidak membantu. emptyDir memang berbagi antar container dalam satu Pod, tetapi hanya bertahan selama Pod hidup dan TIDAK terbagi antar Pod.

emptyDir — berbagi antar container, bukan antar Pod

apiVersion: v1
kind: Pod
metadata:
  name: uploader
spec:
  containers:
    - name: worker
      image: ubuntu
      volumeMounts:
        - name: scrap
          mountPath: /data
  volumes:
    - name: scrap
      emptyDir: {}

#Access Modes di Kubernetes

Kubernetes mendeskripsikan kemampuan akses sebuah volume lewat access modes. Ini adalah kontrak yang menentukan berapa banyak node dan Pod yang boleh membaca/menulis volume:

Access mode ditulis di PVC/PV, dan harus cocok agar binding terjadi. ReadWriteOncePod adalah varian yang lebih ketat (satu Pod di seluruh cluster). Untuk series ini fokus utama kita adalah RWX.

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

• Database (PostgreSQL/MySQL) → RWO. Satu replika primary menulis; replika lain memakai replicas/streaming — bukan berbagi file disk yang sama.
• Shared files/media/upload → RWX. Semua replica Pod menulis ke direktori yang sama.

#Memilih Storage untuk File Sharing

Untuk kebutuhan RWX ada beberapa pendekatan. Untuk kasus web files kita:

• NFS + NFS CSI Driver — simple, murah, mumpuni untuk web files. Satu NFS server mengekspor direktori; semua worker mount ke sana. Tidak ada replikasi data, jadi cocok untuk data non-kritis seperti upload/media.
• Distributed filesystem (CephFS/Rook, GlusterFS) — hebat namun kompleks dan berat secara operasional. Kita bahas kapan harus memakainya di episode 26.
• Object storage (S3/MinIO) — unggul untuk blobs besar dan media yang tidak butuh filesystem semantics, tetapi mengubah cara aplikasi menulis/ membaca file.

Konfigurasi centralized seperti NFS memiliki karakter yang pas untuk upload/gallery/media: metadata ringan, akses langsung via mount, dan tidak mengubah kode aplikasi — file_put_contents() dan Storage::put() tetap bekerja apa adanya.

#Penutup

Pada episode 1 ini, kalian telah memahami akar masalah yang memotivasi seluruh series:

Inti yang harus dibawa pulang:

• Laravel menyimpan upload, media, session, dan cache sebagai file di storage/.
• Tanpa shared storage, upload antar replica tidak terlihat dan data hilang saat Pod restart.
• emptyDir hanya berbagi antar container, bukan antar Pod.
• Access modes menentukan kontrak akses: RWO untuk database, RWX untuk shared files/media.
• NFS + NFS CSI Driver adalah pilihan paling sederhana untuk web files RWX.

Di episode 2 selanjutnya kita akan membahas konsep dasar NFS dan Container Storage Interface (CSI): sejarah dan keunggulan NFS v4.2, bagaimana CSI menjembatani Kubernetes dengan storage provider, dan alur kerja NFS CSI Driver dari PVC sampai Pod mount. Sampai jumpa di episode 2!