Latchu@DevOps

Posted on Oct 6

Part-109: 🧱Google Kubernetes Engine (GKE) Storage — Simplified Explanation

#kubernetes #googlecloud #devops #cloud

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

DEV Community