Study guide
5.3 StorageClasses, Dynamic Provisioning & VolumeBindingModes
Certified Kubernetes Administrator CKA
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: CKA Exam Environment & Cluster Architecture
1.1 CKA Exam Mechanics, Scoring & Remote Terminal Environment 1.2 Kubernetes Control Plane & Worker Node Components 1.3 etcd Architecture, Clustering & Raft Consensus 1.4 Initializing Clusters with Kubeadm 1.5 Highly Available (HA) Control Plane Topologies 1.6 Cluster Lifecycle & Step-by-Step Upgrades 1.7 etcd Snapshot Backup and Restore Procedures
2 Chapter 2: Cluster Extensions, Packaging & RBAC
2.1 Kubernetes TLS Certificates & PKI Infrastructure 2.2 Managing Kubeconfig Files, Users, & Contexts 2.3 Installing Cluster Components with Helm & Kustomize 2.4 Role-Based Access Control (RBAC): Roles & RoleBindings 2.5 ClusterRoles & ClusterRoleBindings 2.6 Custom Resource Definitions (CRDs) & Operators 2.7 Pod Security Standards (PSS) & Admission Controllers
3 Chapter 3: Workloads, Lifecycle & Pod Scheduling
3.1 Pod Lifecycle, Multi-Container Patterns & Init Containers 3.2 Deployments: Rolling Updates, Rollouts & Rollbacks 3.3 DaemonSets & StatefulSets Architecture 3.4 Batch Workloads: Jobs & CronJobs 3.5 Managing ConfigMaps & Sensitive Data with Secrets 3.6 Resource Requests, Limits & Namespace ResourceQuotas 3.7 NodeSelectors, Node Affinity & Anti-Affinity 3.8 Node Taints & Pod Tolerations 3.9 Autoscaling: Horizontal Pod Autoscaler (HPA) & Custom Metrics
4 Chapter 4: Services, Networking & Ingress Architecture
4.1 Kubernetes IP-per-Pod Model & CNI Plugins (Flannel, Calico, Cilium) 4.2 Services Deep Dive: ClusterIP, NodePort, LoadBalancer & EndpointSlices 4.3 Kube-Proxy Service Dataplane: iptables, nftables, IPVS & eBPF 4.4 CoreDNS Configuration, Resolution & Custom Forwarding 4.5 NetworkPolicies: Ingress, Egress & Default-Deny Isolation 4.6 Ingress Architecture, Controllers & Path-Based Routing 4.7 Gateway API: GatewayClass, Gateway, HTTPRoute & Traffic Splitting 4.8 External Traffic Ingress: NodePort, Cloud LoadBalancers & MetalLB
5 Chapter 5: Storage Architecture & Persistent Volumes
5.1 Ephemeral Volumes, EmptyDir, HostPath & Config Volumes 5.2 PersistentVolumes (PV) & PersistentVolumeClaims (PVC) Lifecycle 5.3 StorageClasses, Dynamic Provisioning & VolumeBindingModes 5.4 Storage Access Modes, Reclaim Policies & Volume Expansion 5.5 Container Storage Interface (CSI) Architecture & Drivers 5.6 StatefulSet VolumeClaimTemplates & Persistent Storage Workflows
6 Chapter 6: Advanced Troubleshooting, Monitoring & Maintenance
6.1 Systematic Kubernetes Troubleshooting Methodology 6.2 Node Failure, Kubelet Diagnostics & Systemd Services 6.3 Control Plane Failures, Static Pods & Component Logs 6.4 etcd Troubleshooting, Quorum Loss & Database Defragmentation 6.5 Pod Startup Failures, CrashLoopBackOff & OOMKilled Diagnostics 6.6 Workload Scheduling Failures & Resource Constraint Resolution 6.7 Container & Node Logging Architecture, Journalctl & Fluentd 6.8 Metrics Server, Resource Utilization & Kubectl Top 6.9 Service, Endpoint & Ingress Connectivity Troubleshooting 6.10 Storage Failures: PVC Pending, Mount Failures & Multi-Attach Errors 6.11 NetworkPolicy Isolation & CoreDNS Resolution Diagnostics
5.3 StorageClasses, Dynamic Provisioning & VolumeBindingModes
Key Takeaways Explain This Topic AI
Dynamic volume provisioning automates storage lifecycle management by creating backend storage assets on demand when a PVC is created, eliminating the need for manual PV pre-allocation.
A StorageClass resource encapsulates the provisioner CSI driver, provider-specific parameters (IOPS, disk type, filesystem), reclaimPolicy, and allowVolumeExpansion.
The cluster default StorageClass is designated by the annotation 'storageclass.kubernetes.io/is-default-class: "true"'; claims that omit storageClassName automatically inherit this default.
Setting storageClassName: "" (empty string) in a PVC explicitly disables dynamic provisioning and restricts binding to pre-existing static PVs.
volumeBindingMode: WaitForFirstConsumer delays volume provisioning and binding until a Pod consuming the PVC is scheduled, preventing multi-zone cloud topology conflicts and volume attachment failures.
Last updated: August 2026
5.3 StorageClasses, Dynamic Provisioning & VolumeBindingModes
In enterprise-scale Kubernetes deployments running thousands of microservices across heterogeneous cloud and on-premise environments, relying solely on static PersistentVolume provisioning is operationally unsustainable. Cluster administrators cannot manually create, size, and label individual PVs every time a development team provisions a new database or caching layer. Furthermore, static provisioning frequently results in severe capacity waste, as claims bind to the smallest available PV that satisfies the request—even if that PV is significantly larger than requested.
To establish scalable, self-service infrastructure, Kubernetes introduces Dynamic Provisioning powered by StorageClasses ( storage.k8s.io/v1 ). StorageClasses define storage profiles (e.g., fast-nvme-ssd , replicated-nfs , standard-hdd ) and delegate volume lifecycle operations directly to Container Storage Interface (CSI) drivers.
1. Static vs. Dynamic Provisioning Comparison ============================== STATIC PROVISIONING ==============================
- 1. Admin manually creates AWS EBS disk in AWS Console
- 2. Admin writes and applies PersistentVolume YAML
- 3. Developer creates PVC -> Binds to pre-existing PV
- * Drawbacks: Manual bottleneck, capacity mismatch, non-scalable
- ============================= DYNAMIC PROVISIONING ==============================
- 1. Developer applies PVC referencing StorageClass: fast-ebs
- 2. csi-provisioner intercepts PVC and calls Cloud API directly
- 3. Cloud API provisions exact 20Gi GP3 EBS volume
- 4. csi-provisioner generates PV object and binds it instantly to PVC
- * Benefits: 100% automated, exact capacity sizing, self-service
- Operational Dimension Static Provisioning Dynamic Provisioning
- Provisioning Velocity Slow (Requires administrator action) Instantaneous (Fully automated API call)
- Capacity Sizing Approximate (Claims bind to oversized PVs) Exact (Provisions exact requested gigabytes)
- StorageClass Requirement None or storageClassName: "" Requires defined StorageClass with CSI driver
- Default Reclaim Policy Retain (typically) Delete (Default for dynamically generated PVs)
Topology Awareness Difficult to coordinate across multi-AZ Automated via volumeBindingMode: WaitForFirstConsumer
2. Anatomy of a StorageClass Manifest
A StorageClass is a cluster-scoped object that defines the provisioner driver, backend configuration parameters, mount options, and lifecycle behavior for dynamically allocated volumes. apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: high-performance-ebs
annotations:
- storageclass.kubernetes.io/is-default-class: "true"
- provisioner: ebs.csi.aws.com
- volumeBindingMode: WaitForFirstConsumer
- allowVolumeExpansion: true
- reclaimPolicy: Delete
parameters:
- type: gp3
- iops: "4000"
- throughput: "250"
- encrypted: "true"
- csi.storage.k8s.io/fstype: ext4
mountOptions:
- discard
- noatime
Core StorageClass Fields Explained:
provisioner : The string identifying the CSI plugin responsible for provisioning the storage (e.g., ebs.csi.aws.com , pd.csi.storage.gke.io , disk.csi.azure.com , rook-ceph.rbd.csi.ceph.com , or kubernetes.io/no-provisioner for local volumes).
parameters : Key-value map passed directly to the CSI driver during CreateVolume gRPC calls. Parameters dictate disk performance tier, IOPS, encryption keys, and filesystem formatting.
volumeBindingMode : Controls whether storage provisioning occurs immediately upon PVC creation ( Immediate ) or is postponed until the consuming Pod is placed on a worker node ( WaitForFirstConsumer ).
allowVolumeExpansion : Boolean flag ( true / false ). When true , allows users to resize volumes dynamically by editing the PVC's spec.resources.requests.storage .
reclaimPolicy : Overrides the default reclaim policy for generated PVs ( Delete or Retain ). Defaults to Delete .
mountOptions : Array of Linux kernel mount flags (e.g., noatime , nodiratime , discard , nfsvers=4.1 ) applied when mounting the filesystem on the node.
3. Default StorageClass Evaluation Rules
Kubernetes allows designating a specific StorageClass as the Default StorageClass using the annotation storageclass.kubernetes.io/is-default-class: "true" .
PVC storageClassName Resolution Matrix +-----------------------------------------------------------------------------------------+
- | PVC STORAGECLASS RESOLUTION FLOWCHART |
- | |
- | Does PVC declare 'storageClassName'? |
- | | |
- | +---> YES: Named Class (e.g., storageClassName: "fast-ssd") |
- | | ==> Provisions volume using specified 'fast-ssd' StorageClass. |
- | | |
- | +---> YES: Empty String (storageClassName: "") |
- | | ==> Dynamic provisioning DISABLED. Binds only to pre-existing static PVs. |
- | | |
- | +---> NO: Field Omitted (null) |
- | | |
- | +---> Is there a Default StorageClass annotated in cluster? |
- | | |
- | +---> YES: Mutating webhook injects Default StorageClass name. |
- | | |
- | +---> NO: Dynamic provisioning skipped; PVC seeks static unbound PVs. |
- +-----------------------------------------------------------------------------------------+
Caution
Duplicate Default StorageClasses: If more than one StorageClass is annotated as default, Kubernetes chooses the default with the newest creation timestamp for a PVC that omits storageClassName . This compatibility behavior is not a sound steady state: remove the default annotation from the unintended classes so future claims have an unambiguous policy.
4. Volume Binding Modes: Immediate vs. WaitForFirstConsumer
The volumeBindingMode directive is one of the most critical configuration parameters for multi-zone cloud architectures. +-----------------------------------------------------------------------------------------+
- | IMMEDIATE MODE vs. WAITFORFIRSTCONSUMER MULTI-AZ SCHEDULING |
- | |
- | [IMMEDIATE MODE FAILURE SCENARIO] |
- | 1. Developer creates PVC. |
- | 2. CSI immediately provisions AWS EBS in Availability Zone: us-east-1a. |
- | 3. Developer creates Pod. |
- | 4. Scheduler evaluates Node Affinity / Resources and places Pod on node in us-east-1b. |
- | 5. RESULT: Cloud volume cannot attach cross-AZ! Pod stuck in VolumeZoneConflict. |
- | |
- | [WAITFORFIRSTCONSUMER SUCCESS SCENARIO] |
- | 1. Developer creates PVC -> PVC stays in Pending (No volume provisioned yet). |
- | 2. Developer creates Pod referencing PVC. |
- | 3. kube-scheduler runs filtering/scoring and selects optimal node in us-east-1b. |
- | 4. Scheduler passes node topology constraints to CSI Provisioner. |
- | 5. CSI provisions AWS EBS directly inside us-east-1b. |
- | 6. RESULT: Volume attaches cleanly to the local node without zone conflicts! |
- +-----------------------------------------------------------------------------------------+
- 1. volumeBindingMode: Immediate (Default)
Volume provisioning and binding occur immediately when the PVC is created. Because the storage is allocated before the Pod is scheduled, cloud block storage (such as AWS EBS, Azure Managed Disk, or GCP Persistent Disk) may be provisioned in an Availability Zone where no suitable worker node exists, resulting in unresolvable FailedAttachVolume errors.
2. volumeBindingMode: WaitForFirstConsumer (Best Practice)
Volume provisioning and binding are delayed until a Pod consuming the PVC is evaluated by kube-scheduler . The scheduler incorporates node affinity, taints, tolerations, available CPU/memory, and topology labels ( topology.kubernetes.io/zone ) before selecting a node, guaranteeing that the storage volume is provisioned in the identical availability zone as the scheduled Pod. This mode is recommended for local volumes and topology-constrained multi-zone storage because it lets scheduling participate before binding; verify the provisioner and workload requirements.
- 5. Declarative PVC Consuming Dynamic Storage apiVersion: v1
- kind: PersistentVolumeClaim
metadata:
- name: production-db-claim
- namespace: production
spec:
accessModes:
- ReadWriteOnce
- storageClassName: high-performance-ebs
resources:
requests:
storage: 150Gi
6. Administrative CLI Commands # 1. List all StorageClasses and identify the default class (*marked with (default))
kubectl get sc
# 2. Designate an existing StorageClass as the cluster default
kubectl annotate storageclass high-performance-ebs storageclass.kubernetes.io/is-default-class="true" --overwrite
- # 3. Strip default status from an old StorageClass
- kubectl annotate storageclass standard storageclass.kubernetes.io/is-default-class="false" --overwrite
- # 4. Inspect StorageClass parameters and binding mode
- kubectl describe sc high-performance-ebs