BLOG11a: Storage Reclaim Policy

BLOG 53: Storage Reclaim Policy

DEMO 1 — Understanding reclaimPolicy (Retain vs Delete vs Recycle)

This demo shows what Kubernetes does with a PV after a PVC is deleted.

Reclaim policy = “What should Kubernetes do with this volume when the claim goes away?”

---

Scenario

You create:

• 1 PV (2Gi)

• 1 PVC that uses it

• A pod writes data

• You delete the PVC

• Watch how reclaim policy changes the fate of your data

We show Delete, Retain, and Recycle (legacy, but GREAT for demo).

---

1. PV with Retain

Data survives even after PVC is deleted — like a ghost lingering 👻.

PV:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-retain-demo
spec:
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /mnt/demo-retain

PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-retain-demo
spec:
  accessModes: [ "ReadWriteOnce" ]
  resources:
    requests:
      storage: 1Gi
  volumeName: pv-retain-demo

Pod writes data:

echo "retain test" > /data/hello.txt

Delete PVC:

kubectl delete pvc pvc-retain-demo

Result?

• PV enters Released state

• The data is still physically present under /mnt/demo-retain

• New PVC cannot bind because Kubernetes sees “dirty data”

Teaching point:

Retain = safe for production when cleanup is manual. Good for databases, logs, stateful data.

---

2. PV with Delete (Default for most cloud CSI drivers)

Destroy everything — the Viking funeral of volumes 🪦🔥.

PV:

persistentVolumeReclaimPolicy: Delete

Result after deleting PVC:

• PV destroyed

• Cloud disk auto deleted (EBS, GCE PD, Azure Disk)

• Your data? Gone with the wind 🌬️

Teaching point:

Delete = ephemeral workloads, CI/CD, demo clusters.

---

3. PV with Recycle (Deprecated but brilliant demo)

Old-school cleanup mechanic — Kubernetes runs:

rm -rf /the/path/*

It wipes the volume and then makes it available again.

PV:

persistentVolumeReclaimPolicy: Recycle

Result:

• Data wiped

• PV goes back to Available

• New PVCs can reuse it immediately

Teaching point:

Recycle = legacy but shows volume lifecycle clearly.

---

DEMO 2 — Why emptyDir is Critical When Init Container Generates Data

Let’s paint a charming micro-story:

Your init container is the morning chef 👨‍🍳 chopping ingredients. Your main container is the evening cook 🍳 who needs those chopped veggies. But if there’s no shared kitchen… the main cook finds nothing.

emptyDir is the kitchen.

---

Goal of the demo

Show that:

1. Init container generates config/data

2. The main container uses that data

3. Both share a common emptyDir volume

4. Restart → data persists only while pod exists

Perfect for:

• Rendering templates

• Installing binaries

• Extracting archives

• Preparing DB schemas

---

Demo Pod: init container writes → main container reads

apiVersion: v1
kind: Pod
metadata:
  name: emptydir-demo
spec:
  volumes:
    - name: shared-data
      emptyDir: {}
  initContainers:
    - name: init-setup
      image: busybox
      command:
        - /bin/sh
        - -c
        - |
          echo "Config created by init container" > /work/config.txt
      volumeMounts:
        - name: shared-data
          mountPath: /work
  containers:
    - name: main-app
      image: busybox
      command:
        - /bin/sh
        - -c
        - |
          echo "Main container reading file:"; 
          cat /workspace/config.txt; 
          sleep 3600
      volumeMounts:
        - name: shared-data
          mountPath: /workspace

---

Expected behavior

✔ Init container runs first

Writes:

/work/config.txt

✔ Same file appears in main container’s path:

/workspace/config.txt

✔ Main container can read it and continue

✔ Delete pod → everything disappears

(emptyDir lives only while pod lives)

---

❗ 1. You must use a shared volume for init ↔ main

Otherwise the main container sees nothing.

❗ 2. emptyDir is perfect because it:

• Requires no PVC

• Is ultra-fast (node-local)

• Exists only for the pod lifetime

• Simple and elegant

❗ 3. emptyDir is essential for:

• Bootstrapping configs

• Pre-downloading binaries

• Certificate generation

• Temporary caches

• ML model staging

---

Hostpath

---

Short Answer

How you use HostPath	Needs PV?	Notes
Directly inside Pod spec	❌ NO PV required	Quick, dirty, not recommended for production.
As PersistentVolume (PV + PVC)	✅ YES	Proper, safe way. Supports scheduling rules.

---

1️⃣ HostPath WITHOUT PV (Pod-only mode)

You can mount a host directory directly into the pod:

apiVersion: v1
kind: Pod
metadata:
  name: hostpath-direct-demo
spec:
  containers:
    - name: app
      image: busybox
      command: ["sh", "-c", "echo hi > /hp/hello.txt; sleep 3600"]
      volumeMounts:
        - name: hp
          mountPath: /hp
  volumes:
    - name: hp
      hostPath:
        path: /data/demo
        type: DirectoryOrCreate

What this means

• Pod mounts /data/demo from the host node

• No PV or PVC involved

• No dynamic provisioning

• Pod gets scheduled only on one node (if Pod lands on another node → directory won’t exist)

✔ Good for:

• Local demos

• Single-node clusters

• Quick hacking

❌ Not good for:

• Anything involving HA

• Replicas

• Production workloads

---

2️⃣ HostPath WITH PV + PVC (Recommended way)

This is the proper method when you want a persistent volume backed by the host filesystem.

PV:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: hostpath-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: manual
  hostPath:
    path: /mnt/hostpath-data

PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: hostpath-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: manual
  resources:
    requests:
      storage: 5Gi

Pod:

apiVersion: v1
kind: Pod
metadata:
  name: hostpath-pv-demo
spec:
  containers:
    - name: app
      image: busybox
      command: ["sh", "-c", "echo using PV > /data/file.txt; sleep 3600"]
      volumeMounts:
        - name: hp
          mountPath: /data
  volumes:
    - name: hp
      persistentVolumeClaim:
        claimName: hostpath-pvc

---

Differences between Pod-only HostPath and PV-backed HostPath

Feature	Pod-only HostPath	PV-backed HostPath
Needs PV?	❌ No	✅ Yes
Scheduling	Fixed to node but not obvious	Explicit node affinity possible
Good for multi-node?	❌ No	❌ Still no (hostPath is node-bound)
Persistent after pod delete	❌ Only if directory stays	✅ Always
Reclaim policies (Retain/Delete/Recreate)	❌ None	✅ Full PV lifecycle
Binding & lifecycle control	❌ No	✅ Yes

---

When should HostPath use PV?

✔ When you want:

• PVC abstraction

• Pod independence from storage path

• Volume reuse across deployments

• Clear lifecycle

• Ability to transfer ownership

• Cleaner demos & training

❌ Avoid direct HostPath when:

• Multi-node clusters

• Multi-replica deployments

• StatefulSets

• Production systems

---

Best-Practice Summary

Use case	Recommended?
Quick debug pod → use HostPath directly	👍
Teaching PV lifecycle → use HostPath PV+PVC	👍
Running apps needing persistence	👍 (but better use LocalPV/NFS/EBS)
Multi-node production cluster	👎 Never use HostPath