Ephemeral vs Persistent Storage #
Storage di Kubernetes dibagi menjadi dua kategori fundamental yang punya filosofi berbeda: ephemeral dan persistent. Memilih yang salah untuk sebuah workload bisa berarti kehilangan data saat Pod restart, atau sebaliknya, membayar overhead pengelolaan storage yang tidak perlu. Artikel ini membangun mental model yang benar sebelum masuk ke detail teknis PersistentVolume, PVC, dan StorageClass.
Sifat Dasar Container Storage #
Sebelum bicara soal ephemeral vs persistent, perlu dipahami satu fakta dasar: filesystem container bersifat sementara secara default. Ketika sebuah container dihapus dan dibuat ulang — apakah karena crash, rolling update, atau scale down — semua perubahan yang dibuat di dalam filesystem container hilang. Container baru dimulai dari kondisi yang bersih seperti image aslinya.
Siklus hidup filesystem container:
Container dibuat dari image nginx:1.25
└── Filesystem awal: persis seperti image
Aplikasi berjalan, menulis file:
└── /var/log/nginx/access.log ← file baru
└── /tmp/cache/ ← direktori baru
Container di-restart (crash recovery, rolling update, dll):
└── Container baru dimulai dari image yang bersih
└── /var/log/nginx/access.log ← HILANG
└── /tmp/cache/ ← HILANG
Ini bukan bug — ini adalah fitur yang mendukung immutable infrastructure. Tapi tidak semua aplikasi bisa hidup dengan sifat ini.
Ephemeral Storage #
Ephemeral storage adalah storage yang hidupnya terikat pada Pod — ketika Pod mati atau dipindah ke node lain, data ikut hilang.
emptyDir #
Volume paling sederhana di Kubernetes. Kubernetes membuat direktori kosong di node saat Pod dimulai dan menghapusnya saat Pod dihapus.
spec:
volumes:
- name: cache-vol
emptyDir: {} # direktori biasa di filesystem node
- name: cache-mem # atau di memory (tmpfs) — lebih cepat
emptyDir:
medium: Memory
sizeLimit: 256Mi # batasi penggunaan memory
containers:
- name: app
volumeMounts:
- name: cache-vol
mountPath: /tmp/cache
emptyDir berguna untuk:
- Cache yang boleh dibuang saat Pod restart
- Temporary workspace antar container dalam Pod (sidecar pattern)
- Scratch space untuk processing data besar yang tidak perlu disimpan
configMap dan secret #
Secara teknis ini juga ephemeral — konfigurasi di-mount sebagai file tapi tidak menyimpan state aplikasi:
volumes:
- name: config
configMap:
name: app-config
- name: creds
secret:
secretName: app-secret
Persistent Storage #
Persistent storage hidupnya independen dari Pod. Data tetap ada meskipun Pod mati, dipindah ke node lain, atau bahkan dihapus. Di Kubernetes, persistent storage dikelola melalui tiga resource: PersistentVolume (PV), PersistentVolumeClaim (PVC), dan StorageClass.
Hubungan antara ketiganya:
StorageClass → "resep" cara membuat storage
PersistentVolume → representasi storage yang sudah ada
PersistentVolumeClaim → permintaan storage dari Pod
Pod → PVC → PV → storage fisik (disk cloud, NFS, dll)
Mekanisme ini memisahkan detail infrastruktur storage dari definisi aplikasi — developer menulis PVC tanpa perlu tahu di mana storage fisiknya berada.
Kapan Menggunakan Masing-masing #
Gunakan ephemeral storage (emptyDir) jika:
✓ Data adalah cache yang bisa di-regenerate
✓ Data adalah temporary workspace atau intermediate result
✓ Data hanya perlu dibagi antar container dalam Pod yang sama
✓ Aplikasi stateless yang tidak menyimpan state di disk
Gunakan persistent storage (PVC) jika:
✓ Data harus bertahan meskipun Pod restart atau dipindah
✓ Database atau storage engine (PostgreSQL, Redis, Elasticsearch)
✓ File yang di-upload user
✓ State aplikasi yang tidak bisa di-regenerate
✓ Shared storage yang perlu diakses oleh beberapa Pod
Gunakan layanan storage eksternal jika:
✓ Database relasional dengan kebutuhan ketersediaan tinggi
(pertimbangkan RDS, Cloud SQL daripada mengelola sendiri)
✓ Object storage untuk file besar (S3, GCS, Azure Blob)
✓ Tim tidak punya keahlian mengelola stateful workload di Kubernetes
Access Mode #
Ketika menggunakan persistent storage, kamu perlu mendeklarasikan bagaimana volume tersebut diakses — apakah hanya satu Pod atau banyak Pod, apakah read-write atau read-only:
ReadWriteOnce (RWO):
→ Hanya satu node yang bisa mount volume ini sebagai read-write
→ Mode yang paling umum dan didukung hampir semua storage backend
→ Cocok untuk database, state per-Pod
ReadOnlyMany (ROX):
→ Banyak node bisa mount sebagai read-only bersamaan
→ Jarang digunakan; untuk distribusi file konfigurasi statis
ReadWriteMany (RWX):
→ Banyak node bisa mount sebagai read-write bersamaan
→ Butuh storage backend yang mendukung: NFS, CephFS, Azure Files
→ Untuk shared filesystem yang diakses banyak Pod sekaligus
ReadWriteOncePod (RWOP): ← tambahan di Kubernetes 1.22+
→ Hanya satu Pod (bukan node) yang bisa mount
→ Jaminan lebih ketat dari RWO
Ephemeral Volume yang Bersifat “Semi-Persistent” #
Ada satu kategori yang berada di tengah: generic ephemeral volume. Ini adalah volume yang dibuat dan dihapus bersama Pod, tapi storage-nya bisa berupa disk cloud yang lebih berperforma dari emptyDir biasa.
spec:
volumes:
- name: scratch
ephemeral:
volumeClaimTemplate:
spec:
accessModes: ["ReadWriteOnce"]
storageClassName: "fast-ssd"
resources:
requests:
storage: 10Gi
# PVC untuk volume ini otomatis dibuat dan dihapus bersama Pod
Berguna untuk batch job yang butuh storage berperforma tinggi selama processing, tapi tidak perlu menyimpan hasilnya setelah selesai.
Ringkasan #
- Filesystem container bersifat sementara secara default — data yang ditulis langsung ke container hilang saat container restart; ini adalah perilaku yang disengaja.
- emptyDir untuk data sementara dalam Pod — hidup selama Pod hidup; berguna untuk cache, temp workspace, dan berbagi file antar container dalam Pod.
- PVC untuk data yang harus bertahan — independen dari lifecycle Pod; database, file upload, dan semua state yang tidak boleh hilang butuh persistent storage.
- Tiga resource persistent storage — StorageClass (resep), PersistentVolume (storage yang ada), PersistentVolumeClaim (permintaan dari Pod); ketiganya bekerja bersama.
- Access mode menentukan pola akses — RWO untuk sebagian besar kasus (satu node), RWX hanya jika memang butuh shared filesystem dan storage backend mendukungnya.
- Pertimbangkan managed service untuk database — mengelola stateful workload di Kubernetes kompleks; untuk database kritikal, layanan terkelola seperti RDS sering lebih pragmatis.