प्रत्येक धड्याची मुख्य कल्पना एका क्रमांकित entity/sequence आकृतीत — प्रत्येक बॉक्स-आणि-बाण चित्रात वर्तुळातील क्रमांक 1 → 2 → 3 अनुसरा. संपूर्ण ELI5 गोष्ट आणि प्रत्यक्ष commands साठी धडाच उघडा.
1 🍱 कंटेनर & इमेज — पाककृती → डबा → जेवण
एक पाककृती (Dockerfile) एक गोठवलेला डबा (इमेज) बनवते; प्रत्येक उघडलेला डबा (कंटेनर) एकसारखा.
🧒 सोप्या शब्दांत
आई एकच पाककृती लिहिते आणि त्यावरून डबे गोठवून ठेवते, म्हणून उघडलेल्या प्रत्येक डब्याची चव अगदी सारखी असते. Software मध्ये पाककृती म्हणजे Dockerfile, गोठवलेला डबा म्हणजे image, आणि उघडून चालू असलेला डबा म्हणजे container. जेवण बदलायचे असेल तर नव्या label (v2) सह नवा डबा बनवा — आधीच उघडलेल्या डब्यात कधीच हात घालू नका.
📖 नवे शब्दDockerfile — पाककृती: डबा कसा बनवायचा याच्या एक-एक पायरीच्या सूचनाimage — गोठवलेला डबा — बांधून बंद केलेले तुमचे app, जे कधीच बदलत नाहीcontainer — उघडलेला एक डबा, जो प्रत्यक्ष चालू आहेtag — डब्यावरचे label, जसे v1 किंवा v2, म्हणजे कोणती batch ते कळते
⏪ आधी
एका laptop वर चालणारे app दुसऱ्यावर बिघडत असे, कारण प्रत्येक machine वर वेगळ्या libraries आणि settings होत्या.
💡 काय
Image म्हणजे एका पाककृतीपासून (Dockerfile) बनवलेला गोठवलेला डबा; त्यातून उघडलेला प्रत्येक container एकसारखा असतो.
⚙️ कसे
Dockerfile वरून school-api:v1 build करा, ECR वर push करा आणि तीन वेळा चालवा; प्रत्येक container मध्ये तेच bytes.
🎯 का
तीच image laptop वर, CI मध्ये आणि cluster मध्ये चालते, आणि बदल म्हणजे नवा tag, कधीच patch नाही.
🚀 पुढे
Docker एकाच machine वर डबे चालवतो; Kubernetes machine निवडतो, मेलेले डबे पुन्हा सुरू करतो आणि त्यांना नंबर देतो.
🧪 Try it here — एक image बनवा, तीन वेळा चालवा, मग code बदला
Kubernetes कधीच उघडा कंटेनर चालवत नाही — तो नेहमी स्वतःचा IP आणि सामायिक कपाट असलेल्या बाकावर (Pod) बसतो.
🧒 सोप्या शब्दांत
वर्गात प्रत्येक विद्यार्थ्याला क्रमांक असलेला बाक मिळतो, आणि कधी कधी दोन मित्र एक बाक आणि एक फळी वाटून घेतात. Pod म्हणजे तो बाक: Kubernetes container ला नेहमी अशाच बाकावर बसवतो, आणि प्रत्येक Pod ला स्वतःचा IP address मिळतो. बाक मोडला तर कोणी तो दुरुस्त करत नाही — दुसरीकडे नव्या क्रमांकाचा नवा बाक लावला जातो.
📖 नवे शब्दPod — बाक, जिथे एक किंवा अधिक containers एकत्र बसतातIP address — बाकाचा क्रमांक, ज्यावरून इतर programs त्याच्यापर्यंत पोहोचतातsidecar — त्याच बाकावर बसणारा मदतनीस container, जसे log shippernode — machine (खोली) जिथे बाक ठेवले जातात
⏪ आधी
एकट्या container ला स्थिर घर नव्हते: त्याला पत्ता किंवा मदतनीस processes साठी सामायिक फळी काहीच मिळत नसे.
💡 काय
Pod म्हणजे स्वतःचा IP आणि सामायिक फळी असलेला एक बाक, ज्यावर school-api सारखे एक किंवा अधिक containers असतात.
⚙️ कसे
10.0.4.7:3000 वरचा school-api Pod त्याच बाकावरच्या log-shipper sidecar सोबत volume आणि localhost वाटून घेऊ शकतो.
🎯 का
Node मेल्यावर Kubernetes बाक कधीच दुरुस्त करत नाही; तो दुसरीकडे नव्या नावाने आणि नव्या IP ने नवा Pod बांधतो.
🚀 पुढे
Pods गुरे आहेत, पाळीव प्राणी नाहीत: Deployment संख्या राखते (L03) आणि Service स्थिर नंबर राखते (L04).
🧪 Try it here — Pod खालचा node मारा आणि त्याचा जुना पत्ता वापरून पहा
3 🧑🏫 Deployments — इच्छा जाहीर करा, वर्गप्रमुख ती कायम पाळतो
तुम्ही म्हणता "नेहमी 2"; ReplicaSet सतत मोजतो आणि मेलेले काहीही बदलतो.
🧒 सोप्या शब्दांत
वर्ग-मॉनिटरला सांगितले आहे: फळ्यापाशी नेहमी 2 विद्यार्थी हवेत. मॉनिटर सतत मोजत राहतो, आणि एक गेला तर लगेच दुसऱ्याला बोलावतो. Deployment म्हणजे ती लिहिलेली इच्छा (replicas: 2), आणि ReplicaSet म्हणजे कायम मोजणारा मॉनिटर. म्हणूनच pod delete केल्याने app बंद होत नाही — मॉनिटर लगेच एक परत ठेवतो.
📖 नवे शब्दDeployment — तुमची लिहिलेली इच्छा: कोणते app, कोणती version, किती copiesreplicas — pod च्या किती copies चालू हव्यात ती संख्याReplicaSet — pods मोजणारा मॉनिटर, जो संख्या जुळवायला pods वाढवतो किंवा कमी करतोlabel — app=school-api सारखी नावाची पाटी, जिच्यावरून मॉनिटर मोजतो
⏪ आधी
रात्री pod कोसळला तर कोणीतरी ते लक्षात घेऊन users तक्रार करण्याआधी हाताने नवा सुरू करावा लागत असे.
💡 काय
Deployment म्हणजे "replicas: 2" सारखी लिहिलेली इच्छा, जी ReplicaSet मॉनिटर कायम पाळायला लावतो.
⚙️ कसे
Loop app=school-api label असलेले pods मोजतो; 2 ऐवजी 1 दिसला तर लगेच आणखी एक बनवतो.
🎯 का
Pod delete केल्याने app थांबत नाही; मॉनिटर काही सेकंदांत दुसरा ठेवतो, त्यामुळे crashes आपोआप भरून निघतात.
🚀 पुढे
नव्या pods ना नवे IP मिळतात, म्हणून पुढे कधीच न बदलणारा एक नंबर हवा: Service (L04).
Pods ना सतत नवे IP मिळतात; कॉल करणारे Service चे नाव लावतात आणि ते जो हजर असेल त्याच्याकडे पाठवते.
🧒 सोप्या शब्दांत
विद्यार्थी सतत बाक बदलतात, म्हणून एखाद्याला गाठायला बाक-क्रमांक लिहून ठेवणे उपयोगाचे नाही. त्याऐवजी शाळेच्या office चा एक कधीच न बदलणारा फोन नंबर असतो, आणि तो तुम्हाला हजर व तयार असलेल्या कोणाशीही जोडतो. Service म्हणजे तो नंबर: callers port 80 वर school-api हे नाव dial करतात, आणि तो port 3000 वर ऐकणाऱ्या तयार pod कडे call पाठवतो.
📖 नवे शब्दService — एक स्थिर नाव आणि नंबर, जो नेहमी तयार pod पर्यंत पोहोचतोselector — कोणते pods या नंबरचे आहेत ते सांगणारा नियम (app=school-api)port / targetPort — port म्हणजे callers जो dial करतात (80); targetPort म्हणजे app जिथे ऐकते (3000)EndpointSlice — Service मागच्या तयार pods ची जिवंत यादी
⏪ आधी
Pods ना सतत नवे IP मिळत, त्यामुळे पत्ता लक्षात ठेवणारा caller लवकरच नसलेल्या बाकाला फोन करत असे.
💡 काय
Service म्हणजे कधीच न बदलणारा एक फोन नंबर, जो त्या वेळी हजर असलेल्या ready pods कडे call पाठवतो.
⚙️ कसे
Service school-api selector app=school-api वापरते आणि फक्त READY pods वर port 80 ला targetPort 3000 शी जोडते.
🎯 का
analytics फक्त नावाने http://school-api ला call करते, आणि कोणताही code न बदलता pods येऊ-जाऊ शकतात.
🚀 पुढे
school-api सारखी नावे फक्त एका खोलीत unique असावी लागतात, म्हणून पुढे namespaces (L05).
🧪 Try it here — Service ला 8 calls पाठवा; कोणते pods तयार आहेत ते बदला
एक सामायिक cluster, खोल्यांत विभागलेला — नावे फक्त खोलीच्या आत वेगळी असावी लागतात.
🧒 सोप्या शब्दांत
एका शाळेच्या इमारतीत अनेक वर्ग असतात, आणि 3A मध्ये एक ऐश्वर्या व 3B मध्ये दुसरी ऐश्वर्या असली तरी गोंधळ होत नाही. Namespace म्हणजे एका cluster मधला वर्ग: नाव फक्त त्या खोलीत वेगळे असले की पुरे. म्हणून नेहमी कोणती खोली ते सांगा (-n school), नाहीतर तुम्ही default नावाच्या बोळात पोहोचता.
📖 नवे शब्दnamespace — cluster मधली खोली; तेच नाव दोन खोल्यांत असू शकतेcluster — संपूर्ण इमारत: Kubernetes सांभाळते ती सगळी machineskube-system — office ची खोली, जिथे Kubernetes स्वतःचे मदतनीस ठेवते-n — kubectl command मधला भाग, जो कोणती खोली ते सांगतो
⏪ आधी
सगळे एकाच मोठ्या corridor मध्ये पडत असे, त्यामुळे school-api च्या dev आणि prod प्रतींची नावे भिडत.
💡 काय
Namespace म्हणजे एका cluster इमारतीतली वर्गखोली; नावे फक्त खोलीच्या आत unique असावी लागतात.
⚙️ कसे
आपले app school मध्ये, system चे भाग kube-system मध्ये राहतात; खोली निवडायला kubectl get pods -n school वापरा.
🎯 का
त्याच नावांनी school-dev प्रत चालवता येते आणि school ला हात न लावता एका command ने ती delete करता येते.
🚀 पुढे
Namespace म्हणजे label आहे, भिंत नाही; खरी कुंपणे NetworkPolicies (L19) आणि RBAC (L17) बांधतात.
🧪 Try it here — खोल्यांमध्ये नावाने गोष्टी बनवा — संघर्ष ओळखा
सगळीकडे तीच इमेज; सूचना फलक (config) आणि लॉकरची किल्ली (secret) सुरू होताना घातले जातात.
🧒 सोप्या शब्दांत
तोच डबा प्रत्येक शाळेत जातो, पण प्रत्येक शाळा सूचना-फलकावर स्वतःचे वेळापत्रक लावते आणि तुम्हाला स्वतःची locker ची चावी देते. ConfigMap म्हणजे सूचना-फलक (PORT=3000 सारख्या settings) आणि Secret म्हणजे locker ची चावी (जसे database चा password). दोन्ही pod सुरू होताना त्याला दिले जातात, म्हणून एकच image dev आणि prod मध्ये चालते आणि तिच्यात कधीच password नसतो.
📖 नवे शब्दConfigMap — सूचना-फलक: app सुरू होताना वाचते त्या साध्या settingsSecret — locker ची चावी: image पासून वेगळे ठेवलेले passwords आणि keysbase64 — दुसऱ्या अक्षरांत लिहिलेला text; कोणीही तो परत वाचू शकतो, म्हणून ते कुलूप नाहीenvironment variable — PORT=3000 सारखी नाव असलेली setting, जी चालू app वाचू शकते
⏪ आधी
Settings आणि passwords image मध्येच भाजलेले असत, त्यामुळे dev आणि prod ला वेगळे builds लागत आणि secrets फुटत.
💡 काय
ConfigMap म्हणजे settings चा सूचना फलक आणि Secret म्हणजे लॉकरची चावी, दोन्ही डब्याबाहेर ठेवलेले.
⚙️ कसे
सुरू होताना envFrom आणि secretKeyRef pod मध्ये PORT=3000, APP_VERSION=k8s आणि DATABASE_URL भरतात.
🎯 का
तीच image आत कोणताही password न ठेवता dev आणि prod मध्ये चालते; फक्त ConfigMap आणि Secret वेगळे असतात.
🚀 पुढे
चालू pods ना ConfigMap चे बदल कळत नाहीत, म्हणून kubectl rollout restart चालवा; secret.yaml git मध्ये ठेवू नका.
🧪 Try it here — ConfigMap मधली setting बदला आणि pod ला कधी कळते ते पहा
7 🙋 Health probes — दोन प्रश्न, दोन अगदी वेगळे परिणाम
liveness अपयश कंटेनर पुन्हा सुरू करते; readiness अपयश फक्त त्याचा traffic थांबवते.
🧒 सोप्या शब्दांत
शिक्षक दोन वेगळे प्रश्न विचारतात. "तू आहेस तरी का?" — सलग तीन वेळा उत्तर नाही, तर विद्यार्थ्याला पुन्हा नव्याने सुरुवात करायला पाठवतात. "आत्ता पाहुणे घेऊ शकतोस का?" — नाही म्हटले तर काही वेळ पाहुणे येत नाहीत, एवढेच. Kubernetes हेच विचारते: liveness (दर 10 s ला /healthz) container restart करते; readiness (दर 5 s ला /readyz) फक्त त्याचे traffic थांबवते.
📖 नवे शब्दliveness probe — "तू जिवंत आहेस का?" — यात नापास झाल्यास container restart होतोreadiness probe — "पाहुणे घेऊ शकतोस का?" — यात नापास झाल्यास फक्त काही वेळ traffic थांबतेkubelet — प्रत्येक node वरचा मदतनीस, जो हे प्रश्न सतत विचारत राहतोCrashLoopBackOff — container पुन्हा पुन्हा restart होऊन पडतो, म्हणून Kubernetes दर वेळी जास्त थांबते
⏪ आधी
अडकलेल्या process ला traffic मिळत राहायचे, आणि अजून सुरू होणाऱ्या pod ला न सांभाळता येणाऱ्या requests येत.
💡 काय
Probes म्हणजे kubelet सतत विचारतो ते दोन प्रश्न: liveness "जिवंत आहेस का?", readiness "पाहुणे घेऊ शकतोस का?"
⚙️ कसे
दर 10 s चा GET /healthz 3 वेळा fail झाला तर container restart होतो; दर 5 s चा GET /readyz fail झाला तर traffic थांबते.
🎯 का
अडकलेले containers आपोआप बरे होतात, आणि तयार नसलेला pod errors देण्याऐवजी बाजूला होतो.
🚀 पुढे
DB checks /healthz मध्ये ठेवू नका, नाहीतर एका DB blip ने सगळे pods एकदम restart होतात; rollouts /readyz वर अवलंबून (L11).
🧪 Try it here — एक endpoint बिघडवा आणि kubelet ला तीन वेळा विचारू द्या
8 🍛 Requests & limits — वचन दिलेल्या थाळ्या आणि मर्यादित दुसरी वाढ
requests म्हणजे scheduler मोजतो त्या आरक्षणे; limits म्हणजे कठोर मर्यादा, CPU आणि memory साठी वेगळ्या शिक्षा.
🧒 सोप्या शब्दांत
शाळेच्या जेवणात प्रत्येक मूल आधीच ताट राखून ठेवते, म्हणजे आचाऱ्याला कळते प्रत्येक टेबलावर किती बसतील, आणि भांड्यावरचे झाकण एका मुलाने किती घ्यावे ते मर्यादित करते. Request (100m CPU, 128Mi memory) म्हणजे scheduler मोजतो ते राखीव ताट. Limit (500m, 256Mi) म्हणजे झाकण: जास्त CPU मुळे pod फक्त हळू होतो, जास्त memory मुळे तो थांबवून restart होतो.
📖 नवे शब्दrequest — तुम्ही आधीच राखून ठेवलेला वाटा; scheduler त्यावरून जागा शोधतोlimit — pod जास्तीत जास्त वापरू शकतो ते — भांड्यावरचे झाकण100m — CPU चे हजारावे भाग: 1000m म्हणजे एक पूर्ण CPU, म्हणून 100m म्हणजे दहावा भागOOMKilled — limit पेक्षा जास्त memory वापरल्यामुळे थांबवला (exit 137)
⏪ आधी
आरक्षणाशिवाय scheduler एका node वर खूप pods भरत असे, आणि एक हावरा pod बाकीच्यांना उपाशी ठेवू शकत असे.
💡 काय
Requests म्हणजे scheduler pod साठी राखून ठेवतो त्या ताटल्या; limits म्हणजे तो किती घेऊ शकतो ते मर्यादित करणारे झाकण.
⚙️ कसे
प्रत्येक pod 100m/128Mi request आणि 500m/256Mi limits ठेवतो; 500m वर CPU throttle होतो, 256Mi वर memory OOMKilled.
🎯 का
Scheduler प्रत्यक्ष वापर नाही तर requests ची बेरीज करतो, म्हणून प्रामाणिक आकडे nodes न्याय्य आणि pods योग्य जागी ठेवतात.
🚀 पुढे
Requests वरूनच autoscaling च्या टक्केवारी (L09) ठरतात आणि दबावात आधी कोण बाहेर जाते ते (L23) ठरते.
🧪 Try it here — pod ला त्याच्या मर्यादेपलीकडे ढकला (requests 100m/128Mi · limits 500m/256Mi)
9 🚌 Autoscaling — वाहतूक व्यवस्थापक बसांवर लक्ष ठेवतो
सरासरी CPU 70% वर गेल्यास pods वाढवतो (कमाल 5); शांत असताना ते उभे करतो (2 खाली कधीच नाही).
🧒 सोप्या शब्दांत
पावसाळी सकाळी जास्त मुलांना शाळेची बस हवी असते, म्हणून transport manager जास्त बसेस पाठवतो आणि शांत झाल्यावर त्या परत उभ्या करतो. HPA pods साठी हेच करतो: सरासरी CPU 70% च्या वर गेला की pods वाढवतो (कधीच 5 पेक्षा जास्त नाही), आणि शांत असताना कमी करतो (कधीच 2 पेक्षा कमी नाही). बस उभी करण्याआधी तो 5 मिनिटे शांतता वाट पाहतो.
📖 नवे शब्दHPA — transport manager, जो pods किती व्यस्त आहेत त्यानुसार ते वाढवतो किंवा कमी करतोtarget 70% — तो राखायचा प्रयत्न करतो तो सरासरी CPU, प्रत्येक pod च्या request शी तुलना करूनmin / max — कधीच 2 पेक्षा कमी pods नाहीत, कधीच 5 पेक्षा जास्त नाहीतmetrics-server — प्रत्येक pod किती CPU वापरतो ते मोजणारा मदतनीस
⏪ आधी
गर्दीच्या सकाळी कोणालातरी traffic पाहून हाताने pods वाढवावे लागत, आणि नंतर ते काढायचे लक्षात ठेवावे लागत.
💡 काय
HPA म्हणजे transport manager, जो सरासरी CPU 70% च्या लक्ष्याजवळ ठेवण्यासाठी pods वाढवतो किंवा उभे करतो.
⚙️ कसे
metrics-server CPU कळवतो; 85% वर HPA ceil(2 × 85 / 70) = 3 काढतो आणि replicas ठरवतो, नेहमी 2 ते 5 मध्ये.
🎯 का
Load आल्यावर सुमारे 15–30 s मध्ये वाढवतो आणि कमी करण्याआधी 5 min शांतता पाहतो, म्हणजे वापराइतकेच पैसे.
🚀 पुढे
HPA ला requests (L08) लागतात; pods मावेनासे झाले की cluster autoscaler नवे बाक जोडतो (L15).
🧪 Try it here — सरासरी CPU ठरवा आणि HPA ला गणित करू द्या (लक्ष्य 70%, किमान 2, कमाल 5)
सगळ्यासाठी एकच लोड बॅलन्सर; URL चा path ठरवतो पाहुणा कोणत्या Service पर्यंत पोहोचतो.
🧒 सोप्या शब्दांत
शाळेला एकच मुख्य दरवाजा असतो, आणि फलक पाहुण्यांना सांगतो: analytics office इकडे, बाकी सगळे सरळ पुढे. Ingress म्हणजे तो दरवाजा: संपूर्ण app साठी एक load balancer, जिथे URL चा path (/analytics किंवा /) पाहुणा कोणत्या Service कडे जाईल ते ठरवतो. एक दरवाजा म्हणजे एक बिल आणि एक certificate, प्रत्येक Service साठी वेगळे नाही.
📖 नवे शब्दIngress — एका दरवाजाचे नियम: कोणता path कोणत्या Service कडे जातोload balancer — दरवाजा स्वतः (इथे AWS ALB), जो पाहुण्यांना निरोगी pods कडे वाटतोpath — web पत्त्यातला नावानंतरचा भाग, जसे /analytics/reportTLS certificate — ज्यामुळे site https वापरू शकते, browser मधले कुलूप
⏪ आधी
प्रत्येक Service ला स्वतःचा load balancer लागत असे, म्हणजे अनेक bills आणि अनेक TLS certificates.
💡 काय
Ingress म्हणजे संपूर्ण शाळेसाठी एकच दरवाजा, जो फलकावरच्या URL path नुसार पाहुण्यांना पाठवतो.
⚙️ कसे
AWS LB controller ingress.yaml वरून ALB बांधतो: /analytics analytics कडे आणि / school-api कडे जाते.
🎯 का
एक Ingress म्हणजे प्रत्येक Service साठी एक नाही, तर एकच load balancer, एक bill आणि एक TLS certificate.
🚀 पुढे
दरवाजावर 503 म्हणजे सहसा Service मागे ready pods नाहीत; labels आणि /readyz तपासा (L04, L07).
🧪 Try it here — path टाका आणि कोणती Service उत्तर देते ते पहा
11 ⚽ Rollouts — एका वेळी एक खेळाडू बदला, बेंच ठेवा
मैदानावर नेहमी पूर्ण संघ; जुनी आवृत्ती तात्काळ rollback साठी बेंचवर राहते.
🧒 सोप्या शब्दांत
फुटबॉलच्या सामन्यात प्रशिक्षक एका वेळी एकच खेळाडू बदलतो, म्हणजे मैदानावरचा संघ कधीच कमी पडत नाही. Rolling update हेच करते: एक नवा v2 pod तयारी करतो, आणि तो तयार आहे असे सांगितल्यावरच एक जुना v1 pod बाहेर जातो. जुनी version बाकावर थांबते, म्हणून तिच्याकडे परत जायला (rollback) काही सेकंदच लागतात.
📖 नवे शब्दrolling update — जुने pods नव्यांनी एका वेळी एक बदलणे, कोणताही खंड न पडताmaxSurge: 1 — पूर्ण संघाशेजारी एक जास्तीचा खेळाडू तयारी करू शकतोmaxUnavailable: 0 — सेवा देणारा संघ पूर्ण (2) पेक्षा कधीच कमी नाहीrollback — बाकावरची जुनी version परत मैदानात आणणे
⏪ आधी
नवी version deploy करताना आधी जुनी थांबवावी लागत, त्यामुळे users ना downtime दिसे आणि rollback साठी पुन्हा build.
💡 काय
Rolling update एका वेळी एकच pod बदलतो, पूर्ण team खेळत राहते आणि जुनी version बेंचवर बसते.
⚙️ कसे
maxSurge 1 आणि maxUnavailable 0 सह, एक v2 तयार होतो, /readyz पास करतो, आणि मगच एक v1 बाहेर जातो.
🎯 का
नेहमी दोन pods सेवा देतात, आणि kubectl rollout undo जुना ReplicaSet काही सेकंदांत परत वाढवतो, rebuild नाही.
🚀 पुढे
कधीच ready न होणारा बिघडलेला v2 फक्त rollout थांबवतो; पुढे GitOps मुळे deploy म्हणजे git commit (L14).
🧪 Try it here — rolling update टप्प्याटप्प्याने पहा (maxSurge 1, maxUnavailable 0)
PVC टाकाऊ pods ना टिकाऊ कपाट देते; हा रेपो एक पाऊल पुढे जाऊन ग्रंथालयच भाड्याने घेतो (RDS).
🧒 सोप्या शब्दांत
विद्यार्थी नव्या बाकावर गेला की जुन्या बाकात राहिलेले सगळे जाते, पण ग्रंथालयाच्या फळीवरची पुस्तके राहतात. Pods बाकांसारखे आहेत: pod बदलला की त्याच्या स्वतःच्या files नाहीशा होतात. PVC म्हणजे ग्रंथालयाचे card, जे pod ला टिकणारी फळी (PV) देते. हा कोर्स एक पाऊल पुढे जाऊन database साठी संपूर्ण ग्रंथालय, RDS, भाड्याने घेतो.
📖 नवे शब्दPVC — ग्रंथालयाचे card: "10 Gi storage द्या" अशी मागणीPV — प्रत्यक्ष फळी (इथे EBS disk), जी कोणत्याही pod पेक्षा जास्त टिकतेStorageClass — कोणत्या प्रकारची फळी घ्यायची त्याचा नियम, जसे gp3RDS — भाड्याने घेतलेला database, जो AWS चालवते, backup घेते आणि दुरुस्त करते
⏪ आधी
Pod आत लिहिलेला data त्याच्यासोबत नाहीसा होत असे, जसे बाकासोबत फेकलेले दप्तर.
💡 काय
PVC म्हणजे library card, जे फेकून देता येणाऱ्या pods ना टिकाऊ फळी (PV, इथे EBS disk) देते.
⚙️ कसे
PVC "10 Gi, ReadWriteOnce" मागते, gp3 StorageClass फळी विकत घेते, आणि PV pods पेक्षा जास्त टिकते.
🎯 का
नव्या postgres pod ला तीच पुस्तके परत मिळतात, पण EBS disk फक्त ONE AZ मध्ये राहतो.
🚀 पुढे
हा repo त्याऐवजी library भाड्याने घेतो: RDS (terraform/rds.tf) तुमच्यासाठी backup, patch आणि failover करते.
🧪 Try it here — rows लिहा, pod मारा, काय टिकते ते पहा
कार्यालयातील पाच भूमिका, एक रजिस्टर, एक न संपणारा लूप: इच्छा → नोंद → जुळवणी → चालवणे → अहवाल.
🧒 सोप्या शब्दांत
शाळेच्या office मध्ये तुम्ही तुमची मागणी पुढच्या खिडकीवर देता, कारकून ती register मध्ये लिहितो, आणि वेगवेगळे कर्मचारी register वाचून काम पूर्ण करतात. kubectl apply असेच चालते: API server हा एकमेव दरवाजा, etcd हे register, scheduler machine निवडतो, आणि त्या machine वरचा kubelet container सुरू करून परत कळवतो.
📖 नवे शब्दAPI server — एकमेव दरवाजा; प्रत्येकजण त्याच्याशीच बोलतो, इतर कोणाशी नाहीetcd — register, जिथे प्रत्येक इच्छा आणि तिची स्थिती लिहिलेली असतेcontroller — इच्छा आणि वास्तव यांची तुलना करून फरक दुरुस्त करणारा मदतनीसscheduler — प्रत्येक नवा pod कोणत्या machine वर जाईल ते निवडणाराkubelet — प्रत्येक machine वरचा मदतनीस, जो प्रत्यक्ष containers सुरू करतो
⏪ आधी
kubectl apply जादूसारखे वाटत असे, म्हणून pod अडकला की cluster च्या कोणत्या भागाचा दोष ते कोणालाच कळत नसे.
💡 काय
Control plane म्हणजे एका register (etcd) भोवतीच्या पाच office भूमिका, ज्या इच्छेला चालू pods मध्ये बदलतात.
⚙️ कसे
API server इच्छा etcd मध्ये नोंदवतो, controllers pods बनवतात, scheduler त्यांना node देतो, आणि kubelet चालवतो.
🎯 का
सगळे फक्त API server शी बोलतात, म्हणून एखादी पायरी fail झाली की नेमके कुठे पाहायचे ते कळते.
🚀 पुढे
हाच watch-and-reconcile loop GitOps (L14) आणि तुमचे स्वतःचे operators (L25) चालवतो.
🧪 Try it here — kubectl apply कार्यालयातून एकेक टप्पा चालवा
CI प्रत्येक push वर test & build करतो; ArgoCD cluster च्या आत राहतो आणि तो प्लॅन-वहीशी (git) जुळता ठेवतो.
🧒 सोप्या शब्दांत
दोन robots ची कल्पना करा. गृहपाठ robot तुम्ही काम दिले की प्रत्येक वेळी ते तपासून बांधून ठेवतो; काळजीवाहू robot शाळेतच राहतो आणि प्रत्येक खोली आराखड्याच्या वहीप्रमाणे ठेवतो. CI हा पहिला: प्रत्येक git push वर तो test करतो, image build करून साठवतो. ArgoCD हा दुसरा: तो दर ~3 मिनिटांनी cluster ची git शी तुलना करतो आणि कोणताही फरक दुरुस्त करतो.
📖 नवे शब्दCI — बाहेरचा robot, जो प्रत्येक push वर test आणि build करतोGitOps — git म्हणजे आराखड्याची वही; cluster नेहमी तिच्याशी जुळलाच पाहिजेArgoCD — cluster मधला robot, जो त्याला git शी जुळवून ठेवतोgit revert — commit उलटवणे — इथे release मागे घेण्याचा मार्ग
⏪ आधी
लोक laptop वर images बनवून हाताने kubectl चालवत, त्यामुळे नेमके काय चालू आहे ते कोणालाच माहीत नसे.
💡 काय
CI म्हणजे प्रत्येक push वर test आणि build करणारा homework robot; ArgoCD म्हणजे cluster आतला काळजीवाहू robot.
⚙️ कसे
CI school-api:a1b2c3 ECR वर push करून tag git मध्ये commit करतो; ArgoCD दर ~3 min ला pull करून तुलना करतो.
🎯 का
Deploy म्हणजे git commit, rollback म्हणजे git revert, आणि हाताने केलेले बदल परत होतात कारण पुस्तकच नेहमी जिंकते.
🚀 पुढे
CI cluster ला कधीच हात लावत नाही आणि ArgoCD कधीच build करत नाही; ArgoCD school या robot चा सखोल अभ्यास करते.
🧪 Try it here — code push करा, मग cluster हाताने बदला आणि कोण जिंकते ते पहा
संपूर्ण वर्ग कधीच एका इमारतीत बसवू नका — आणि परीक्षेच्या दिवशी आधी सर्वात स्वस्त पायरी चढा.
🧒 सोप्या शब्दांत
शाळा संपूर्ण वर्ग कधीच एकाच इमारतीत बसवत नाही: त्या इमारतीची वीज गेली तर कोणालाच शिकता येत नाही. Multi-AZ प्रत्येक pod च्या copies वेगवेगळ्या data-centre इमारतींमध्ये (AZs) ठेवते, म्हणून एक बंद पडली तरी शाळा बंद होत नाही. गर्दीच्या दिवशी आधी सर्वात स्वस्त पायरी चढा: जास्त pods (सेकंदांत), मग जास्त machines (मिनिटांत).
📖 नवे शब्दAZ — Availability Zone: त्याच region मधली वेगळी data-centre इमारतtopologySpreadConstraints — pod च्या copies इमारतींमध्ये वाटून ठेवणारा नियमcluster autoscaler — pods ना बसायला जागा नसेल तेव्हा नवी machine जोडतोPDB — PodDisruptionBudget: सगळ्या copies एकदम जाणार नाहीत असे वचन
⏪ आधी
सगळ्या प्रती एकाच इमारतीत असल्याने, एका data-centre मधल्या आगीने संपूर्ण शाळा बंद पडत असे.
💡 काय
Multi-AZ pods वेगवेगळ्या इमारतींमध्ये (AZs) पसरवते, आणि scaling शिडी आधी कोणती पायरी चढायची ते सांगते.
⚙️ कसे
topologySpreadConstraints प्रती AZ a आणि b मध्ये वाटतात; HPA सेकंदांत pods, autoscaler मिनिटांत बाक जोडतो.
🎯 का
एका इमारतीला आग लागली तरी शाळा बंद होत नाही, आणि PDB खात्री करतो की सगळ्या प्रती एकदम कधीच जात नाहीत.
🚀 पुढे
तरीही काही बिघडले तर शांत triage पद्धत हवी, म्हणजेच debugging (L16).
जो कोणी आत येईल: आधी describe, Events नेहमी, crash loop साठी logs --previous.
🧒 सोप्या शब्दांत
मूल शाळेच्या परिचारिकेच्या खोलीत आले की परिचारिका अंदाज न लावता दर वेळी तीच यादी पाळते. बिघडलेला pod दुरुस्त करणे असेच आहे: आधी kubectl describe चालवून Events वाचा, मग पडलेला container का थांबला ते पाहायला logs --previous. Status चे नाव (Pending, ImagePullBackOff, CrashLoopBackOff, OOMKilled) chart ची कोणती ओळ पाळायची ते सांगते.
📖 नवे शब्दEvents — pod सोबत काय घडले त्याची Kubernetes ठेवते ती छोटी दैनंदिनीlogs --previous — मागच्या वेळी थांबण्याआधी container ने काय लिहिले तेPending — pod थांबलेला आहे कारण कोणत्याही machine वर त्याला जागा नाहीImagePullBackOff — डबा (image) आणता आला नाही — चुकीचा tag किंवा परवानगी नाही
⏪ आधी
आजारी pod दिसला की अंदाजाने गोष्टी restart केल्या जात, आणि चुकीच्या कारणावर तास वाया जात.
💡 काय
Debugging म्हणजे nurse चा triage chart: प्रत्येक आजारी pod साठी तीच चार पायऱ्यांची पद्धत.
⚙️ कसे
kubectl describe चालवून Events वाचा, मग logs --previous, मग get events --sort-by, मग exec किंवा endpointslices.
🎯 का
प्रत्येक लक्षण एका कारणाशी जोडलेले: Pending, ImagePullBackOff, CrashLoopBackOff, OOMKilled किंवा शांत Service.
🚀 पुढे
ही पद्धत आधीच्या धड्यांशी (L04, L06, L07, L08) जोडते आणि production मध्ये तुमची on-call सवय बनते.
🧪 Try it here — pod आजारी आहे — परिचारिकेच्या commands चालवा आणि निदान करा
Roles म्हणजे पास, bindings ते सोपवतात, ServiceAccounts म्हणजे रोबोटची ओळखपत्रे.
🧒 सोप्या शब्दांत
शाळेत प्रयोगशाळेत जायला पास लागतो, आणि शिक्षक पास वाटतात. RBAC असेच चालते: Role म्हणजे एका खोलीत तुम्ही काय करू शकता (जसे pods get आणि list करणे) याची यादी असलेला पास, आणि RoleBinding तो पास एखादी व्यक्ती, गट किंवा robot ला देतो. पास नाही तर प्रवेश नाही, म्हणून काहीही न देता सुरुवात करा आणि फक्त गरजेचे तेवढेच द्या.
📖 नवे शब्दRole — एका namespace (खोली) मध्ये परवानगी असलेल्या कृतींची यादी असलेला पासClusterRole — संपूर्ण इमारतीत चालणारा पासRoleBinding — हस्तांतर: Role एखादी व्यक्ती, गट किंवा robot ला देतेServiceAccount — व्यक्तीऐवजी program (robot) वापरतो ते ओळखपत्र
⏪ आधी
सगळे एकच admin key वापरत, त्यामुळे कोणतीही व्यक्ती किंवा robot cluster मधले काहीही delete करू शकत असे.
💡 काय
RBAC म्हणजे hall passes: Roles परवानगी असलेली verbs सांगतात, bindings ती देतात, ServiceAccounts robots ची cards.
⚙️ कसे
Role pod-reader school मध्ये pods वर get, list आणि watch ला परवानगी देतो; RoleBinding तो aishwarya ला त्या खोलीत देते.
🎯 का
Pass नाही तर प्रवेश नाही: kubectl auth can-i ने pass तपासता येतो, आणि चुका लहानच राहतात.
🚀 पुढे
शून्यापासून सुरू करून verbs जोडा, cluster-admin कधीच देऊ नका; ArgoCD सारख्या operators ना स्वतःची cards लागतात.
घंटा गृहपाठ तयार करते; गृहपाठ एक मूल तयार करतो; मूल पूर्ण करते आणि तोच मुद्दा.
🧒 सोप्या शब्दांत
गृहपाठ वर्गात बसण्यापेक्षा वेगळा असतो: तो करायचा, पूर्ण करायचा आणि द्यायचा. Deployment ला त्याचे pods कायम चालू हवे असतात, पण Job ला त्याचा pod पूर्ण व्हायला हवा असतो — exit 0 म्हणजे यश, crash नाही. CronJob म्हणजे शाळेची घंटा: दर रात्री 02:00 ला ती database चा backup घेणारा Job बनवते.
📖 नवे शब्दJob — काम पूर्ण होईपर्यंत pod चालवणारे आणि मग थांबणारे कामCronJob — वेळापत्रकानुसार नवा Job बनवणारी घंटाschedule — "0 2 * * *" म्हणजे दर रात्री 02:00 लाbackoffLimit — Job Failed ठरण्याआधी किती वेळा पुन्हा प्रयत्न (इथे 2)
⏪ आधी
Backup सारखी रात्रीची कामे कुठल्यातरी server च्या crontab वर असत, किंवा संपल्यावरही restart होणाऱ्या pods मध्ये.
💡 काय
Job एक pod काम संपेपर्यंत चालवतो; CronJob म्हणजे वेळापत्रकानुसार Job तयार करणारी घंटा.
⚙️ कसे
CronJob school-db-backup "0 2 * * *" schedule ने 02:00 ला pg_dump करून S3 ला पाठवतो, backoffLimit: 2 retries सह.
🎯 का
Exit 0 म्हणजे यश, crash नाही, आणि cluster शेवटच्या 3 यशस्वी आणि 1 अयशस्वी runs चा इतिहास ठेवतो.
🚀 पुढे
kubectl create job --from=cronjob ने आत्ताच घंटा वाजवा, आणि spec.timeZone नसेल तर cron वेळा UTC असतात.
🧪 Try it here — schedule निवडा आणि पुढच्या घंटा पहा (UTC), मग अस्थिर job चालवा
नियम नसतील तर वर्गातला कोणीही विद्यार्थी कोणालाही चिठ्ठी देऊ शकतो. NetworkPolicy म्हणजे कोण कोणाला चिठ्ठी देऊ शकतो याचा शिक्षकांचा नियम. आधी "कोणतीच चिठ्ठी नाही" (default-deny) असे सांगा, मग app ला गरजेचे तेवढेच बोलणे परवानगी द्या: gate आणि analytics api पर्यंत पोहोचू शकतात, आणि database पर्यंत फक्त api.
📖 नवे शब्दNetworkPolicy — कोणते pods कोणत्या pods ना traffic पाठवू शकतात ते सांगणारा नियमdefault-deny — आधी सगळे बंद करा, मग फक्त गरजेचे तेवढेच उघडाCNI — network मदतनीस, ज्याने नियम पाळायला लावले पाहिजेत, नाहीतर ते दुर्लक्षित होतात
⏪ आधी
Default ने प्रत्येक pod प्रत्येक pod शी बोलू शकतो, त्यामुळे hack झालेला analytics pod थेट database शी बोलू शकत असे.
💡 काय
NetworkPolicy म्हणजे चिठ्ठ्या पाठवण्याचा नियम, जो कोणता pod कोणत्या pod ला traffic पाठवू शकतो ते सांगतो.
⚙️ कसे
podSelector: {} आणि policyTypes [Ingress] सगळे नाकारतात, मग api ला gate व analytics कडून, db ला फक्त api कडून परवानगी.
🎯 का
फक्त app ला हवी असलेली संभाषणेच परवानगीत असतात; analytics कडून db कडे जाणारे traffic शांतपणे टाकले जाते.
🚀 पुढे
यासाठी Calico किंवा policies चालू असलेला VPC CNI सारखा enforce करणारा CNI लागतो, म्हणून नेहमी test करा.
🧪 Try it here — चिठ्ठ्यांचे नियम लिहा, मग चिठ्ठी पाठवा
बाकांवरील पाट्या दूर ढकलतात; चिठ्ठ्या परवानगी देतात; इच्छा आकर्षित करतात; anti-affinity जुळ्यांना वेगळे करते.
🧒 सोप्या शब्दांत
काही बाक राखीव असतात: विज्ञान-प्रयोगशाळेच्या बाकावरची पाटी सांगते की तिथे फक्त प्रयोगशाळेचे विद्यार्थी बसू शकतात. परवानगीची चिठ्ठी नसलेल्याला परत पाठवले जाते, चिठ्ठी असलेला तिथे बसू शकतो, आणि तो बाक मागणाऱ्याला तिथेच पाठवले जाते. Kubernetes मध्ये पाटी म्हणजे node वरचा taint, चिठ्ठी म्हणजे toleration, आणि इच्छा म्हणजे node affinity.
📖 नवे शब्दtaint — node वरची पाटी, जी साध्या pods ना दूर ठेवतेtoleration — pod वरची चिठ्ठी: "मी त्या बाकावर बसू शकतो"node affinity — pod वरची इच्छा: "मला त्याच बाकावर बसायचे आहे"anti-affinity — एकाच app च्या दोन copies कधीच एका बाकावर ठेवू नका
⏪ आधी
साधे pods महागड्या GPU nodes वर बसत, आणि api च्या दोन्ही प्रती एकाच node वर येऊ शकत.
💡 काय
Taints आणि affinity म्हणजे ठरलेली बैठक: बाकावरच्या पाट्या दूर ठेवतात, चिठ्ठ्या परवानगी देतात, इच्छा आकर्षित करतात.
⚙️ कसे
Taint gpu=true:NoSchedule node वर असतो; ml-train कडे toleration (बसू शकतो) आणि nodeAffinity (बसायचे आहे) असतात.
🎯 का
खास बाक गरज असलेल्या pods साठीच मोकळे राहतात, आणि anti-affinity जुळ्या api pods ना वेगळ्या बाकांवर ठेवते.
🚀 पुढे
एक बाक मेला तरी दुसरे जुळे सेवा देत राहते: बाकाच्या पातळीवर high availability, L15 वर आधारित.
🧪 Try it here — pod बसवा — gpu बाकावर taint gpu=true:NoSchedule आहे
replica संख्या नाही: nodes ची यादी हीच संख्या. नवा बाक, नवा अग्निशामक, आपोआप.
🧒 सोप्या शब्दांत
शाळेच्या प्रत्येक मजल्यावर एक अग्निशामक असतो: कोणी संख्या ठरवत नाही, कारण मजल्यांची संख्या हीच संख्या. DaemonSet प्रत्येक node वर pod ची नेमकी एक copy चालवतो, जसे log agent किंवा kube-proxy. Cluster मध्ये नवा node आला की त्याची copy आपोआप येते, तुम्हाला काहीही बदलावे लागत नाही.
📖 नवे शब्दDaemonSet — प्रत्येक node वर pod ची एक copy चालवतो — संख्या ठरवायची नाहीnode — cluster मधली एक machine (मजला)log agent — apps जे लिहितात ते गोळा करून पुढे पाठवणारा मदतनीसkube-proxy — प्रत्येक node वरचा मदतनीस, जो Service नंबर चालू ठेवतो
⏪ आधी
Log shippers सारखे agents प्रत्येक node वर हाताने install करावे लागत, आणि नवे nodes सहज विसरले जात.
💡 काय
DaemonSet प्रत्येक node वर एका pod ची नेमकी एक प्रत चालवतो, जसे प्रत्येक मजल्यावर एक अग्निशामक.
⚙️ कसे
त्यात replicas field नसते: nodes ची यादी हीच संख्या, म्हणून autoscaler ने node-3 जोडला की त्याचा agent पण येतो.
🎯 का
काहीही न मोजता किंवा न आठवता प्रत्येक node ला नेहमी त्याचा log agent आणि network भाग मिळतात.
🚀 पुढे
तुम्ही ते आधीच चालवता: aws-node (CNI) आणि kube-proxy हे DaemonSets आहेत, आणि logging agents L26 ला data देतात.
🧪 Try it here — nodes जोडा आणि काढा; अग्निशामक मोजा
बहुतेक वर्गांत कोणीही कोणत्याही बाकावर बसू शकतो, पण परीक्षा-हॉलमध्ये प्रत्येक बाकावर नावाची पाटी आणि स्वतःचा ड्रॉवर असतो. StatefulSet pods ना ठरलेली नावे (postgres-0, postgres-1) आणि स्वतःचे storage देतो, आणि त्यांना एकामागून एक सुरू करतो. postgres-1 बदलला तर नव्याचे नावही postgres-1 च असते आणि त्याला तोच ड्रॉवर परत मिळतो.
📖 नवे शब्दStatefulSet — Deployment सारखा, पण प्रत्येक pod त्याचे नाव आणि स्वतःचे storage ठेवतोstable name — बदलल्यानंतरही postgres-0 हा postgres-0 च राहतोheadless Service — कोणत्याही pod ऐवजी नेमक्या एका pod ला नावाने बोलावू देतेordered start — pod 0 तयार झाल्यावरच pod 1 सुरू होतो
⏪ आधी
Deployment बदली database pod ला random नाव देत असे आणि ड्रॉवर नाही, त्यामुळे त्याची ओळख आणि data हरवत.
💡 काय
StatefulSet प्रत्येक pod ला नावाची पाटी, स्वतःचा ड्रॉवर (PVC), आणि एकामागून एक क्रमाने येणे देतो.
⚙️ कसे
postgres-0 ready झाल्यावरच postgres-1 येतो; तो मेला तर नवा postgres-1 पुन्हा data-postgres-1 जोडतो.
🎯 का
प्रत्येक pod नावाने पोहोचता येतो, जसे headless Service द्वारे postgres-0.postgres.school.svc.
🚀 पुढे
हे ओळख देते, replication किंवा failover नाही; त्यासाठी operator (L25) लागतो, किंवा library भाड्याने घ्या (RDS, L12).
🧪 Try it here — प्रत्येक प्रकारातला एक pod delete करा आणि काय परत येते त्याची तुलना करा
BestEffort, मग जास्त-वचन देणारे Burstable, मग Guaranteed — तुमचे requests हीच तुमची क्रमवारी.
🧒 सोप्या शब्दांत
जेवणाच्या हॉलमध्ये खूप गर्दी झाली की कोणाला तरी आधी बाहेर जावे लागते, आणि ते म्हणजे ज्यांनी जागा राखलीच नव्हती. Node ची memory संपली की kubelet pods ना क्रमाने बाहेर काढतो: आधी BestEffort (requests नाहीत), मग Burstable (आपल्यासारखे, limit पेक्षा कमी मागणारे), आणि शेवटी Guaranteed. तुमचे requests रांगेतली तुमची जागा ठरवतात.
📖 नवे शब्दeviction — memory मोकळी करायला kubelet ने pod ला node वरून काढणेBestEffort — requests नाहीत आणि limits नाहीत — सर्वात आधी जातोBurstable — requests limits पेक्षा कमी, आपल्यासारखे (100m/128Mi < 500m/256Mi)Guaranteed — प्रत्येक container साठी requests = limits — शेवटी जातो
⏪ आधी
Node ची memory संपल्यावर कोणते pods आधी बाहेर काढले जातील हे एक गूढ असे.
💡 काय
QoS classes eviction साठी pods ना क्रम देतात: BestEffort आधी जातो, मग Burstable, आणि Guaranteed शेवटी.
⚙️ कसे
97% memory वर kubelet आधी class नुसार, मग request पेक्षा किती जास्त त्यानुसार evict करतो; आपला Burstable आहे.
🎯 का
तुमच्या requests म्हणजेच रांगेतली तुमची जागा, म्हणून त्या प्रामाणिकपणे ठेवल्या तर दबावात app सुरक्षित राहते.
🚀 पुढे
PriorityClass CoreDNS आणि CNI सारख्या staff ला टिकवते, आणि high-priority Pending pod कमी priority वाल्यांना हटवू शकतो.
🧪 Try it here — node ची memory संपते — सुरक्षित होईपर्यंत हकालपट्टी करा
आधी कार्यालय, मग बाकामागून बाक: cordon, drain (PDB पहाऱ्यावर), बदला, uncordon.
🧒 सोप्या शब्दांत
काळजीपूर्वक केले तर सत्र चालू असतानाही शाळा रंगवता येते: आधी office, मग मुले शेजारच्या वर्गात जात असताना एका वेळी एक वर्ग. Cluster upgrade असेच आहे: control plane एका version ने upgrade करा, मग प्रत्येक node ला cordon करा, drain करा, बदला आणि uncordon करा. PodDisruptionBudget किमान एक api pod सेवा देत राहील याची खात्री करते.
📖 नवे शब्दcontrol plane — office: cluster चालवणारे API server आणि त्याचे साथीदारcordon — node वर "इथे नवे pods नाहीत" अशी पाटी लावणेdrain — node बदलण्याआधी त्यावरचे सगळे pods नीटपणे हलवणेPodDisruptionBudget — पहारेकरी: minAvailable 1 म्हणजे एक pod नेहमी राहिलाच पाहिजे
⏪ आधी
Kubernetes upgrade म्हणजे संपूर्ण शाळा बंद ठेवून एका भीतीदायक weekend ला सगळे एकदम बदलणे.
💡 काय
Cluster upgrade शाळा चालू ठेवून दुरुस्ती करतो: आधी office (control plane), मग बाक (nodes) एकेक करून.
⚙️ कसे
EKS 1.30 वरून 1.31 करा, मग प्रत्येक node साठी: cordon, drain (PDBs पहाऱ्यावर), kubelet 1.31 ने बदला, uncordon.
🎯 का
PDB minAvailable: 1 मुळे दुसरा api pod ready होईपर्यंत drain थांबतो, त्यामुळे app कधीच बंद पडत नाही.
🚀 पुढे
बाक office पेक्षा एक-दोन versions मागे राहू शकतात, पुढे कधीच नाही; पायरी 1 आधी deprecation notes वाचा.
🧪 Try it here — cluster upgrade करा; school-api चे 2 replicas आणि PDB minAvailable 1 आहे
रजिस्टरमधला एक शब्द आणि तो खरा करणारा रोबोट — ArgoCD चे रहस्य उलगडले.
🧒 सोप्या शब्दांत
कल्पना करा, शाळेच्या office ला BackupPlan हा अगदी नवा शब्द शिकवला, आणि मग प्रत्येक BackupPlan वाचून तो प्रत्यक्षात आणणारा मदतनीस robot नेमला. CRD हा नवा शब्द Kubernetes ला शिकवतो, आणि controller म्हणजे तो robot; तज्ज्ञांचे ज्ञान आत घालून दोघे मिळून operator म्हणवतात. ArgoCD चे Application हा असाच एक शब्द आहे.
📖 नवे शब्दCRD — Kubernetes ला नवीन प्रकारची गोष्ट शिकवते, जसे BackupPlancustom resource — नव्या शब्दात लिहिलेली एक इच्छा, जसे "रोज रात्री, 7 ठेवा"controller — त्या इच्छांवर लक्ष ठेवून त्या खऱ्या करणारा robotoperator — CRD आणि त्याचा controller, तज्ज्ञांच्या ज्ञानासह
⏪ आधी
Kubernetes ला फक्त Pod आणि Deployment सारखे अंगभूत शब्द माहीत होते, म्हणून खास गरजांसाठी cluster बाहेर scripts लागत.
💡 काय
CRD office ला नवा शब्द शिकवते, आणि controller तो खरा करणारा robot आहे; दोघे मिळून operator.
⚙️ कसे
kind: BackupPlan schedule "0 2 * * *" आणि keep: 7 सह apply करा; controller CronJob बनवतो आणि जुने backups छाटतो.
🎯 का
तुमच्या नव्या नामाला kubectl get, RBAC आणि L03 सारखा reconcile loop मिळतो, सगळे API server मार्फत.
🚀 पुढे
तुम्ही ते आधीपासूनच वापरत आहात: ArgoCD Application, cert-manager Certificate आणि CloudNativePG Cluster.
🧪 Try it here — कार्यालयाला नवा शब्द शिकवा, एका वेळी एक टप्पा
प्रगतिपुस्तके (metrics), डायऱ्या (logs), धोक्याच्या घंटा (alerts) — आणि सगळ्यासाठी एकच स्क्रीन.
🧒 सोप्या शब्दांत
शाळा कशी चालली आहे ते तिला प्रगती-पुस्तके, रोजच्या दैनंदिनी आणि काही चुकले की वाजणारी घंटा यावरून कळते. Apps ना हीच तीन मिळतात: metrics (Prometheus दर 30 s ला गोळा करतो ते आकडे), logs (लिहिलेली दैनंदिनी), आणि errors 5 मिनिटे 1% च्या वर राहिल्या की कोणाला तरी बोलावणारे alerts. Grafana हे सगळे एका screen वर दाखवते.
📖 नवे शब्दmetrics — वेळेनुसार मोजलेले आकडे, जसे किती requests अयशस्वी झाल्याlogs — app काम करताना लिहिते त्या ओळी — तिची दैनंदिनीalert — नियम मोडला की on-call व्यक्तीला बोलावणारी घंटाPrometheus — प्रत्येक pod कडून metrics गोळा करून इतिहास ठेवणारे toolGrafana — metrics आणि logs एकत्र दाखवणारी एक screen
⏪ आधी
Monitoring शिवाय, outages बद्दल तुमच्या स्वतःच्या screens वरून नाही तर रागावलेल्या users कडून कळत असे.
💡 काय
Observability म्हणजे प्रगतीपुस्तके (metrics), रोजनिशी (logs) आणि धोक्याच्या घंटा (alerts), सगळे एकाच screen वर.
⚙️ कसे
Prometheus दर 30 s ला /metrics गोळा करतो, DaemonSet agent logs पाठवतो, आणि 5m साठी 5xx > 1% झाले की Alertmanager कळवतो.
🎯 का
Grafana चार प्रश्नांची उत्तरे पटकन देते: चालू आहे का, errors येतात का, हळू आहे का, आणि cluster निरोगी आहे का?
🚀 पुढे
एका dashboard ने सुरुवात करा आणि तुमची खरी team production चालवताना on-call alerts आणि SLOs पर्यंत वाढा.
🧪 Try it here — dials फिरवा; 5 मिनिटे 5xx > 1% असेल तर alert वाजतो