Persistent Volume dan Persistent Volume Claim di Kubernetes: Panduan Lengkap Penyimpanan Data yang Tahan Banting

Pelajari cara kerja Persistent Volume dan PVC di Kubernetes agar data Pod tetap aman meski Pod dihapus atau dipindah node.

Bayangkan Anda menjalankan database MySQL di dalam Pod Kubernetes, lalu suatu hari Pod itu crash dan Kubernetes membuat Pod baru untuk menggantikannya. Pertanyaan pentingnya: apakah data yang sudah Anda simpan sebelumnya masih ada?

Jawabannya tergantung pada bagaimana Anda mengatur storage-nya. Secara default, container di Kubernetes bersifat ephemeral alias sementara. Semua yang ditulis ke filesystem container akan hilang begitu container tersebut berhenti atau dijadwalkan ulang ke node lain. Untuk aplikasi stateless seperti web server sederhana, ini bukan masalah. Tapi untuk aplikasi stateful seperti database, message queue, atau sistem file bersama, kehilangan data adalah bencana.

Di sinilah Persistent Volume (PV) dan Persistent Volume Claim (PVC) berperan. Kedua objek ini adalah fondasi dari sistem penyimpanan Kubernetes yang memungkinkan data tetap ada meskipun Pod dihapus, di-restart, atau dipindahkan ke node lain. Bagi siapa pun yang mengelola cluster Kubernetes untuk workload produksi—baik itu database, aplikasi enterprise, maupun sistem monitoring—memahami PV dan PVC bukan sekadar nice-to-have, tapi kebutuhan mutlak.

Artikel ini akan membahas tuntas konsep PV dan PVC, mulai dari teori dasar, cara kerja, contoh manifest YAML yang bisa langsung dipakai, sampai kesalahan umum yang sering terjadi di lapangan.

Pembahasan Utama

Apa Itu Persistent Volume (PV)?

Persistent Volume adalah representasi dari sepotong ruang penyimpanan fisik atau virtual di dalam cluster Kubernetes. PV bisa disediakan oleh administrator cluster secara manual (static provisioning) atau dibuat otomatis oleh sistem lewat StorageClass (dynamic provisioning).

Yang membedakan PV dari volume biasa (seperti emptyDir) adalah lifecycle-nya. PV memiliki siklus hidup yang terpisah dari Pod mana pun yang menggunakannya. Artinya, meski Pod yang memakai PV dihapus, PV tersebut—beserta datanya—tetap ada di cluster sampai ada tindakan eksplisit untuk menghapusnya.

Secara analogi, PV itu seperti hard disk eksternal yang berdiri sendiri di gudang penyimpanan. Hard disk ini bisa dicolokkan ke komputer mana pun (Pod mana pun), dan ketika komputer itu dimatikan, hard disk tetap menyimpan semua datanya dengan aman di gudang.

Apa Itu Persistent Volume Claim (PVC)?

Jika PV adalah “penyedia” ruang penyimpanan, maka PVC adalah “permintaan” dari sisi pengguna. PVC adalah cara Pod meminta storage dengan spesifikasi tertentu—misalnya kapasitas 10Gi, mode akses ReadWriteOnce, dan kelas penyimpanan tertentu—tanpa perlu tahu detail teknis di baliknya (apakah itu disk cloud, NFS, atau storage lokal).

Ketika PVC dibuat, Kubernetes akan mencari PV yang cocok dengan permintaan tersebut dan mengikatnya (binding). Jika tidak ada PV yang cocok secara statis tapi ada StorageClass yang mendukung provisioning dinamis, Kubernetes akan membuatkan PV baru secara otomatis.

Analoginya, PVC itu seperti formulir permintaan ruang penyimpanan yang Anda isi ke bagian gudang. Anda cukup bilang “saya butuh 10Gi, akses baca-tulis dari satu node”, dan gudang akan mencarikan atau menyediakan unit penyimpanan yang sesuai—Anda tidak perlu tahu itu disk fisik nomor berapa.

Hubungan PV, PVC, dan Pod

Alur kerja PV dan PVC secara sederhana adalah sebagai berikut:

Administrator menyediakan PV (atau StorageClass untuk provisioning dinamis)
Pengguna membuat PVC yang meminta storage dengan spesifikasi tertentu
Kubernetes mengikat (bind) PVC ke PV yang sesuai
Pod mereferensikan PVC (bukan PV secara langsung) di dalam volumes
Ketika Pod dihapus, PVC dan PV tetap ada—data tidak hilang
Pod baru yang mereferensikan PVC yang sama akan mendapatkan data yang persis sama

