🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

📚 धडा 12 — Storage आणि state: दप्तर विरुद्ध ग्रंथालयाचे कपाट

📍 तुम्ही इथे आहात: 13 पैकी धडा 12 · मागचा: lesson-11-rollouts · पुढचा: lesson-13-under-the-hood

📦 या ब्रँचमध्ये काय आहे

धडे 01–11, आणि: storage — pod मेल्यावर काय टिकते आणि काय नाही, आणि "माझा database कुठे राहावा?" याचे प्रामाणिक उत्तर. खऱ्या files:

k8s/secret.example.yaml — cluster च्या बाहेर बोट दाखवणारा DATABASE_URL
terraform/rds.tf — हा repo प्रत्यक्षात वापरतो तो managed Postgres
docker-compose.yml — local Postgres चा data ठेवणारी volumes: ओळ पाहा

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

एखादे मूल कायमचे शाळा सोडून जाते, तेव्हा दोन प्रकारच्या वस्तू असतात:

त्याचे दप्तर 🎒 — त्याच्यासोबत घरी जाते. गेले. हीच pod ची स्वतःची filesystem: container ने लिहिलेली प्रत्येक file pod मेल्यावर नाहीशी होते. (आणि pods सतत मरतात — धडे 03, 09, 11 त्यांना मुद्दाम मारतात!)
ग्रंथालयाचे कपाट 📚 — कोणती मुले येतात आणि जातात याची पर्वा न करता पुस्तके ग्रंथालयातच राहतात. पुढचे मूल मागचे जिथे थांबले होते तिथूनच सुरू करते. हाच PersistentVolume: स्वतःचे वेगळे आयुष्य असलेली storage.

Pod ला कपाटात जागा कशी मिळते? तो एक मागणी-पावती भरतो: "मला 10Gi कपाट हवे आहे, कृपया" — हाच PersistentVolumeClaim (PVC). ग्रंथपाल (एक StorageClass + CSI driver — AWS वर, एक EBS disk) खरे कपाट शोधते किंवा बनवते आणि ते pod ला जोडते. नंतर नवा pod? तीच पावती → तेच कपाट, तीच पुस्तके.

आणि मुलांचे सर्वात मोठे गुपित 🤫: कधी कधी सर्वात चांगले ग्रंथालय रस्त्याच्या पलीकडे असते. हा repo cluster च्या आत Postgres चालवण्याऐवजी त्याचा database RDS मध्ये ठेवतो — AWS चे व्यावसायिकपणे चालवलेले ग्रंथालय. दोन्ही योग्य आहेत; कधी कोणते निवडायचे हे जाणणे हाच खरा धडा.

🗺️ आकृती

flowchart TB
    subgraph cluster["🏫 Kubernetes cluster"]
        pod1["🪑 postgres pod v1<br/>💥 dies"]
        pod2["🪑 postgres pod v2<br/>new desk, same books"]
        pvc["📝 PVC: 'I claim 10Gi'"]
        pod1 -.-> pvc
        pod2 --> pvc
    end
    pv["📚 PersistentVolume<br/>= real EBS disk on AWS<br/>outlives every pod"]
    pvc --> pv
    subgraph outside["🏛️ across the street - what THIS repo does"]
        rds["AWS RDS Postgres<br/>backups, patching, failover<br/>managed by AWS"]
    end
    api["🪑 school-api pods"] -->|"DATABASE_URL from the Secret<br/>lesson 06"| rds

❓ काय

Volume — pod ला जोडलेली storage. emptyDir फक्त pod जिवंत असेपर्यंत राहते (दप्तर); PVC वर आधारित volume त्याच्यानंतरही टिकते (कपाट).
PersistentVolume (PV) — खरी storage (EKS वर एक EBS disk). PersistentVolumeClaim (PVC) — एखाद्यासाठी pod ची मागणी-पावती. StorageClass — मागणीनुसार PVs बनवणारी ग्रंथपाल.
StatefulSet — stateful apps (databases) साठीचा खास Deployment: pods ना स्थिर नावे (postgres-0) मिळतात आणि प्रत्येक जण स्वतःचा PVC ठेवतो.
आर्किटेक्चरमधली निवड: cluster-मध्ये-stateful (StatefulSet + PVC) विरुद्ध बाहेरची managed service (RDS). या repo ने RDS निवडले — terraform/rds.tf पाहा.

🤔 का

धडे 01–11 मधले सगळे चालले कारण pods टाकाऊ होते — त्यांना मारा, हलवा, वाढवा. Databases ही जादू मोडतात: data टाकाऊ असता कामा नये. PV/PVC जीवनचक्र विभागून ही जादू परत आणतात: pods cattle राहतात, storage pet बनते. पण production database नीट चालवणे (backups, upgrades, failover, tuning) हे पूर्णवेळचे काम आहे — म्हणूनच लहान teams सहसा ग्रंथपालच भाड्याने घेतात (RDS) आणि cluster stateless ठेवतात. अनुभवाचा नियम: cluster मध्ये stateless, state managed services मध्ये — अगदी या repo चा आकार.

