Dynamic Provisioning #

Dynamic provisioning menghilangkan kebutuhan admin untuk membuat PersistentVolume secara manual setiap kali developer membutuhkan storage baru. Saat PVC dibuat dan tidak ada PV yang cocok, Kubernetes memanggil provisioner yang dikonfigurasi di StorageClass untuk membuat PV baru secara otomatis. Ini bukan hanya kenyamanan — ini adalah prerequisite untuk cluster yang bisa di-scale dan dikelola secara efisien.

Alur Dynamic Provisioning #

Developer membuat PVC:
  storageClassName: standard-ssd
  storage: 20Gi
  accessModes: ReadWriteOnce
          │
          ▼
Kubernetes cari PV yang cocok
  → Tidak ada PV Available yang sesuai
          │
          ▼
Kubernetes melihat StorageClass "standard-ssd"
  → provisioner: ebs.csi.aws.com
  → parameters: { type: gp3, iops: "3000" }
          │
          ▼
API Server kirim request ke CSI driver (ebs.csi.aws.com)
  CreateVolume(size=20Gi, parameters={type:gp3, iops:3000})
          │
          ▼
CSI driver memanggil AWS API
  → ec2.CreateVolume(Size=20, VolumeType=gp3, Iops=3000)
  → AWS membuat EBS volume vol-0a1b2c3d...
          │
          ▼
CSI driver melaporkan ke Kubernetes
  → "Volume created: vol-0a1b2c3d, size 20Gi"
          │
          ▼
Kubernetes membuat PV baru secara otomatis:
  name: pvc-abc123-def456-...
  capacity: 20Gi
  csi.volumeHandle: vol-0a1b2c3d...
          │
          ▼
PVC di-bind ke PV baru → PVC status: Bound
          │
          ▼
Pod bisa menggunakan PVC

CSI Driver Architecture #

CSI (Container Storage Interface) adalah standar yang mendefinisikan bagaimana Kubernetes berkomunikasi dengan storage backend. Setiap CSI driver terdiri dari beberapa komponen:

Komponen CSI Driver:

1. External Provisioner (Deployment)
   → Watch API Server untuk PVC baru
   → Panggil CSI CreateVolume saat PVC butuh PV baru
   → Buat PV object di Kubernetes setelah volume dibuat

2. External Attacher (Deployment)
   → Watch VolumeAttachment objects
   → Panggil CSI ControllerPublishVolume untuk attach volume ke node
   → Ini yang membuat cloud disk "attach" ke EC2/VM instance

3. Node Plugin (DaemonSet)
   → Berjalan di setiap node
   → Panggil CSI NodeStageVolume dan NodePublishVolume
   → Mount volume ke filesystem Pod di node tersebut

4. CSI Driver Pod (DaemonSet)
   → Socket /var/lib/kubelet/plugins/<driver-name>/csi.sock
   → Kubelet berkomunikasi dengan driver via socket ini

# Lihat komponen CSI driver yang ter-install
kubectl get pods -n kube-system | grep csi

# Untuk AWS EBS CSI driver:
# ebs-csi-controller-xxx  → External Provisioner + Attacher
# ebs-csi-node-xxx        → Node Plugin (DaemonSet)

Instalasi CSI Driver #

CSI driver umumnya di-install via Helm atau manifest:

# AWS EBS CSI Driver
helm repo add aws-ebs-csi-driver https://kubernetes-sigs.github.io/aws-ebs-csi-driver
helm install aws-ebs-csi-driver \
  aws-ebs-csi-driver/aws-ebs-csi-driver \
  --namespace kube-system \
  --set controller.serviceAccount.annotations."eks\.amazonaws\.com/role-arn"=arn:aws:iam::ACCOUNT_ID:role/AmazonEKS_EBS_CSI_DriverRole

# GKE sudah include CSI driver — tinggal enable
gcloud container clusters update CLUSTER_NAME \
  --update-addons=GcePersistentDiskCsiDriver=ENABLED

# Azure AKS — CSI driver aktif secara default untuk cluster baru

StorageClass untuk Dynamic Provisioning #