Poin krusial di sini: Pod tidak pernah berinteraksi langsung dengan PV. Pod selalu berbicara dengan PVC, dan PVC-lah yang menjembatani ke PV. Desain ini membuat konfigurasi Pod tetap portable—Anda bisa memakai manifest Pod yang sama di cluster berbeda tanpa mengubah detail storage backend.

StorageClass: Otomatisasi Penyediaan Storage

Di lingkungan produksi, membuat PV secara manual satu per satu sangat tidak efisien. Di sinilah StorageClass masuk. StorageClass mendefinisikan “provisioner” (driver CSI yang berkomunikasi dengan backend storage seperti AWS EBS, GCP Persistent Disk, atau Ceph), parameter performa, serta kebijakan reclaim.

Saat PVC merujuk pada sebuah StorageClass, Kubernetes secara otomatis membuat PV baru sesuai kebutuhan—tanpa administrator perlu membuat PV manual terlebih dahulu. Inilah yang disebut dynamic provisioning, dan menjadi pendekatan standar di sebagian besar cluster produksi modern.

Mode Akses (Access Modes)

Setiap PV dan PVC memiliki mode akses yang menentukan bagaimana volume bisa di-mount:

ReadWriteOnce (RWO) — volume bisa di-mount baca-tulis oleh satu node saja (semua Pod di node tersebut tetap bisa mengaksesnya)
ReadOnlyMany (ROX) — volume bisa di-mount hanya-baca oleh banyak node sekaligus
ReadWriteMany (RWX) — volume bisa di-mount baca-tulis oleh banyak node sekaligus (biasanya butuh backend seperti NFS atau CephFS)
ReadWriteOncePod (RWOP) — mode terbaru yang membatasi akses baca-tulis hanya untuk satu Pod tunggal di seluruh cluster, lebih ketat dibanding RWO. Kubernetes saat ini merekomendasikan RWOP untuk workload single-writer di produksi, meski memerlukan dukungan CSI driver

Tidak semua backend storage mendukung semua mode akses. Storage block seperti disk cloud (EBS, Persistent Disk) umumnya hanya mendukung RWO, sedangkan NFS dan CephFS mendukung RWX.

Kebijakan Reclaim (Reclaim Policy)

Reclaim policy menentukan apa yang terjadi pada PV setelah PVC yang mengikatnya dihapus:

Retain — PV dan datanya tetap ada meski PVC dihapus. Status PV berubah menjadi “Released” dan administrator harus menangani secara manual (hapus data atau gunakan ulang). Ini pilihan paling aman untuk data penting
Delete — PV dan storage fisik di baliknya otomatis dihapus saat PVC dihapus. Ini default untuk PV yang dibuat secara dinamis lewat StorageClass, dan cukup berbahaya jika tidak disadari
Recycle (deprecated) — dulu melakukan scrub data dasar (rm -rf) agar volume bisa dipakai ulang, namun pendekatan ini tidak lagi direkomendasikan; provisioning dinamis adalah penggantinya

Poin penting: jika Anda menggunakan StorageClass default tanpa mengecek reclaim policy-nya, ada risiko data terhapus otomatis tanpa disadari saat PVC dihapus. Untuk data kritikal seperti database produksi, selalu pastikan reclaim policy diset ke Retain.

Materi Praktis

Contoh Manifest: StorageClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

Contoh Manifest: Persistent Volume (Static Provisioning)

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-data-pv
  labels:
    type: nfs
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: manual
  nfs:
    server: 192.168.1.100
    path: /exports/data

Contoh Manifest: Persistent Volume Claim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-data-claim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast-ssd
  resources:
    requests:
      storage: 5Gi

Contoh Manifest: Pod yang Menggunakan PVC

apiVersion: v1
kind: Pod
metadata:
  name: mysql-db
spec:
  containers:
    - name: mysql
      image: mysql:8
      env:
        - name: MYSQL_ROOT_PASSWORD
          value: "changeme"
      volumeMounts:
        - mountPath: /var/lib/mysql
          name: mysql-storage
  volumes:
    - name: mysql-storage
      persistentVolumeClaim:
        claimName: mysql-data-claim

Studi Kasus: Data Bertahan Setelah Pod Dihapus

Berikut skenario sederhana yang membuktikan konsep ini bekerja:

Buat PVC mysql-data-claim seperti contoh di atas
Deploy Pod mysql-db yang mereferensikan PVC tersebut
Masuk ke dalam Pod, buat sebuah database dan tabel dengan beberapa data dummy
Hapus Pod dengan kubectl delete pod mysql-db
Deploy ulang Pod yang sama (dengan manifest identik)
Masuk kembali ke Pod baru, cek isi database

