Belajar Kubernetes Shared Filesystem RWX - Studi Kasus & Refleksi

#Pendahuluan

Ini episode terakhir perjalanan 28 episode. Sebelum kalian menutup tab, mari kita rangkai semua yang sudah dipelajari menjadi satu gambar utuh: arsitektur yang berdiri dari episode 0 sampai 26, lalu kita uji dia dengan skenario nyata, tebak-tebakan debugging, dan bercermin ke langkah berikutnya.

Ini bukan sekadar review — ini latihan "semua bisa gagal" yang justru membuat keyakinan kalian terhadap sistem menjadi nyata.

#Recap Arsitektur Final

Arsitektur yang kita bangun dari awal:

100%

Bahan yang sudah kalian rakit:

• Cluster 5 node (3 CP + 2 worker) — topologi dari episode 0.
• NFS server dedicated (v4.2) dengan ekspor terkunci IP worker, all_squash/anonuid (episode 13).
• NFS CSI Driver via Helm + StorageClass nfs-rwx dengan allowVolumeExpansion (episode 4-5).
• Laravel multi-replica dengan PVC RWX, probe, Ingress, init container symlink (episode 9-12).
• Observability + backup: monitoring, snapshot, Velero, runbook (episode 17-23).

#Skenario Simulasi

#Skala 3 → 10 Replica

Skala horizontal di atas volume yang sama

kubectl scale deployment laravel --replicas=10
kubectl get pods -l app=laravel -o wide

Upload berjalan di Pod mana pun, terlihat di semua — karena storage tidak peduli replika mana yang menulis (episode 19).

#Restart Pod Random Tanpa Kehilangan Data

Uji persistensi data

kubectl rollout restart deployment/laravel
kubectl exec deploy/laravel -- ls /var/www/storage/app/uploads/

Data upload tetap utuh pasca-restart — bukti hidup data di NFS, bukan di Pod.

#NFS Server Mati (Downtime Drill)

Matikan service NFS di server, lalu amati: mount worker membeku (hard), dashboard nginx error naik, alert menyala (episode 18). Nyalakan kembali, dan tanpa intervensi manual, proses yang menunggu melanjutkan write. Drill ini mengajarkan dua hal: pentingnya HA (episode 20) dan harga dari setiap detik downtime.

#Sesi Problem Solving

Latihan diagnosis cepat — menutup tiga kasus umum dari episode 24:

1. Permission error: upload gagal, ls -ln menunjukkan file ber-owner 1000, proses aplikasi 33 → samakan UID; jangan asal chmod 777.
2. Mount hang: describe pod menampilkan MountVolume.MountDevice failed → uji showmount -e dan mount manual dari worker sebelum menyentuh manifest.
3. PVC pending: kubectl get events menunjukkan Failed to provision volume → cek log csi-nfs-controller dan ekspor di server (exportfs -v).

Hierarki berpikirnya selalu sama: baca gejala di objek Kubernetes, verifikasi di sisi NFS, baru ubah konfigurasi.

#Apa Selanjutnya dalam Metode Belajar

Kalau kalian sampai di sini, fondasi storage RWX sudah solid. Selanjutnya:

• Block storage (RWO) → series Belajar Longhorn / Rook-Ceph RBD untuk database yang butuh replikasi.
• Distributed storage → series Belajar Rook-Ceph untuk kebutuhan multi-protocol berskala besar.
• Simple shared storage → series Belajar OpenEBS / Simple Shared Storage untuk lab tanpa mesin NFS terpisah.

Alur belajar alami: mulai dari kebutuhan aplikasi → pilih storage yang sepadan → maintenace dan backup yang disiplin → kombinasi beberapa storage untuk arsitektur yang matang.

#Penutup

28 episode, enam fase, satu perjalanan. Yang kalian bawa pulang sekarang bukan sekadar "bisa bikin PVC RWX", melainkan cara berpikir tentang storage: memahami NFS, memperhitungkan UID/GID, mengamankan jaringan, menjaga performa, memulai backup, dan — sama pentingnya — tahu kapan harus pindah ke teknologi lain.

Rangkuman besar:

• Shared filesystem RWX adalah tulang punggung aplikasi web multi-replica.
• NFS + NFS CSI Driver: solusi paling sederhana yang tetap profesional.
• Setiap lapisan punya disiplinnya: permission, keamanan, monitoring, backup.
• Storage adalah keputusan bisnis — sesuaikan dengan beban dan skala tim.

Terima kasih sudah bertahan sampai episode 27. Praktikkan, rusakkan di lab, perbaiki, dan bangun sistem yang kalian yakin bisa tidur nyenyak. Kalau seri ini bermanfaat, lanjutkan ke seri storage berikutnya — dan sampai jumpa di series yang lain!