# StorageClass untuk dynamic provisioning di AWS EKS
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
  annotations:
    storageclass.kubernetes.io/is-default-class: "false"
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer    # penting untuk multi-AZ
reclaimPolicy: Delete
allowVolumeExpansion: true
parameters:
  type: gp3
  iops: "3000"
  throughput: "125"
  encrypted: "true"
  # untuk enkripsi dengan KMS key tertentu:
  # kmsKeyId: "arn:aws:kms:ap-southeast-1:123456789:key/abc123"

Dynamic Provisioning On-Premise #

Di environment on-premise tanpa cloud provider, dynamic provisioning bisa dilakukan dengan storage solution seperti:

NFS dengan nfs-subdir-external-provisioner:

# StorageClass untuk NFS
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-dynamic
provisioner: cluster.local/nfs-subdir-external-provisioner
reclaimPolicy: Delete
parameters:
  archiveOnDelete: "false"    # hapus data saat PVC dihapus
  pathPattern: "${.PVC.namespace}-${.PVC.name}"  # path pattern di NFS

Longhorn (distributed block storage):

# StorageClass untuk Longhorn
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn
provisioner: driver.longhorn.io
parameters:
  numberOfReplicas: "3"        # jumlah replica data
  staleReplicaTimeout: "2880"
  fromBackup: ""
  diskSelector: ""
  nodeSelector: ""
allowVolumeExpansion: true

OpenEBS (multiple storage engines):

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: openebs-hostpath
provisioner: openebs.io/local
reclaimPolicy: Delete
parameters:
  basePath: "/var/openebs/local"
volumeBindingMode: WaitForFirstConsumer

Troubleshooting Dynamic Provisioning #

PVC Stuck di Pending #

# Step 1: Lihat events PVC
kubectl describe pvc <pvc-name>

# Pesan umum dan artinya:

"waiting for a volume to be created, either by external provisioner
 or manually created by system administrator"
  → Provisioner tidak merespons
  → Cek apakah CSI driver berjalan

"failed to provision volume: RPC error: ... AccessDenied"
  → CSI driver tidak punya permission untuk membuat volume
  → Cek IAM role / service account permission

"no StorageClass found for PVC"
  → storageClassName di PVC tidak ada
  → Cek nama StorageClass dengan: kubectl get storageclass

# Step 2: Cek status CSI driver
kubectl get pods -n kube-system | grep csi
kubectl logs -n kube-system deployment/ebs-csi-controller -c csi-provisioner

# Step 3: Verifikasi StorageClass
kubectl describe storageclass <storageclass-name>
# Perhatikan: apakah Provisioner-nya sesuai dengan CSI driver yang ter-install?

Volume Tidak Bisa Di-attach ke Node #

# Lihat events Pod
kubectl describe pod <pod-name>

# Pesan: "AttachVolume.Attach failed for volume ... Access denied"
# → Masalah permission IAM/SA untuk CSI attacher

# Pesan: "Multi-Attach error for volume ... Volume is already attached"
# → Volume masih attached ke node lain (sering terjadi setelah node failure)
# → Tunggu timeout (biasanya ~6 menit) atau force detach secara manual via cloud console

Ringkasan #

  • Dynamic provisioning menghilangkan bottleneck admin — PV dibuat otomatis saat PVC tidak menemukan PV yang cocok; tidak perlu intervensi manual untuk setiap storage request.
  • CSI driver terdiri dari tiga komponen — external provisioner (buat PV), external attacher (attach ke node), dan node plugin (mount ke Pod); ketiganya perlu berjalan untuk dynamic provisioning bekerja.
  • WaitForFirstConsumer wajib di multi-AZ — mencegah PV di-provision di zone yang salah sebelum diketahui zone mana Pod akan berjalan.
  • Tiap cloud provider punya CSI driver sendiri — EKS butuh aws-ebs-csi-driver, GKE dan AKS sudah include driver-nya; pastikan ter-install dan punya permission yang benar.
  • On-premise menggunakan Longhorn atau NFS provisioner — untuk cluster yang tidak di cloud, Longhorn memberikan distributed storage yang solid dengan replika; NFS lebih sederhana tapi ada limitasi performa.
  • Cek log CSI driver untuk diagnosis — kubectl logs deployment/ebs-csi-controller -c csi-provisioner adalah titik mulai troubleshooting provisioning yang gagal.

← Sebelumnya: Backup & Restore   Berikutnya: Anti-Pattern Storage →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact