← कोर्सच्या मुख्य पानाकडे परत

⏮️ आधी काय होते & फायदे-तोटे

प्रत्येक साधनाने काहीतरी वाईट गोष्ट बदलली — आणि तेच साधन कुठेतरी चुकीचे ठरते. या कोर्समधील प्रत्येक मोठ्या कल्पनेसाठी: ती येण्याआधी जीवन कसे होते, तिचे प्रामाणिक फायदे ✅ आणि तोटे ❌, आणि कुठे वापरावी 👍 विरुद्ध कुठे नाही 👎.

☸️ खुद्द Kubernetes — संपूर्ण कोर्स

⏮️ Kubernetes च्या आधी (2014 मध्ये ओपन-सोर्स)

हाताने सांभाळलेल्या VM चे ताफे: प्रत्येक VM वर एक ॲप, SSH + shell स्क्रिप्ट किंवा Ansible ने deploy, हाताने बदललेले लोड बॅलन्सर, scaling = infra टीमकडे तिकीट, आणि पहाटे 3 वाजता पेजर वाजतो कारण एक प्रोसेस मेली आणि काहीही तिला पुन्हा चालू केले नाही. Google ने एक दशक अंतर्गत उत्तर (Borg) चालवले; Kubernetes ही तीच कल्पना, सार्वजनिक. मधल्या काळात Heroku-सारखे PaaS होते — सुंदर सोपे, पण मर्यादित आणि मोठ्या प्रमाणावर महाग — आणि "एका मोठ्या VM वर docker-compose", म्हणजे ट्रेंच कोट घातलेला single point of failure.

✅ फायदे

  • स्व-उपचार — कोसळलेले pod माणसाशिवाय परत येतात
  • declarative इच्छित स्थिती (कोर्सची मोठी कल्पना)
  • rolling deploy, autoscaling, service discovery अंगभूत
  • कुठेही चालते — EKS, GKE, on-prem, लॅपटॉप

❌ तोटे

  • शिकण्याचा चढ खडा (म्हणूनच… 26 धडे 😄)
  • नुसते अस्तित्वात असण्याचेही पैसे (EKS ≈ $73/महिना, नोड्सशिवाय)
  • YAML चा पसारा; दुसऱ्या दिवसाची कामे: अपग्रेड, add-ons, CVE
  • एका छोट्या ॲपसाठी प्रचंड अतिरेक

👍 वापरा जेव्हा

  • अनेक services/टीम, किंवा खरी scaling ची गरज
  • uptime इतके महत्त्वाचे की redundancy साठी पैसे मोजावे
  • तुम्ही आधीच containerized आहात आणि एक मशीन पुरत नाही

👎 दोनदा विचार करा जेव्हा

  • एक ॲप, छोटी टीम → Cloud Run / App Runner / compose
  • कोणाकडेच ops साठी वेळ नाही — managed PaaS प्रामाणिक पर्याय
  • static साइट किंवा cron job (खरंच, नको)

आकृत्या ↗

🏫 Ingress — धडा 10

⏮️ Ingress च्या आधी

एकतर प्रत्येक service साठी एक क्लाउड लोड बॅलन्सर — प्रत्येकाचे खरे पैसे, गुणिले प्रत्येक service, गुणिले प्रत्येक environment — किंवा हाताने चालवलेली nginx VM जी एकच धाडसी व्यक्ती समजू शकत असे. Ingress ने "एक गेट, अनेक खोल्या" ही declarative वस्तू बनवली.

✅ फायदे

  • अनेक services साठी एकच लोड बॅलन्सर (एकच बिल)
  • path/host routing + TLS एकाच घोषित जागी
  • service जोडणे = आणखी एक नियम, आणखी हार्डवेअर नाही

❌ तोटे

  • controller add-on लागतो (ALB controller, nginx…)
  • annotation चा पसारा controller नुसार वेगळा
  • HTTP(S)-आकाराचे; कच्च्या TCP/UDP ला वेगळी दारे लागतात

👍 वापरा जेव्हा

  • 2+ HTTP services एक domain/LB वाटून घेतात
  • तुम्हाला केंद्रीय TLS आणि routing नियम git मध्ये हवेत

👎 दोनदा विचार करा जेव्हा

  • नेमकी एकच service → LoadBalancer Service सोपी
  • HTTP नसलेले प्रोटोकॉल (डेटाबेस, गेम सर्व्हर)

आकृती ↗

🚌 Autoscaling (HPA) — धडा 09

⏮️ autoscaling च्या आधी

