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

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

🏷️ धडा 22 — StatefulSets: नावाच्या पाट्या असलेले बाक

📍 तुम्ही इथे आहात: धडा 22 / 26 · मागील: lesson-21-daemonsets · पुढील: lesson-23-qos-evictions

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

आधीचे सगळे, आणि धडा 12 ने फक्त दुरूनच दाखवलेला workload आकार — आता प्रत्यक्ष हाताने. खरी file:

k8s/postgres-statefulset.yaml — स्वतःचा drawer असलेला खरा Postgres (शिकण्यासाठी; prod ची भूमिका तशीच: RDS)

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

Deployment ची मुले एकमेकांच्या जागी चालणारी असतात — नवे मूल, नवे random नाव (school-api-7d9f8-xk2lp), कोणताही बाक, सामायिक reception नंबर. Stateless कामासाठी उत्तम; database साठी निरुपयोगी. Database मुलाला हवे:

नावाची पाटी 🏷️: postgres-0. मेले? त्याच्या जागी येणारेही postgres-0 — तेच नाव, तीच ओळख, थेट postgres-0.postgres या पत्त्यावर पोहोचता येते (headless Service मधून — "जो मोकळा असेल तो" ऐवजी तुम्हाला ठरावीक मुलाकडे जोडून देणारे reception).
स्वतःचा drawer 🗄️: volumeClaimTemplates प्रत्येक pod साठी वैयक्तिक PVC बनवते — postgres-0 नेहमी स्वतःचाच drawer उघडतो (धडा 12 ची ग्रंथालयातली फळी, आता मुलाचे नाव कोरलेली). Pod delete केल्याने drawer कधीच delete होत नाही.
क्रम 📶: मुले एकेक करून येतात (-0, मग -1, मग -2) आणि उलट्या क्रमाने जातात — replicated databases ना followers त्याच्याकडून copy करण्याआधी पहिले मूल तयार असायला लागते.

ही तिकडी — चिकटलेले नाव, चिकटलेला drawer, क्रमाने येणे — हाच StatefulSet आणि Deployment यांमधला संपूर्ण फरक.

🗺️ आकृती

flowchart LR
    ss["🏷️ StatefulSet: postgres<br/>replicas: 1"]
    hs["☎️ headless Service<br/>'connect me to postgres-0<br/>SPECIFICALLY'"]
    subgraph pod0["🪑 postgres-0 - named desk"]
        pg["postgres:16"]
    end
    pvc["🗄️ PVC: data-postgres-0<br/>ITS OWN drawer -<br/>survives the pod, reattaches"]
    ss -->|"1 ordered, named"| pod0
    hs -->|"2 by-name address"| pod0
    pod0 ---|"3 always reopens"| pvc

❓ काय

serviceName: एका headless Service कडे (clusterIP: None) निर्देश करते — load-balancing ऐवजी DNS प्रत्येक pod ला नावानुसार स्थिर पत्ता देतो.
volumeClaimTemplates: — वैयक्तिक drawers बनवणारा कारखाना. EKS वर हे EBS volumes होतात, आणि धडा 15 चा इशारा लागू होतो: drawer एकाच इमारतीत (AZ) राहतो — postgres-0 फक्त त्याचा drawer जिथे आहे तिथेच reschedule होतो.
Updates उलट्या क्रमाने, एकेक करून होतात; scale down केल्यावर drawers वेगळे होतात पण ठेवले जातात (परत येणाऱ्या मुलांना त्यांचे सामान मिळते).
प्रामाणिक मर्यादा: एक StatefulSet ≠ high availability. खऱ्या replication/ failover साठी operator लागतो (CloudNativePG वगैरे — operators म्हणजे काय ते धडा 25 समजावतो). या repo ची production भूमिका कायम आहे: ग्रंथालय भाड्याने घ्या (RDS); StatefulSets ते समजून घेण्यासाठी चालवा, किंवा dev/test साठी.

🤔 का

कारण "database cluster मध्ये चालवू शकतो का?" हा प्रश्न प्रत्येक team मध्ये विचारला जातो, आणि आता तुम्ही नेमके उत्तर देऊ शकता: k8s तुम्हाला हे देतो (ओळख, storage, क्रम), हे देत नाही (replication, failover, backups — operator चे किंवा RDS चे काम), आणि धडा 12 ने RDS का निवडला ते हे. यंत्रणा माहीत असल्यामुळेच "भाड्याने घ्या" हा सल्ला विश्वासार्ह ठरतो.

🧪 करून पाहा

kubectl apply -f k8s/postgres-statefulset.yaml
kubectl -n school get pods -w                    # postgres-0 — THE name; Ctrl+C
kubectl -n school get pvc                        # data-postgres-0 — THE drawer

# write something, then kill the kid:
kubectl -n school exec postgres-0 -- psql -U school -c "CREATE TABLE proof(id int); INSERT INTO proof VALUES (42);"
kubectl -n school delete pod postgres-0          # 💥
kubectl -n school get pods -w                    # postgres-0 returns (same name!); Ctrl+C

# same drawer, data intact:
kubectl -n school exec postgres-0 -- psql -U school -c "SELECT * FROM proof;"   # 42 🎉

# cleanup (drawer is kept on purpose — delete it explicitly):
kubectl delete -f k8s/postgres-statefulset.yaml
kubectl -n school delete pvc data-postgres-0

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

kubectl get sts,pvc · kubectl get pods -l app=postgres

🔗 यावर आधारित: 🪪 AWS L17 (RDS — त्याऐवजी नोंदींचे कार्यालय भाड्याने घ्या)

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

