When you deploy apps on Kubernetes, your Pods are temporary. If a Pod restarts or reschedules, all its data inside the container disappears. Thatβs why we need persistent storage β storage that lives beyond Pod lifecycles.
In Google Kubernetes Engine (GKE), this is handled using:
- StorageClass π§©
- PersistentVolume (PV) πΎ
- PersistentVolumeClaim (PVC) π Letβs go step-by-step π
βοΈ 1. StorageClass β Define Storage Types
A StorageClass defines how storage should be provisioned in your GKE cluster. You can think of it as a βtemplateβ or a βprofileβ for creating disks automatically.
Google provides a few default StorageClasses such as:
Storage Class | Description |
---|---|
standard-rwo | Provides balanced persistent disks (default opti⦠|
When you deploy apps on Kubernetes, your Pods are temporary. If a Pod restarts or reschedules, all its data inside the container disappears. Thatβs why we need persistent storage β storage that lives beyond Pod lifecycles.
In Google Kubernetes Engine (GKE), this is handled using:
- StorageClass π§©
- PersistentVolume (PV) πΎ
- PersistentVolumeClaim (PVC) π Letβs go step-by-step π
βοΈ 1. StorageClass β Define Storage Types
A StorageClass defines how storage should be provisioned in your GKE cluster. You can think of it as a βtemplateβ or a βprofileβ for creating disks automatically.
Google provides a few default StorageClasses such as:
Storage Class | Description |
---|---|
standard-rwo | Provides balanced persistent disks (default option) |
premium-rwo | Provides high-performance SSD disks |
π§ Tip:
If you donβt specify a StorageClass in your PVC, GKE uses the default StorageClass (usually standard-rwo).
πΎ Step 2: Persistent Volume (PV)
A PersistentVolume (PV) is the actual storage resource in your Kubernetes cluster. In GKE, PVs are usually backed by Google Persistent Disks (GCE PD).
πΉ Key Features:
- PVs are cluster-level resources.
- They exist independently of Pods and survive Pod restarts.
- They can be dynamically provisioned β you donβt have to manually create disks.
- Once provisioned, they are bound to a PVC. So, when a Pod uses a PVC, Kubernetes automatically attaches the corresponding PV to that Pod.
π Step 3: Persistent Volume Claim (PVC)
A PersistentVolumeClaim (PVC) is a userβs request for storage. You define:
- Size (e.g., 1Gi, 5Gi)
- Access mode (how Pods can access the volume)
- StorageClass (type of disk) When you create a PVC:
- Kubernetes looks for an existing PV that matches your request.
- If no PV exists, it dynamically creates one using the StorageClass.
- The PVC is then bound to the PV.
π Step 4: Access Modes (Very Important)
Access modes define how many nodes can mount a volume and in what way.
Access Mode | Abbreviation | Description |
---|---|---|
ReadWriteOnce | RWO | Volume can be mounted as read-write by a single node. |
ReadOnlyMany | ROX | Volume can be mounted as read-only by many nodes. |
ReadWriteMany | RWX | Volume can be mounted as read-write by many nodes. |
β οΈ Note:
In GKE, Compute Engine Persistent Disks (the default backend) donβt support ReadWriteMany. For RWX support, youβd use Filestore (NFS) or Cloud Storage FUSE.
π§© Step 5: How It All Connects
Hereβs how all the pieces work together:
ββββββββββββββββββββββββββββββββ
β StorageClass β
β Defines type of disk β
β (standard-rwo, SSD, etc.) β
ββββββββββββββββ¬ββββββββββββββββ
β
βΌ
ββββββββββββββββββββββββββββββββ
β Persistent Volume (PV) β
β Actual GCE Persistent Disk β
β automatically provisioned β
ββββββββββββββββ¬ββββββββββββββββ
β
βΌ
ββββββββββββββββββββββββββββββββ
β Persistent Volume Claim (PVC)β
β Requests storage with size β
β and access mode β
ββββββββββββββββ¬ββββββββββββββββ
β
βΌ
ββββββββββββββββββββββββββββββββ
β Pod β
β Uses PVC to attach the PV β
ββββββββββββββββββββββββββββββββ
π§± Step 6: Resource Scope (Who Owns What?)
Resource Type | Level | Purpose |
---|---|---|
StorageClass | Cluster level | Defines available storage types |
PersistentVolume (PV) | Cluster level | Actual provisioned storage resource |
PersistentVolumeClaim (PVC) | Namespace level | Userβs storage request |
π§° Step 7: Simple Example (YAML)
Hereβs a quick example to tie it all together π
storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: standard-rwo
provisioner: kubernetes.io/gce-pd
parameters:
type: pd-balanced
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
- ReadWriteOnce
storageClassName: standard-rwo
resources:
requests:
storage: 2Gi
pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-pv-demo
spec:
containers:
- name: nginx
image: nginx
volumeMounts:
- name: my-storage
mountPath: /usr/share/nginx/html
volumes:
- name: my-storage
persistentVolumeClaim:
claimName: my-pvc
π§Ή Step 8: Cleanup
kubectl delete pod nginx-pv-demo
kubectl delete pvc my-pvc
kubectl delete storageclass standard-rwo
β Summary
Concept | Description |
---|---|
StorageClass | Defines disk type and provisioning policy |
PersistentVolume (PV) | Actual provisioned storage |
PersistentVolumeClaim (PVC) | Request for storage (size + access mode) |
Pod | Uses the PVC to attach storage |
Access Modes | Control how Pods/nodes can mount the volume |
π‘ In short:
StorageClass decides what kind of storage to use. PVC requests how much storage to use. PV provides the actual storage. Pods use PVC to access that storage β safely and persistently.
π Thanks for reading! If this post added value, a like β€οΈ, follow, or share would encourage me to keep creating more content.
β Latchu | Senior DevOps & Cloud Engineer
βοΈ AWS | GCP | βΈοΈ Kubernetes | π Security | β‘ Automation π Sharing hands-on guides, best practices & real-world cloud solutions