क्षमता-नियोजनाच्या बैठका. तुम्ही peak load चा अंदाज केलात, तेवढे सर्व्हर विकत घेतलेत, आणि मंगळवारी पहाटे 3 वाजताही त्यांचे पैसे भरलेत. अंदाज चुकला? एकतर निकालाच्या दिवशी outage किंवा रिकाम्या लोखंडाचे रॅक. "Scaling" म्हणजे क्रिकेटच्या फायनलदरम्यान माणसाने बटणे दाबणे.

✅ फायदे

  • क्षमता प्रत्यक्ष load च्या वक्रावर चालते
  • peak साठी provisioning ऐवजी शांत रात्रींचे पैसे
  • पहाटे 3 वाजता माणसाने scaling नाही

❌ तोटे

  • metrics-server + प्रामाणिक resource requests लागतात
  • मिनिटांत प्रतिसाद — अचानक spikes तरीही दुखतात
  • गळत्या लपवू शकते (दुरुस्तीऐवजी scaling)
  • replicas ठरवणाऱ्या इतर कोणाशीही भांडते (GitOps: ते field दुर्लक्षित करा)

👍 वापरा जेव्हा

  • traffic खरोखर बदलतो (दिवस/रात्र, ऋतू, कार्यक्रम)
  • CPU/memory load ला बऱ्यापैकी अनुसरतात

👎 दोनदा विचार करा जेव्हा

  • सपाट traffic — निश्चित replicas सोपे आणि अंदाजे
  • scale-to-zero ची स्वप्ने → ते serverless/Knative चे क्षेत्र
  • सेकंदांत spike होणारा load → आधी warm करा किंवा queue वापरा

आकृती ↗

🚪 Namespaces (विरुद्ध वेगळे clusters) — धडा 05

⏮️ namespaces च्या आधी

isolation म्हणजे प्रत्येक टीम/प्रोजेक्टसाठी संपूर्ण cluster (किंवा VM ताफा) — कमाल वेगळेपणा, कमाल बिले, आणि cluster अपग्रेडमध्ये बुडालेली ops टीम. Namespaces ने एका इमारतीत हलक्या खोल्या दिल्या.

✅ फायदे

  • दुसरा cluster न विकत घेता isolation
  • प्रत्येक खोलीसाठी quota आणि प्रवेश नियम
  • स्वच्छ blast radius: खोली हटवा, शाळा नाही

❌ तोटे

  • सामायिक control plane — एका cluster अपग्रेडचा धोका सर्व खोल्यांना
  • quota/taints नसतील तर गोंगाट करणारे शेजारी nodes वाटून घेतात
  • शत्रू tenants साठी कठोर सुरक्षा सीमा नाही

👍 वापरा जेव्हा

  • एका विश्वासू संस्थेतील टीम/environments
  • पैसे वाचवण्यासाठी dev/staging एक cluster वाटून घेतात

👎 दोनदा विचार करा जेव्हा

  • compliance ला कठोर isolation हवे → वेगळे clusters
  • अविश्वसनीय तृतीय-पक्ष workloads चालवणे

आकृती ↗

📚 Managed डेटाबेस (RDS) विरुद्ध cluster मध्ये — धडा 12

⏮️ managed डेटाबेसच्या आधी

एक DBA (किंवा सर्वात दुर्दैवी डेव्हलपर) हाताने डेटाबेस सर्व्हर सांभाळत असे: install, patch, कोणीही न तपासलेले backup, आणि घामाच्या हातांनी live केलेले failover. RDS-सारख्या सेवांनी (2009+) याचे भाड्याच्या, स्वयंचलित ग्रंथपालात रूपांतर केले.

✅ फायदे (managed)

  • backup, patching, failover — दुसऱ्या कोणाची पहाट 3
  • cluster stateless राहतो = प्रत्येक k8s धडा सोपा राहतो
  • encryption, snapshots, restore सराव अंगभूत

❌ तोटे (managed)

  • कच्च्या compute पेक्षा महाग
  • कमी नियंत्रण (आवृत्त्या, extensions, खास tuning)
  • थोडे vendor वर अवलंबित्व

👍 Managed, जेव्हा

  • production डेटा + छोटी टीम (या रेपोची निवड)
  • खरे डेटाबेस ऑपरेशन्स सांभाळायला माणसे नाहीत

👎 cluster मध्ये, जेव्हा

  • dev/test environments (स्वस्त, टाकाऊ)
  • कुशल टीम + operator (CloudNativePG इ.)
  • तो डेटाबेस managed सेवा म्हणून उपलब्ध नाही

आकृती ↗