Belajar Kubernetes Simple Shared Storage - Mengapa Simple Shared Storage untuk Lab/Small Cluster
Memahami alasan di balik pilihan arsitektur: mengapa Rook-Ceph dan Longhorn terlalu berat untuk lab, mengapa OpenEBS Local PV plus Dynamic NFS Provisioner adalah keseimbangan yang tepat, dan kapan sebaiknya memakai solusi lainnya
#Pendahuluan
Setelah environment siap di episode 0, kita mulai dengan pertanyaan desain: solusi storage mana? Sebelum menulis satu baris YAML, kalian perlu memahami mengapa "simple shared storage" adalah pilihan yang segaja—bukan karena tidak tahu teknologi lain, melainkan karena sudah mempertimbangkannya dan menolaknya demi alasan yang baik.
Episode 1 membangun argumen itu: masalah di lab, solusi OpenEBS + NFS, dan garis batas kapan simple tidak cukup.
#Masalah Shared Storage di Lab/Small Cluster
Kebutuhan lab/small cluster nyaris selalu sama:
- Tidak mau kompleksitas Rook-Ceph (operator, 3 monitor, OSD, placement groups) atau Longhorn (engine per volume) untuk sekadar upload upload.
- Budget terbatas — cluster 5 node kecil, disk kecil, dan tidak ada engineer storage dedicated.
- Butuh RWX sederhana — beberapa replica Deployment Laravel yang berbagi folder upload/media.
Di sinilah "simple" menjadi kriteria yang sah, bukan alasan: kompleksitas yang tinggi dengan beban kecil hanya akan menyedot waktu maintenance tim yang kecil.
Note
Pembeda paling praktis antara solusi storage: berapa banyak komponen yang harus hidup dan dijaga? Rook-Ceph butuh +10 Pod cluster-wide; OpenEBS simple hanya CSI controller, node agent, dan satu NFS Server Pod per PVC.
#Solusi OpenEBS + NFS
Arsitektur yang kita bangun di series ini terdiri dari dua bagian OpenEBS:
- OpenEBS Local PV — penyimpanan block lokal per-node. Simple dan berperilaku cepat: volume
hostpathditempel langsung ke folder disk node. Hasilnya RWO (satu node), latensi rendah. - OpenEBS Dynamic NFS Provisioner — lapisan NFS di atas Local PV. Setiap PVC mode RWX menghidupkan NFS Server Pod yang menyimpan data di volume Local PV, lalu mengeksposnya via NFSv4 ke semua worker.
Alurnya satu arah, mudah dipahami:
Instalasi keduanya selesai dalam beberapa menit via Helm (episode 4). Tidak ada mesin eksternal, tidak ada replikasi yang harus dirawat, tidak ada licensing.
#Kapan Pakai Ini vs Lainnya
Ringkasan keputusan yang dipakai sepanjang series:
| Kebutuhan | Solusi |
|---|---|
| Lab / small cluster, RWX sederhana | OpenEBS + NFS (series ini) |
| Production RWO database (replikasi) | Longhorn |
| Production serius multi-protocol (RWX+RBD+RGW) | Rook-Ceph |
Panduan praktis:
- OpenEBS + NFS: lab, staging, small non-critical production. Prioritas: waktu setup cepat, footprint kecil.
- Longhorn: data database yang butuh replikasi antar node, UI yang ramah, dan fitur backup sederhana.
- Rook-Ceph: storage mission-critical, volume besar, multi-protocol, atau tim yang punya kapasitas operasional.
Tip
Kalian bukan memilih "yang paling hebat", melainkan "yang paling sesuai dengan beban dan tim". Untuk cluster 5 node dengan aplikasi web sederhana, solusi simple adalah keputusan engineering yang benar — bukan kompromi.
#Penutup
Pada episode 1 ini, kalian telah membangun pembenaran arsitektur:
Inti yang harus dibawa pulang:
- Lab/small cluster menolak kompleksitas Rook-Ceph/Longhorn demi kecepatan & budget.
- OpenEBS Local PV = storage RWO cepat menempel node.
- OpenEBS Dynamic NFS Provisioner = lapisan RWX di atas Local PV.
- Instalasi cepat via Helm; NFS Server Pod per-PVC sebagai titik akses.
- Gunakan ini untuk lab/small non-critical; Longhorn untuk RWO DB; Rook-Ceph untuk produksi serius.
Di episode 2 selanjutnya kita akan membedah arsitektur OpenEBS dan konsep shared: komponen controller, engine Mayastor opsional, macam-macam Local PV (hostpath/LVM/ZFS/rawfile), serta alur akses RWX dari PVC sampai Pod. Sampai jumpa di episode 2!