postgres-0 delete करा → त्याच्या जागी येणाऱ्याचे नाव पुन्हा postgres-0 असते आणि तो rows शाबूत असलेला data-postgres-0 पुन्हा जोडतो.

🧹 साफसफाई

kubectl delete sts postgres PVCs ठेवतो — data काढून टाकायचा असेल तर ते स्पष्टपणे delete करा

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

stateless app साठी StatefulSet — तुम्ही फक्त rollouts हळू केले
single-replica StatefulSet कडून HA ची अपेक्षा — त्यासाठी operator किंवा RDS लागतो

⏭️ पुढे

बाकावरचे जेवण संपले तर आधी कोणाला बाहेर जायला सांगितले जाते? QoS classes आणि evictions — नकळत तुम्ही आधीच ज्या उतरंडीत आहात ती.

git checkout lesson-23-qos-evictions

🏷️ Lesson 22 — StatefulSets: desks with name plates

📍 You are here: Lesson 22 of 26 · Previous: lesson-21-daemonsets · Next: lesson-23-qos-evictions

📦 What's in this branch

Everything before, plus the workload shape lesson 12 only waved at — now hands-on. Real file:

k8s/postgres-statefulset.yaml — a real Postgres with its own drawer (for learning; prod stance unchanged: RDS)

🧒 Explain like I'm 5

Deployment kids are interchangeable — new kid, new random name (school-api-7d9f8-xk2lp), any desk, shared reception number. Perfect for stateless work; useless for a database. A database kid needs:

A name plate 🏷️: postgres-0. Dies? The replacement is also postgres-0 — same name, same identity, addressable directly as postgres-0.postgres (via a headless Service — reception that transfers you to a SPECIFIC kid instead of "whoever's free").
Their own drawer 🗄️: volumeClaimTemplates mints a personal PVC per pod — postgres-0 always reopens its own drawer (lesson 12's library shelf, now with the kid's name engraved). Deleting the pod never deletes the drawer.
Order 📶: kids arrive one at a time (-0, then -1, then -2) and leave in reverse — replicated databases need the firstborn ready before the followers copy from it.

That trio — sticky name, sticky drawer, ordered arrival — is the entire difference between a StatefulSet and a Deployment.

🗺️ Diagram

flowchart LR
    ss["🏷️ StatefulSet: postgres<br/>replicas: 1"]
    hs["☎️ headless Service<br/>'connect me to postgres-0<br/>SPECIFICALLY'"]
    subgraph pod0["🪑 postgres-0 - named desk"]
        pg["postgres:16"]
    end
    pvc["🗄️ PVC: data-postgres-0<br/>ITS OWN drawer -<br/>survives the pod, reattaches"]
    ss -->|"1 ordered, named"| pod0
    hs -->|"2 by-name address"| pod0
    pod0 ---|"3 always reopens"| pvc

❓ What

serviceName: points at a headless Service (clusterIP: None) — DNS gives each pod a stable per-name address instead of load-balancing.
volumeClaimTemplates: — the personal-drawer mint. On EKS these become EBS volumes, and lesson 15's warning applies: a drawer lives in ONE building (AZ) — postgres-0 reschedules only where its drawer is.
Updates roll in reverse order, one by one; scaling down detaches drawers but keeps them (rejoining kids find their stuff).
Honest scope: ONE StatefulSet ≠ high availability. Real replication/ failover needs an operator (CloudNativePG etc. — lesson 25 explains what operators are). This repo's production stance stands: rent the library (RDS); run StatefulSets to understand them, or for dev/test.

🤔 Why

Because "can we run the database in the cluster?" is asked in every team, and now you can answer precisely: here's what k8s gives you (identity, storage, order), here's what it doesn't (replication, failover, backups — the operator's or RDS's job), and here's why lesson 12 chose RDS. Knowing the machinery is what makes the "rent it" advice credible.

🧪 Try it

kubectl apply -f k8s/postgres-statefulset.yaml
kubectl -n school get pods -w                    # postgres-0 — THE name; Ctrl+C
kubectl -n school get pvc                        # data-postgres-0 — THE drawer

# write something, then kill the kid:
kubectl -n school exec postgres-0 -- psql -U school -c "CREATE TABLE proof(id int); INSERT INTO proof VALUES (42);"
kubectl -n school delete pod postgres-0          # 💥
kubectl -n school get pods -w                    # postgres-0 returns (same name!); Ctrl+C

# same drawer, data intact:
kubectl -n school exec postgres-0 -- psql -U school -c "SELECT * FROM proof;"   # 42 🎉

# cleanup (drawer is kept on purpose — delete it explicitly):
kubectl delete -f k8s/postgres-statefulset.yaml
kubectl -n school delete pvc data-postgres-0

🔧 kubectl for this lesson

kubectl get sts,pvc · kubectl get pods -l app=postgres

🔗 Builds on: 🪪 AWS L17 (RDS — rent the record office instead)

✅ Verify — what you should see

delete postgres-0 → the replacement is named postgres-0 again and reattaches data-postgres-0 with the rows intact.

🧹 Clean up

kubectl delete sts postgres keeps the PVCs — delete them explicitly if you want the data gone

⚠️ Common mistakes

a StatefulSet for a stateless app — you just made rollouts slower
expecting HA from a single-replica StatefulSet — that needs an operator or RDS

⏭️ Next

When a desk runs out of lunch, who gets asked to leave first? QoS classes & evictions — the pecking order you're already in without knowing it.

git checkout lesson-23-qos-evictions

← Previousdaemonsets Next →qos evictions

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