StorageClass

StorageClass adalah template tingkat kluster yang menjelaskan jenis penyimpanan yang dapat dibuat, sehingga kapasitas baru bisa disediakan secara dinamis tanpa membuat PersistentVolume manual satu per satu. Topik ini membahas bidang provisioner dan parameters, pola PVC dinamis dengan storageClassName, perilaku volumeBindingMode dan reclaimPolicy, serta cara class default bekerja. Perbedaan keadaan claim dengan dan tanpa class disimulasikan secara terprogram di akhir topik, sehingga alur provisioning dan binding-nya terlihat utuh.

StorageClass dan provisioner#

Setiap StorageClass menunjuk satu provisioner, yaitu komponen yang mengetahui cara membuat penyimpanan nyata di belakang kluster, misalnya disk pada penyedia awan atau direktori pada host lokal. Provisioner tidak disediakan Kubernetes itu sendiri, melainkan dikirim oleh setiap lingkungan, sehingga minikube menyertakan k8s.io/minikube-hostpath, kind menyertakan provisionernya sendiri, dan kluster produksi menyertakan driver CSI dari penyedia penyimpanannya. StorageClass tidak berada di dalam namespace, sehingga nama classnya terbaca sama dari seluruh namespace di kluster. Manifest berikut mendefinisikan class bernama cepat untuk lab minikube:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: cepat
provisioner: k8s.io/minikube-hostpath
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Bidang parameters memuat penyesuaian khusus provisioner, dan kuncinya ditentukan sepenuhnya oleh provisioner yang bersangkutan:

parameters:
  type: pd-ssd

Contoh parameter di atas mengikuti dokumentasi resmi untuk provisioner disk yang menuntut jenis disk tertentu, sedangkan provisioner pada lab minikube tidak membaca parameter apa pun. Bidang allowVolumeExpansion: true mengizinkan claim yang sudah terikat untuk diperbesar ukurannya, misalnya dari 1 Gi menjadi 2 Gi tanpa membuat volume baru. Perintah kubectl get storageclass menampilkan seluruh class yang tersedia beserta provisioner dan kebijakannya, sehingga nama class untuk manifest baru diambil dari daftar tersebut.

PVC dinamis dengan storageClassName#

PVC yang menyebut sebuah class menjadi pintu masuk provisioning dinamis. Berbeda dengan PVC statis pada topik PV dan PVC yang menunggu PV manual, claim berikut ini memicu provisioner membuat PV seketika:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: arsip-dinamis
spec:
  storageClassName: cepat
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Setelah PV dibuat, claim terikat padanya dan Pod dapat menunjuknya seperti biasa melalui persistentVolumeClaim.claimName. Simulasi berikut mengikuti keadaan dua claim pada kluster yang hanya memiliki class cepat dan tidak menetapkan class default, sehingga perbedaan keadaan keduanya terlihat:

import yaml

with open("storageclass.yaml") as f:
    kelas = yaml.safe_load(f)

print(f"StorageClass {kelas['metadata']['name']}:")
print(f"  provisioner       = {kelas['provisioner']}")
print(f"  reclaimPolicy     = {kelas['reclaimPolicy']}")
print(f"  volumeBindingMode = {kelas['volumeBindingMode']}")

# kluster hanya memiliki class di atas dan tidak menetapkan class default
kelas_ada = {kelas["metadata"]["name"]: kelas["provisioner"]}

def alur(nama, kelas_pvc):
    # mengikuti volumeBindingMode WaitForFirstConsumer pada class cepat
    print(f"PVC {nama} (storageClassName={kelas_pvc or 'tidak diisi'})")
    if kelas_pvc is None or kelas_pvc not in kelas_ada:
        print("  claim dibuat   -> Pending, tidak ada provisioner yang bekerja")
        return
    print("  claim dibuat   -> Pending, menunggu pod pertama yang menggunakannya")
    print("  pod dibuat     -> PV dibuat oleh " + kelas_ada[kelas_pvc])
    print("  PV terikat     -> Bound")

alur("arsip-dinamis", "cepat")
alur("arsip-manual", None)

StorageClass cepat:
  provisioner       = k8s.io/minikube-hostpath
  reclaimPolicy     = Delete
  volumeBindingMode = WaitForFirstConsumer
PVC arsip-dinamis (storageClassName=cepat)
  claim dibuat   -> Pending, menunggu pod pertama yang menggunakannya
  pod dibuat     -> PV dibuat oleh k8s.io/minikube-hostpath
  PV terikat     -> Bound
PVC arsip-manual (storageClassName=tidak diisi)
  claim dibuat   -> Pending, tidak ada provisioner yang bekerja

Claim dengan class bergerak melalui keadaan Pending, provisioning, lalu Bound, sedangkan claim tanpa class tertahan di Pending karena tidak ada provisioner yang mengambil pekerjaannya. Pada kluster yang sesungguhnya, keadaan claim yang menunggu dapat dibedakan dari event-nya, yaitu provisioning saat provisioner bekerja dan WaitForFirstConsumer saat menunggu Pod.