🔧 कसे (या repo मध्ये)

App pods मुद्दाम stateless आहेत — k8s/deployment.yaml मध्ये एकही volume नाही. सगळी state Postgres मध्ये राहते, जिथे धडा 06 च्या Secret मधल्या DATABASE_URL ने पोहोचले जाते: postgres://school:...@your-rds-endpoint:5432/school.
terraform/rds.tf तो Postgres automated backups आणि encryption सह बनवते — ज्या गोष्टी StatefulSet मध्ये तुम्हाला कराव्या लागल्या असत्या.
Local ला, docker-compose.yml तीच कल्पना लहान स्वरूपात दाखवते: नाव दिलेला Docker volume restarts नंतरही Postgres चा data ठेवतो.

🧪 करून पाहा

# Feel the difference between backpack and shelf (local cluster):
kubectl -n school apply -f - <<'EOF'
apiVersion: v1
kind: PersistentVolumeClaim
metadata: { name: shelf }
spec:
  accessModes: [ReadWriteOnce]
  resources: { requests: { storage: 1Gi } }
EOF
kubectl -n school run scribe --restart=Never --image=busybox \
  --overrides='{"spec":{"containers":[{"name":"scribe","image":"busybox",
    "command":["sh","-c","echo my homework > /shelf/notes.txt; sleep 3600"],
    "volumeMounts":[{"name":"s","mountPath":"/shelf"}]}],
    "volumes":[{"name":"s","persistentVolumeClaim":{"claimName":"shelf"}}]}}'

kubectl -n school delete pod scribe          # kid leaves school 💥
# New kid, same claim — the homework is still there:
kubectl -n school run scribe2 --restart=Never --image=busybox \
  --overrides='{"spec":{"containers":[{"name":"scribe2","image":"busybox",
    "command":["sh","-c","cat /shelf/notes.txt; sleep 60"],
    "volumeMounts":[{"name":"s","mountPath":"/shelf"}]}],
    "volumes":[{"name":"s","persistentVolumeClaim":{"claimName":"shelf"}}]}}'
kubectl -n school logs scribe2               # → "my homework" 🎉
kubectl -n school delete pod scribe2 && kubectl -n school delete pvc shelf

🔧 या धड्यासाठी kubectl

kubectl get pv,pvc · kubectl describe pvc

🔗 यावर आधारित: 🪪 AWS L11 (EBS) · L14 (S3) · L17 (RDS)

✅ तपासा — तुम्हाला काय दिसायला हवे

postgres pod मारा → नव्या pod ला त्याच PVC वर त्याच rows सापडतात.

🧹 साफसफाई

data नाहीसा करायचा असेल तर kubectl delete pvc (PVC मुद्दाम pod पेक्षा जास्त टिकतो)

⚠️ नेहमीच्या चुका

state container च्या filesystem मध्ये (दप्तरात) ठेवणे
operator शिवाय production databases cluster च्या आत चालवणे — RDS भाड्याने घ्या (AWS L17)

⏭️ पुढे

शेवटचा धडा: शाळेच्या कार्यालयाचे दार उघडा आणि हे सगळे घडवून आणणाऱ्या यंत्रणेला भेटा — control plane.

git checkout lesson-13-under-the-hood

📚 Lesson 12 — Storage & state: backpack vs library shelf

📍 You are here: Lesson 12 of 13 · Previous: lesson-11-rollouts · Next: lesson-13-under-the-hood

📦 What's in this branch

Lessons 01–11, plus: storage — what survives a pod's death and what doesn't, and the honest answer to "where should my database live?" Real files:

k8s/secret.example.yaml — DATABASE_URL pointing outside the cluster
terraform/rds.tf — the managed Postgres this repo actually uses
docker-compose.yml — see the volumes: line keeping local Postgres data

🧒 Explain like I'm 5

When a kid leaves school for good, two kinds of stuff exist:

Their backpack 🎒 — goes home WITH them. Gone. That's a pod's own filesystem: every file a container writes disappears when the pod dies. (And pods die all the time — lessons 03, 09, 11 kill them on purpose!)
The library shelf 📚 — books stay in the library, no matter which kids come and go. The next kid picks up exactly where the last one left off. That's a PersistentVolume: storage with a life of its own.

How does a pod get shelf space? It files a request slip: "I need 10Gi of shelf, please" — that's a PersistentVolumeClaim (PVC). The librarian (a StorageClass + CSI driver — on AWS, an EBS disk) finds or creates a real shelf and clips it to the pod. New pod later? Same slip → same shelf, same books.

