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

📊 Cheat sheet — सगळे गोंधळतात त्या पाच तुलना

एक पान, पाच तक्ते, प्रत्येक ओळीला शाळेची उपमा — आणि एक "कधी नाही" ओळ, कारण चुकीची वस्तू ही Kubernetes मधली सर्वात सामान्य चूक. प्रिंट करा; आकृत्या आणि triage card शेजारी लावा.

🧑‍🏫 Deployment विरुद्ध StatefulSet विरुद्ध DaemonSet (धडे 03, 22, 21)

DeploymentStatefulSetDaemonSet
उपमावर्गप्रमुख — "नेहमी N", कोणताही बाकनावाच्या पाट्या असलेले बाकप्रत्येक मजल्यावर एक अग्निशामक
Pods असतातअदलाबदल करता येणारे, यादृच्छिक नावेचिकट नावे (postgres-0), क्रमाने सुरू/बंदप्रत्येक node वर नेमका एक
Storageसामायिक किंवा काहीच नाहीप्रत्येक pod चा स्वतःचा PVC, नावाने पुन्हा जोडलेलासहसा host paths / node-स्थानिक
Scalingreplicas + HPAreplicas, क्रमाने; HPA क्वचितnodes ची यादी हीच संख्या
कशासाठीstateless ॲप्स, APIs, workersडेटाबेस, brokers, ओळख असलेले काहीहीlog shippers, CNI, node agents, kube-proxy
कधी नाहीस्थिर ओळख किंवा स्वतःची डिस्क लागणारे काहीहीstateless ॲप्स (हळू rollouts) — आणि prod डेटासाठी RDS ला पसंतीnode नुसार नव्हे, load नुसार वाढणारी ॲप्स

आकृती ↗

☎️ Service चे प्रकार + Ingress (धडे 04, 10)

ClusterIPNodePortLoadBalancerIngress
उपमाशाळेच्या आतला रिसेप्शन डेस्कप्रत्येक इमारतीला एक बाजूची खिडकीप्रत्येक service साठी क्लाउड रिसेप्शन डेस्क (ALB/NLB)मुख्य गेट + फलक, अनेक खोल्या
कुठून पोहोचता येतेफक्त cluster च्या आतूनकोणत्याही node चा IP : 30000–32767इंटरनेट, प्रत्येकी एक क्लाउड LBइंटरनेट, अनेक services साठी एक LB
वाट कशानेselector → तयार podsतेच, node port मार्गेतेच, LB मार्गेhost / path → Services
खर्चमोफतमोफत (पण कुरूप)प्रत्येक service ला क्लाउड LB चे बिलएक LB + एक controller add-on
कशासाठीservice-ते-service (मूळ पर्याय)स्थानिक डेमो, bare metal युक्त्याएकच HTTP-नसलेला प्रवेश (DB, गेम सर्व्हर)HTTP(S) साइट आणि APIs — नेहमीचे पुढचे दार
कधी नाहीबाहेरून पोहोचायचे काहीहीproduction trafficदहा HTTP services = दहा बिले → Ingressकच्चे TCP/UDP — LoadBalancer Service वापरा

आकृती ↗

🙋 Liveness विरुद्ध readiness विरुद्ध startup probes (धडा 07)

LivenessReadinessStartup
प्रश्न"जागा आहेस?""उत्तर द्यायला तयार?""जागा होणे संपले का?"
फसल्यावरकंटेनर पुन्हा सुरूService च्या endpoints मधून काढला — पुन्हा सुरू नाहीपास होईपर्यंत liveness/readiness बंद ठेवतो
नेहमीचा endpoint/healthz — साधा, स्वस्त/readyz — dependencies तपासतोliveness सारखाच, उदार failureThreshold
AWS मधला भाऊ—ALB चा health check (AWS L15)—
कधी नाहीDB तपासणारा probe — DB च्या outage साठी तुम्ही ॲप पुन्हा सुरू करालनेहमी "तयार" असणारा probe — सुरू होताना trafficपटकन सुरू होणारी ॲप्स — फक्त initialDelaySeconds ठेवा

आकृती ↗

🍛 Requests विरुद्ध limits + QoS classes (धडे 08, 23)

RequestsLimits
उपमावचन दिलेली थाळीदुसऱ्या वाढीवरची मर्यादा
कोण वाचतेscheduler — requests बसतील तिथेच pods ठेवतोkubelet/kernel — चालू असताना लागू करतो
CPU ओलांडले—throttled (हळू, जिवंत)
Memory ओलांडली—OOMKilled 💀
QoS classGuaranteed = requests == limits · Burstable = requests < limits · BestEffort = काहीच नाही — दबावाखाली सर्वात आधी काढला
कधी नाही"सगळे वापरू द्या" म्हणून requests नाहीत — BestEffort, सर्वात आधी बाहेरrequests पेक्षा खूप वरचे limits — over-commit जे शेजाऱ्याला OOMKill करते

आकृती ↗

🚫 NetworkPolicy विरुद्ध security group (धडा 19 · AWS L10/L21)

NetworkPolicySecurity group (EKS nodes/pods)
उपमाबाकांमधले चिठ्ठ्या पाठवण्याचे नियमइमारतीच्या डेस्कवरची पाहुण्यांची यादी
लागू होतेpods, label selector नेENIs — nodes (किंवा SG-for-pods सह pods)
मूळप्रत्येक pod प्रत्येक pod शी बोलतोसगळे inbound नाकारले
दिशाingress आणि egress, प्रत्येक policy साठीinbound नियम; stateful उत्तरे
लागू करणाराCNI (Calico, VPC CNI policy mode) — लागू करणारा नसेल तर दुर्लक्षितAWS, नेहमी
कशासाठीcluster च्या आतले pod-ते-pod नियमबाहेरून nodes/ALB पर्यंत कोण पोहोचू शकते
कधी नाहीतुमची एकमेव सीमा म्हणून — ALB/WAF आणि SG रस्त्याचा पहारा देतातबारीक pod-ते-pod नियम — ते NetworkPolicy चे काम

आकृती ↗