Hasilnya: database dan data yang dibuat sebelumnya tetap ada, karena Pod baru terhubung ke PVC yang sama, yang tetap terikat ke PV yang menyimpan data secara fisik. Inilah inti dari mengapa PV dan PVC menjadi fondasi wajib untuk aplikasi stateful di Kubernetes.

Contoh Manifest: StatefulSet dengan volumeClaimTemplates

Untuk workload database bereplika seperti PostgreSQL cluster, setiap replika idealnya punya PVC sendiri yang dibuat otomatis. Inilah gunanya volumeClaimTemplates pada StatefulSet:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres
  replicas: 3
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
        - name: postgres
          image: postgres:16
          env:
            - name: POSTGRES_PASSWORD
              value: "changeme"
          volumeMounts:
            - mountPath: /var/lib/postgresql/data
              name: data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: fast-ssd
        resources:
          requests:
            storage: 10Gi

Dengan pendekatan ini, setiap Pod di StatefulSet (misalnya postgres-0, postgres-1, postgres-2) otomatis mendapat PVC-nya sendiri dengan nama seperti data-postgres-0. Jika salah satu Pod dihapus dan dibuat ulang, Kubernetes akan mencocokkannya kembali dengan PVC yang sama berdasarkan nama, sehingga data tiap replika tetap konsisten dan tidak tertukar.

Tutorial Step-by-Step

Berikut langkah lengkap menerapkan Persistent Volume dan PVC dari nol:

Langkah 1 — Siapkan StorageClass (jika belum ada default) Sebagian besar cluster cloud (GKE, EKS, AKS) sudah memiliki StorageClass default. Cek dengan kubectl get storageclass. Jika belum ada, buat sesuai contoh manifest StorageClass di atas.

Langkah 2 — Buat PVC Simpan manifest PVC ke file pvc.yaml, lalu jalankan:

kubectl apply -f pvc.yaml

Langkah 3 — Verifikasi status PVC

kubectl get pvc

Pastikan statusnya Bound. Jika masih Pending, cek apakah StorageClass tersedia dan provisioner berjalan normal.

Langkah 4 — Deploy Pod atau StatefulSet yang mereferensikan PVC Untuk workload database yang butuh replika, gunakan StatefulSet dengan volumeClaimTemplates agar setiap replika otomatis mendapat PVC sendiri.

Langkah 5 — Uji ketahanan data Hapus Pod, tunggu Kubernetes membuat Pod baru (atau buat ulang manual), lalu verifikasi data masih ada di lokasi mount yang sama.

Langkah 6 — Atur reclaim policy sesuai kebutuhan Untuk data produksi, pastikan persistentVolumeReclaimPolicy diset Retain, bukan Delete, agar data tidak otomatis terhapus saat PVC dihapus secara tidak sengaja.

Kesalahan yang Sering Terjadi

1. Menggunakan reclaim policy default (Delete) untuk data penting Penyebab: tidak menyadari bahwa StorageClass dinamis defaultnya Delete. Dampak: data hilang permanen begitu PVC terhapus, misalnya saat StatefulSet di-uninstall. Solusi: eksplisit set reclaimPolicy: Retain pada StorageClass atau PV untuk data kritikal.

2. Salah memilih access mode Penyebab: memakai ReadWriteMany pada backend storage block (seperti EBS) yang sebenarnya hanya mendukung ReadWriteOnce. Dampak: PVC gagal bind, Pod stuck di status Pending. Solusi: cek dokumentasi provisioner storage sebelum menentukan access mode.

3. Lupa menetapkan ukuran storage yang realistis Penyebab: menetapkan kapasitas terlalu kecil di awal tanpa mempertimbangkan pertumbuhan data. Dampak: aplikasi kehabisan ruang disk mendadak. Solusi: aktifkan allowVolumeExpansion: true pada StorageClass agar PVC bisa diperbesar tanpa migrasi data.

4. Menghapus namespace tanpa sadar ikut menghapus PVC Penyebab: kubectl delete namespace menghapus semua resource di dalamnya, termasuk PVC. Dampak: jika reclaim policy Delete, data ikut hilang. Solusi: backup data penting sebelum operasi penghapusan namespace, dan gunakan reclaim policy Retain sebagai lapisan pengaman tambahan.

5. Tidak memantau status binding PVC Penyebab: PVC dibuat tapi tidak ada PV atau provisioner yang cocok, sehingga PVC menggantung di status Pending tanpa terdeteksi. Dampak: Pod yang bergantung pada PVC tersebut juga tidak pernah berjalan. Solusi: pantau status PVC secara rutin, terutama di pipeline CI/CD, agar kegagalan binding cepat terdeteksi.

Tips dan Rekomendasi