Perintah berikut menuntaskan alur di atas pada lab minikube:

# tidak-dijalankan
# terapkan StorageClass lalu PVC dinamis
kubectl apply -f storageclass.yaml
kubectl apply -f pvc-dinamis.yaml

# periksa keadaan PVC setelah pod pertama dibuat
kubectl get pvc arsip-dinamis

storageclass.storage.k8s.io/cepat created
persistentvolumeclaim/arsip-dinamis created
NAME             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS
arsip-dinamis    Bound    pvc-8f2c9d1a-4b7e-4f3a-9d21-6c1b8a2e4f77   1Gi        RWO            cepat

Nama PV yang berawalan pvc- adalah ciri provisioning dinamis, karena PV tersebut dibuat otomatis dan bukan secara manual oleh pengelola kluster.

volumeBindingMode dan waktu provisioning#

Bidang volumeBindingMode mengatur kapan provisioning dan binding berlangsung. Mode Immediate memicu pembuatan PV begitu claim dibuat, sedangkan mode WaitForFirstConsumer menunda hingga ada Pod pertama yang menggunakan claim tersebut. Mode penundaan ini menghindari masalah penempatan, karena PV yang dibuat terlalu dini bisa mendarat di zona yang berbeda dari zona Node tempat Pod akhirnya dijadwalkan. Perbedaan kedua mode juga terbaca pada keadaan claim, karena mode Immediate yang gagal mencocokkan langsung menampilkan alasan pencocokannya, sedangkan mode WaitForFirstConsumer menampilkan keadaan menunggu yang wajar.

Bidang reclaimPolicy pada class berlaku untuk seluruh PV yang dibuatnya, dan nilainya bisa Delete atau Retain. Class dengan kebijakan Delete membuat penyimpanan sementara yang bersih setelah claim dihapus, sedangkan kebijakan Retain menyisakan PV berstatus Released untuk ditinjau manual sebelum dihapus.

Kesalahan umum#

• PVC tanpa storageClassName pada kluster tanpa class default. Claim tertahan di Pending karena tidak ada provisioner yang bekerja, dan event pada kubectl describe pvc tidak menampilkan percobaan provisioning apa pun. Perbaikannya adalah menyebut nama class secara eksplisit atau menetapkan satu class sebagai default.
• Mengharapkan claim dengan mode WaitForFirstConsumer terikat segera. Claim terlihat Pending lebih lama karena provisioning sengaja ditunda sampai Pod pertama dibuat, dan keadaan ini bukan error. Perbaikannya adalah membuat Pod yang menggunakan claim agar alur provisioning dan binding berjalan.
• Menyalin nama class antara lingkungan tanpa penyesuaian. Manifest yang berjalan di lab bisa menggantung di kluster lain karena provisioner seperti k8s.io/minikube-hostpath tidak ada di sana. Perbaikannya adalah menyesuaikan nama class dengan daftar kubectl get storageclass pada setiap lingkungan.

Class default dan pemilihan class#

Kluster dapat menetapkan satu StorageClass sebagai default melalui anotasi, dan setiap PVC tanpa storageClassName otomatis mewarisi class tersebut:

metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"

Mekanisme ini menjelaskan mengapa banyak tutorial membuat PVC tanpa menyebut class apa pun dan tetap mendapatkan volume, karena lingkungan lab seperti minikube sudah mengangkat class standard sebagai defaultnya. Pemilihan class tetap eksplisit pada manifest aplikasi yang serius, karena nama class mengikat PVC pada karakteristik penyimpanannya, mulai dari kecepatan, replikasi, hingga kebijakan reclaim. Perubahan class default hanya memengaruhi claim yang dibuat setelahnya, sedangkan claim lama tetap mengikuti class saat ia dibuat.

Ringkasan#

• StorageClass adalah template class penyimpanan tingkat kluster yang menunjuk satu provisioner beserta parameters yang ditentukan provisioner tersebut.
• PVC yang menyebut storageClassName memicu provisioning dinamis, sehingga PV baru dibuat otomatis dan terikat pada claim tanpa pekerjaan manual.
• volumeBindingMode menentukan waktu provisioning, dengan WaitForFirstConsumer menunda hingga Pod pertama muncul agar penempatan PV sesuai Node Pod.
• Class default melalui anotasi melayani PVC tanpa class, sedangkan storageClassName pada PVC bersifat tetap setelah claim dibuat.

Referensi#

• Storage Classes — Kubernetes — Dokumentasi konsep StorageClass, mencakup provisioner, parameters, volumeBindingMode, dan class default.
• Persistent Volumes — Kubernetes — Dokumentasi PV dan PVC yang menjadi dasar alur provisioning dinamis.