And the biggest kid secret 🤫: sometimes the best library is across the street. This repo keeps its database in RDS — AWS's professionally-run library — instead of running Postgres inside the cluster. Both are valid; knowing when to choose which is the real lesson.

🗺️ Diagram

flowchart TB
    subgraph cluster["🏫 Kubernetes cluster"]
        pod1["🪑 postgres pod v1<br/>💥 dies"]
        pod2["🪑 postgres pod v2<br/>new desk, same books"]
        pvc["📝 PVC: 'I claim 10Gi'"]
        pod1 -.-> pvc
        pod2 --> pvc
    end
    pv["📚 PersistentVolume<br/>= real EBS disk on AWS<br/>outlives every pod"]
    pvc --> pv
    subgraph outside["🏛️ across the street - what THIS repo does"]
        rds["AWS RDS Postgres<br/>backups, patching, failover<br/>managed by AWS"]
    end
    api["🪑 school-api pods"] -->|"DATABASE_URL from the Secret<br/>lesson 06"| rds

❓ What

Volume — storage attached to a pod. emptyDir lives only as long as the pod (backpack); a PVC-backed volume survives it (shelf).
PersistentVolume (PV) — the actual storage (an EBS disk on EKS). PersistentVolumeClaim (PVC) — a pod's request slip for one. StorageClass — the librarian that creates PVs on demand.
StatefulSet — a special Deployment for stateful apps (databases): pods get stable names (postgres-0) and each keeps its own PVC.
The architectural choice: stateful-in-cluster (StatefulSet + PVC) vs managed service outside (RDS). This repo chose RDS — see terraform/rds.tf.

🤔 Why

Everything in lessons 01–11 worked because pods were disposable — kill them, move them, multiply them. Databases break that spell: data must NOT be disposable. PV/PVC restores the spell by splitting the lifecycle: pods stay cattle, storage becomes the pet. But running a production database well (backups, upgrades, failover, tuning) is a full-time job — which is why small teams usually rent the librarian (RDS) and keep the cluster stateless. Rule of thumb: stateless in the cluster, state in managed services — exactly this repo's shape.

🔧 How (in this repo)

The app pods are stateless on purpose — no volumes in k8s/deployment.yaml at all. All state lives in Postgres, reached via DATABASE_URL from lesson 06's Secret: postgres://school:...@your-rds-endpoint:5432/school.
terraform/rds.tf builds that Postgres with automated backups and encryption — things a StatefulSet would make you do.
Locally, docker-compose.yml shows the same idea in miniature: a named Docker volume keeps Postgres data across restarts.

🧪 Try it

# Feel the difference between backpack and shelf (local cluster):
kubectl -n school apply -f - <<'EOF'
apiVersion: v1
kind: PersistentVolumeClaim
metadata: { name: shelf }
spec:
  accessModes: [ReadWriteOnce]
  resources: { requests: { storage: 1Gi } }
EOF
kubectl -n school run scribe --restart=Never --image=busybox \
  --overrides='{"spec":{"containers":[{"name":"scribe","image":"busybox",
    "command":["sh","-c","echo my homework > /shelf/notes.txt; sleep 3600"],
    "volumeMounts":[{"name":"s","mountPath":"/shelf"}]}],
    "volumes":[{"name":"s","persistentVolumeClaim":{"claimName":"shelf"}}]}}'

kubectl -n school delete pod scribe          # kid leaves school 💥
# New kid, same claim — the homework is still there:
kubectl -n school run scribe2 --restart=Never --image=busybox \
  --overrides='{"spec":{"containers":[{"name":"scribe2","image":"busybox",
    "command":["sh","-c","cat /shelf/notes.txt; sleep 60"],
    "volumeMounts":[{"name":"s","mountPath":"/shelf"}]}],
    "volumes":[{"name":"s","persistentVolumeClaim":{"claimName":"shelf"}}]}}'
kubectl -n school logs scribe2               # → "my homework" 🎉
kubectl -n school delete pod scribe2 && kubectl -n school delete pvc shelf

🔧 kubectl for this lesson

kubectl get pv,pvc · kubectl describe pvc

🔗 Builds on: 🪪 AWS L11 (EBS) · L14 (S3) · L17 (RDS)

✅ Verify — what you should see

kill the postgres pod → the new pod finds the same rows on the same PVC.

🧹 Clean up

kubectl delete pvc if you want the data gone (a PVC outlives the pod on purpose)

⚠️ Common mistakes

storing state in the container filesystem (a backpack)
running production databases in-cluster without an operator — rent RDS (AWS L17)

⏭️ Next

Final lesson: open the school office door and meet the machinery that made ALL of this happen — the control plane.

git checkout lesson-13-under-the-hood

← Previousrollouts Next →under the hood

This page is the lesson's README from the lesson-12-storage branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.