Selalu gunakan StatefulSet dengan volumeClaimTemplates untuk workload database bereplika, bukan Deployment biasa
Set volumeBindingMode: WaitForFirstConsumer pada StorageClass agar PV baru dibuat di zona yang sama dengan node tempat Pod dijadwalkan—ini penting di cluster multi-zona
Untuk workload single-writer sensitif seperti WAL database, pertimbangkan access mode ReadWriteOncePod agar tidak ada risiko dua Pod menulis ke volume yang sama secara bersamaan
Lakukan monitoring kapasitas PVC secara berkala agar tidak kehabisan ruang tanpa peringatan
Dokumentasikan reclaim policy setiap StorageClass yang dipakai tim, supaya semua anggota tim paham risiko sebelum menghapus resource

Kesimpulan

Persistent Volume dan Persistent Volume Claim adalah dua objek inti yang membuat Kubernetes mampu menjalankan aplikasi stateful dengan andal. PV menyediakan abstraksi storage fisik yang lifecycle-nya independen dari Pod, sedangkan PVC menjadi jembatan permintaan storage dari sisi pengguna tanpa perlu tahu detail infrastruktur di baliknya.

Poin-poin penting yang perlu diingat:

Data di PV tetap ada meski Pod dihapus atau dijadwalkan ulang ke node lain
Pod selalu berinteraksi dengan PVC, tidak pernah langsung dengan PV
StorageClass memungkinkan provisioning storage otomatis (dynamic provisioning)
Reclaim policy Retain adalah pilihan aman untuk data kritikal, sementara Delete berisiko menghapus data secara permanen
Pemilihan access mode yang tepat (RWO, ROX, RWX, atau RWOP) harus disesuaikan dengan kebutuhan aplikasi dan dukungan backend storage

Dengan memahami dan menerapkan konsep ini dengan benar, Anda bisa membangun infrastruktur Kubernetes yang tangguh untuk database, message queue, dan aplikasi stateful lainnya—tanpa was-was data hilang setiap kali Pod di-restart.

Bagaimana pengalaman Anda mengelola storage di Kubernetes? Pernah mengalami insiden data hilang karena reclaim policy yang salah? Bagikan cerita dan pertanyaan Anda di kolom komentar di bawah ini!

Frequently Asked Questions (FAQ)

Pertanyaan: Apa perbedaan utama antara Persistent Volume dan Persistent Volume Claim? Jawaban: Persistent Volume adalah sumber daya storage aktual di cluster, sedangkan Persistent Volume Claim adalah permintaan storage dari pengguna. PV disediakan oleh administrator atau sistem, PVC dibuat oleh pengguna yang membutuhkan storage.

Pertanyaan: Apakah data di Persistent Volume otomatis hilang saat Pod dihapus? Jawaban: Tidak. Data di PV tetap ada meski Pod dihapus, karena lifecycle PV terpisah dari Pod. Data baru hilang jika PVC dihapus dan reclaim policy-nya diset ke Delete.

Pertanyaan: Kapan sebaiknya menggunakan StorageClass dibanding membuat PV manual? Jawaban: StorageClass sebaiknya dipakai di hampir semua kasus produksi karena memungkinkan provisioning storage otomatis. PV manual (static provisioning) hanya relevan untuk skenario khusus, misalnya menghubungkan ke storage NFS yang sudah ada sebelumnya.

Pertanyaan: Apa itu ReadWriteOncePod dan kenapa direkomendasikan? Jawaban: ReadWriteOncePod adalah access mode yang membatasi volume hanya bisa ditulis oleh satu Pod di seluruh cluster, lebih ketat dari ReadWriteOnce. Kubernetes merekomendasikannya untuk workload single-writer produksi guna mencegah risiko penulisan ganda yang tidak disengaja.

Pertanyaan: Bagaimana cara mencegah data hilang saat PVC terhapus tanpa sengaja? Jawaban: Pastikan reclaim policy PV atau StorageClass diset ke Retain, bukan Delete. Dengan begitu, PV dan datanya tetap ada meski PVC dihapus, dan bisa dipulihkan secara manual oleh administrator.

Sudah paham cara kerja Persistent Volume dan PVC di Kubernetes? Yuk diskusikan di kolom komentar

ceritakan pengalaman Anda mengelola storage di cluster, atau tanyakan hal yang masih membingungkan! Jangan lupa bagikan artikel ini ke rekan tim DevOps atau sysadmin Anda yang sedang belajar Kubernetes, dan jelajahi juga artikel-artikel lain seputar Kubernetes, Cloud Computing, dan Infrastruktur IT di blog ini. Ikuti terus update konten terbaru seputar dunia teknologi dan server administration!

Terkait

You may have missed

Kontribusi & Donasi...