CNCF Kubernetes and Cloud Native Associate
अंतिम समीक्षा: मई 2026
KCNA परीक्षा द्वारा परखे जाने वाले architectural patterns का स्कैन-योग्य संदर्भ। ऊपर से नीचे पढ़ें या किसी section पर जाएं।
सबसे छोटी संभव, सह-स्थित कार्यभार इकाई को डिप्लॉय करें।
`Pod` संसाधन को परिभाषित करें। पॉड्स में एक या एक से अधिक कंटेनर हो सकते हैं जो नेटवर्क और स्टोरेज साझा करते हैं।
क्यों: Pod कुबेरनेट्स में शेड्यूलिंग की एटॉमिक इकाई है। कंटेनरों को हमेशा एक Pod के भीतर डिप्लॉय किया जाता है।
सुनिश्चित करें कि क्लस्टर की स्थिति लगातार वांछित स्थिति से मेल खाती रहे।
`kube-controller-manager` पर निर्भर रहें। यह कंट्रोल लूप चलाता है जो संसाधनों (जैसे, ReplicaSets, Deployments) की निगरानी करता है और अंतरों का समाधान करता है।
क्यों: यह मूल घोषणात्मक, स्वयं-ठीक होने वाली प्रणाली है। यदि किसी ReplicaSet द्वारा प्रबंधित कोई Pod बंद हो जाता है, तो कंट्रोलर उसे स्वचालित रूप से बदल देता है।
नए बनाए गए Pods को स्वचालित रूप से सबसे उपयुक्त वर्कर नोड पर असाइन करें।
`kube-scheduler` पर निर्भर रहें। यह Pod की आवश्यकताओं (जैसे, रिसोर्स रिक्वेस्ट) के आधार पर नोड्स को फ़िल्टर करता है और सबसे उपयुक्त का चयन करने के लिए उन्हें स्कोर करता है।
क्यों: शेड्यूलर नीति, एफिनिटी और उपलब्धता के आधार पर प्लेसमेंट निर्णय लेता है, जिससे उपयोगकर्ता से नोड चयन को अमूर्त करता है।
सुनिश्चित करें कि Pods में निर्दिष्ट कंटेनर दिए गए वर्कर नोड पर चल रहे हैं और स्वस्थ हैं।
`kubelet` एजेंट हर नोड पर चलता है, API सर्वर के साथ संचार करता है, और कंटेनर रनटाइम के माध्यम से कंटेनर जीवनचक्र (शुरू करना, बंद करना, स्वास्थ्य जांच) का प्रबंधन करता है।
क्यों: Kubelet कंट्रोल प्लेन और वर्कर नोड के बीच की कड़ी है; यह Pod स्पेसिफिकेशन्स को निष्पादित करता है।
कुबेरनेट्स क्लस्टर की पूरी स्थिति और कॉन्फ़िगरेशन को मज़बूती से बनाए रखें।
`etcd` का उपयोग करें, जो एक सुसंगत और अत्यधिक उपलब्ध कुंजी-मूल्य स्टोर है। यह क्लस्टर के लिए सत्य के एकमात्र स्रोत के रूप में कार्य करता है।
क्यों: सभी क्लस्टर ऑब्जेक्ट्स (Pods, Services, आदि) etcd में संग्रहीत होते हैं। केवल API सर्वर सीधे इसके साथ संचार करता है।
कुबेरनेट्स सेवाओं के माध्यम से संचार सक्षम करने के लिए प्रत्येक नोड पर नेटवर्क नियम लागू करें।
प्रत्येक नोड पर `kube-proxy` घटक नेटवर्क नियमों (जैसे, iptables, IPVS) को बनाए रखता है जो Service IP से सही बैकएंड Pods पर ट्रैफ़िक अग्रेषित करते हैं।
क्यों: Kube-proxy Service एब्स्ट्रैक्शन के पीछे का कार्यान्वयन विवरण है, जो लोड बैलेंसिंग और रूटिंग को संभालता है।
कई टीमों, प्रोजेक्ट्स या परिवेशों के लिए एक एकल कुबेरनेट्स क्लस्टर को तार्किक रूप से विभाजित करें।
`Namespace` संसाधन बनाएँ। नेम्सपेस नामों के लिए एक दायरा और प्राधिकरण और नीतियों (जैसे, ResourceQuotas) को संलग्न करने का एक तरीका प्रदान करते हैं।
क्यों: नेम्सपेस कई क्लस्टरों के ओवरहेड के बिना मल्टी-टेनेंसी और संसाधन संगठन को सक्षम करते हैं।
क्षणिक Pods के एक सेट के लिए एक स्थिर नेटवर्क एंडपॉइंट (IP और DNS) प्रदान करें।
एक `Service` संसाधन परिभाषित करें जो लेबल सेलेक्टर का उपयोग करके Pods के एक सेट को लक्षित करता है।
क्यों: Pods क्षणिक होते हैं और उनके IP बदलते रहते हैं। एक Service एक टिकाऊ एब्स्ट्रैक्शन प्रदान करती है जो सही Pods पर ट्रैफ़िक को लोड बैलेंस करती है।
Pods में चल रहे एक एप्लिकेशन को विभिन्न नेटवर्क स्कोप में उजागर करें।
एक Service `type` चुनें: `ClusterIP` (केवल आंतरिक, डिफ़ॉल्ट), `NodePort` (प्रत्येक नोड IP:port पर उजागर करता है), या `LoadBalancer` (एक क्लाउड लोड बैलेंसर प्रदान करता है)।
क्यों: Service प्रकार एप्लिकेशन की पहुँच निर्धारित करता है, विशुद्ध रूप से आंतरिक से लेकर पूरी तरह से बाहरी तक।
Service प्रॉक्सी को बायपास करते हुए, व्यक्तिगत Pods की सीधी नेटवर्क खोज को सक्षम करें।
`clusterIP: None` के साथ एक `Service` बनाएँ। यह प्रत्येक Pod के लिए DNS A रिकॉर्ड बनाता है, जिससे क्लाइंट सीधे Pods से कनेक्ट हो सकते हैं।
क्यों: यह डेटाबेस जैसे स्टेटफुल एप्लिकेशनों (अक्सर StatefulSets के साथ) के लिए आवश्यक है जहाँ पीयर-टू-पीयर संचार या स्थिर Pod पहचान की आवश्यकता होती है।
कुबेरनेट्स ऑब्जेक्ट्स के एक उपसमूह को व्यवस्थित और चुनें।
ऑब्जेक्ट्स (जैसे, `app: my-api`) में कुंजी-मूल्य `labels` संलग्न करें। उन्हें लक्षित करने के लिए अन्य ऑब्जेक्ट्स (जैसे, Services, Deployments) में `label selectors` का उपयोग करें।
क्यों: Labels कुबेरनेट्स में मुख्य समूहन तंत्र हैं, जो संसाधनों के बीच ढीले युग्मन को सक्षम करते हैं।
एप्लिकेशन कॉन्फ़िगरेशन को कंटेनर इमेज से अलग करें।
गैर-संवेदनशील कॉन्फ़िगरेशन डेटा को एक `ConfigMap` में संग्रहीत करें। इसे एक वॉल्यूम के रूप में माउंट करें या Pods में पर्यावरण चर के रूप में कुंजियों को इंजेक्ट करें।
क्यों: यह कॉन्फ़िगरेशन को एप्लिकेशन कोड से स्वतंत्र रूप से प्रबंधित करने की अनुमति देता है, 12-फैक्टर ऐप सिद्धांतों का पालन करते हुए।
एप्लिकेशन उपयोग के लिए पासवर्ड, टोकन या API कुंजी जैसे संवेदनशील डेटा संग्रहीत करें।
एक `Secret` ऑब्जेक्ट का उपयोग करें। इसे एक वॉल्यूम के रूप में माउंट करें या एक पर्यावरण चर के रूप में इंजेक्ट करें।
क्यों: Secrets विशेष रूप से संवेदनशील डेटा के लिए हैं और ConfigMaps की तुलना में अधिक सुरक्षित रूप से संभाले जाते हैं (जैसे, डिफ़ॉल्ट रूप से `kubectl describe` में नहीं दिखाए जाते, आराम पर एन्क्रिप्ट किए जा सकते हैं)।
स्टेटफुल एप्लिकेशनों को स्टोरेज प्रदान करें जो Pod रीस्टार्ट के बाद भी बना रहता है।
एक Pod स्टोरेज का अनुरोध करने के लिए एक `PersistentVolumeClaim` (PVC) बनाता है। एक एडमिनिस्ट्रेटर एक `PersistentVolume` (PV) प्रदान करता है जो दावा को पूरा करता है।
क्यों: यह स्टोरेज खपत (PVC) को स्टोरेज प्रोविजनिंग (PV) से अलग करता है, जिससे पोर्टेबल वर्कलोड डेफिनिशन संभव हो पाती हैं।
कंटेनरों के लिए CPU और मेमोरी आवंटन का प्रबंधन करें।
गारंटीकृत संसाधनों (शेड्यूलिंग के लिए उपयोग किए जाने वाले) के लिए `resources.requests` सेट करें और अधिकतम अनुमत उपयोग (रनटाइम पर लागू) के लिए `resources.limits` सेट करें।
क्यों: रिक्वेस्ट्स सुनिश्चित करती हैं कि Pods के पास चलने के लिए पर्याप्त संसाधन हों; लिमिट्स Pods को बहुत अधिक संसाधन खपत करने और अन्य कार्यभारों को प्रभावित करने से रोकती हैं।
एक नेम्सपेस पर एग्रीगेट रिसोर्स कंस्ट्रेंट्स सेट करें।
एक `ResourceQuota` ऑब्जेक्ट बनाएँ ताकि CPU, मेमोरी, या ऑब्जेक्ट्स (Pods, Services) की कुल संख्या को सीमित किया जा सके जिन्हें एक नेम्सपेस में बनाया जा सकता है।
क्यों: ResourceQuotas मल्टी-टेनेंट वातावरण के लिए आवश्यक हैं ताकि उचित संसाधन साझाकरण सुनिश्चित किया जा सके और अत्यधिक खपत को रोका जा सके।
संस्करण-नियंत्रित कॉन्फ़िगरेशन फ़ाइलों का उपयोग करके कुबेरनेट्स संसाधनों का प्रबंधन करें।
`kubectl apply -f <filename.yaml>` का उपयोग करें। यह कमांड फ़ाइल सामग्री के आधार पर संसाधनों को बनाता या अपडेट करता है।
क्यों: `apply` घोषणात्मक है, जो इसे GitOps और CI/CD के लिए आदर्श बनाता है। यह परिवर्तनों को ट्रैक करता है और एक तीन-तरफा मर्ज करता है, जो अनिवार्य `create` या `replace` से अधिक सुरक्षित है।
यह निदान करें कि एक Pod सही ढंग से क्यों नहीं चल रहा है (जैसे, Pending, ContainerCreating, या CrashLoopBackOff में फंसा हुआ)।
`kubectl describe pod <pod-name>` का उपयोग करें। शेड्यूलर, kubelet, या कंट्रोलर से विस्तृत संदेशों के लिए नीचे `Events` अनुभाग देखें।
क्यों: `describe` एक कालानुक्रमिक इवेंट लॉग प्रदान करता है जो संसाधन जीवनचक्र समस्याओं को डीबग करने का प्राथमिक उपकरण है।
कंटेनरों के लिए नेटवर्किंग कार्यक्षमता प्रदान करें, जिससे क्लस्टर में Pod-टू-Pod संचार सक्षम हो सके।
एक कंटेनर नेटवर्क इंटरफ़ेस (CNI) प्लगइन (जैसे, Calico, Flannel, Cilium) का उपयोग करें। प्रत्येक नोड पर kubelet प्रत्येक Pod के लिए नेटवर्किंग कॉन्फ़िगर करने के लिए CNI प्लगइन का उपयोग करता है।
क्यों: CNI एक मानक इंटरफ़ेस प्रदान करता है, जिससे कुबेरनेट्स को मुख्य घटकों को संशोधित किए बिना विभिन्न नेटवर्किंग समाधानों के साथ एकीकृत किया जा सकता है।
उपयोगकर्ताओं और एप्लिकेशनों के लिए कुबेरनेट्स API संसाधनों तक पहुँच को नियंत्रित करें।
भूमिका-आधारित पहुँच नियंत्रण (RBAC) का उपयोग करें। अनुमतियों के साथ एक `Role` (नेम्सपेस) या `ClusterRole` (क्लस्टर-व्यापी) परिभाषित करें, और इसे `RoleBinding` या `ClusterRoleBinding` का उपयोग करके एक विषय (User, Group, ServiceAccount) से बाँधें।
क्यों: RBAC कुबेरनेट्स को सुरक्षित करने का मानक है, जो सभी API इंटरैक्शन के लिए कम से कम विशेषाधिकार के सिद्धांत को सक्षम करता है।
एक स्टेटलेस एप्लिकेशन का प्रबंधन करें, जिससे आसान अपडेट और रोलबैक सक्षम हो सकें।
एक `Deployment` कार्यभार का उपयोग करें। यह ReplicaSets का प्रबंधन करता है ताकि यह सुनिश्चित हो सके कि वांछित संख्या में Pod रेप्लिका चल रहे हैं और घोषणात्मक अपडेट रणनीतियाँ प्रदान करता है।
क्यों: Deployments स्टेटलेस एप्लिकेशनों के लिए मानक हैं, जो स्केलिंग और रोलिंग अपडेट के विवरण को अमूर्त करते हैं।
एक स्टेटफुल एप्लिकेशन (जैसे, डेटाबेस) डिप्लॉय करें जिसे स्थिर नेटवर्क पहचान और स्टोरेज की आवश्यकता होती है।
एक `StatefulSet` कार्यभार का उपयोग करें। यह प्रत्येक Pod को एक स्थिर, अद्वितीय होस्टनाम और परसिस्टेंट स्टोरेज प्रदान करता है जो रीस्टार्ट के दौरान भी इसके साथ रहता है।
क्यों: Deployments के विपरीत, StatefulSets पहचान के साथ Pods का प्रबंधन करते हैं, जिससे व्यवस्थित डिप्लॉयमेंट और स्केलिंग सुनिश्चित होती है, जो स्टेटफुल सिस्टम के लिए महत्वपूर्ण है।
क्लस्टर में प्रत्येक नोड पर एक एजेंट (जैसे, लॉग कलेक्टर, मॉनिटरिंग एजेंट) डिप्लॉय करें।
एक `DaemonSet` कार्यभार का उपयोग करें। यह सुनिश्चित करता है कि एक Pod की एक प्रति प्रत्येक नोड (या नोड्स के एक उपसमूह) पर चलती है।
क्यों: DaemonSets नोड-स्तर की सेवाओं के वितरण को स्वचालित करते हैं, नए नोड्स के क्लस्टर में शामिल होने पर स्वचालित रूप से स्केलिंग करते हैं।
एक सीमित, एक बार का कार्य चलाएँ जिसे पूरा होने तक निष्पादित करने की आवश्यकता है।
एक `Job` संसाधन का उपयोग करें। यह एक या एक से अधिक Pods बनाता है और सुनिश्चित करता है कि वे सफलतापूर्वक समाप्त हो जाएँ।
क्यों: Jobs बैच प्रोसेसिंग के लिए हैं, Deployments के विपरीत जो निरंतर सेवाओं के लिए हैं। सफल समापन के बाद Pods को बदला नहीं जाता है।
एक आवर्ती शेड्यूल पर एक कार्य चलाएँ (जैसे, रात भर का बैकअप, रिपोर्ट)।
एक `CronJob` संसाधन का उपयोग करें। यह एक cron शेड्यूल स्ट्रिंग के आधार पर Jobs बनाता है।
क्यों: CronJobs समय-आधारित, आवर्ती कार्यों का प्रबंधन करने का एक मूल कुबेरनेट्स तरीका प्रदान करते हैं।
एक कंटेनर को स्वचालित रूप से रीस्टार्ट करें जो अनुत्तरदायी हो गया है (जैसे, डेडलॉक)।
कंटेनर स्पेसिफिकेशन्स में एक `livenessProbe` कॉन्फ़िगर करें। यदि प्रोब विफल हो जाता है, तो kubelet कंटेनर को रीस्टार्ट कर देता है।
क्यों: Liveness probes उन एप्लिकेशनों के लिए एक शक्तिशाली स्वयं-ठीक होने वाली प्रणाली प्रदान करती हैं जो क्रैश हुए बिना एक टूटी हुई स्थिति में फंस सकते हैं।
एक कंटेनर को ट्रैफ़िक भेजने से रोकें जो अभी तक अनुरोधों को पूरा करने के लिए तैयार नहीं है।
कंटेनर स्पेसिफिकेशन्स में एक `readinessProbe` कॉन्फ़िगर करें। Pod को Service एंडपॉइंट्स में तभी जोड़ा जाता है जब प्रोब सफल हो जाता है।
क्यों: Readiness probes शून्य-डाउनटाइम रोलिंग अपडेट के लिए महत्वपूर्ण हैं, यह सुनिश्चित करते हुए कि नए Pods उत्पादन ट्रैफ़िक प्राप्त करने से पहले पूरी तरह से इनिशियलाइज़ हो जाएँ।
मुख्य एप्लिकेशन कंटेनर शुरू करने से पहले सेटअप कार्य चलाएँ या निर्भरताओं के तैयार होने की प्रतीक्षा करें।
Pod स्पेसिफिकेशन्स में एक या एक से अधिक `initContainers` को परिभाषित करें। वे किसी भी ऐप कंटेनर के शुरू होने से पहले अनुक्रम में पूरा होने तक चलते हैं।
क्यों: Init कंटेनर सेटअप लॉजिक के लिए एक स्वच्छ अलगाव प्रदान करते हैं, यह सुनिश्चित करते हुए कि मुख्य एप्लिकेशन कंटेनर को अव्यवस्थित किए बिना पूर्वापेक्षाएँ पूरी हों।
सुनिश्चित करें कि Pods विशिष्ट विशेषताओं वाले नोड्स पर शेड्यूल किए गए हैं (जैसे, GPUs, SSDs वाले नोड्स)।
नोड लेबलों के आधार पर नियम निर्धारित करने के लिए Pod स्पेसिफिकेशन्स में `nodeAffinity` का उपयोग करें। यह एक "required" (कठिन) या "preferred" (नरम) बाधा हो सकती है।
क्यों: Node एफिनिटी `nodeSelector` की तुलना में अधिक अभिव्यंजक है और नोड गुणों के आधार पर Pod प्लेसमेंट को नियंत्रित करने का आधुनिक तरीका है।
प्रदर्शन या उच्च उपलब्धता के लिए एक दूसरे के सापेक्ष Pods के सह-स्थान को नियंत्रित करें।
Pods को एक साथ शेड्यूल करने के लिए `podAffinity` का उपयोग करें (जैसे, एक ही नोड पर) या उन्हें अलग करने के लिए `podAntiAffinity` का उपयोग करें (जैसे, विभिन्न नोड्स या ज़ोन में)।
क्यों: एंटी-एफिनिटी यह सुनिश्चित करने के लिए महत्वपूर्ण है कि एक सेवा के रेप्लिका एक ही विफलता डोमेन पर न हों, जिससे उपलब्धता बढ़ती है।
सामान्य-उद्देश्य वाले Pods को समर्पित या विशेष-उद्देश्य वाले नोड्स पर शेड्यूल होने से रोकें।
एक नोड पर एक `Taint` लागू करें। उस नोड पर शेड्यूल होने के लिए Pods को अपनी स्पेसिफिकेशन्स में एक मिलान करने वाला `Toleration` होना चाहिए।
क्यों: Taints और tolerations सुनिश्चित करते हैं कि नोड्स उन कार्यभारों के लिए आरक्षित हैं जिन्हें वहाँ चलाने की स्पष्ट रूप से अनुमति है।
ज़ोन या नोड्स जैसे विफलता डोमेन में Pods को समान रूप से वितरित करके उच्च उपलब्धता सुनिश्चित करें।
लेबल और टोपोलॉजी कुंजियों (जैसे, `topology.kubernetes.io/zone`) के आधार पर Pods कैसे फैले हुए हैं, इसे नियंत्रित करने के लिए Pod स्पेसिफिकेशन्स में `topologySpreadConstraints` को परिभाषित करें।
क्यों: यह pod एंटी-एफिनिटी की तुलना में HA पर अधिक बारीक नियंत्रण प्रदान करता है, जिससे सभी रेप्लिका को एक ही स्थान पर केंद्रित होने से रोका जा सकता है।
देखे गए लोड के आधार पर एप्लिकेशन रेप्लिका की संख्या को स्वचालित रूप से स्केल करें।
एक `HorizontalPodAutoscaler` (HPA) संसाधन बनाएँ जो एक Deployment को लक्षित करता है और एक मेट्रिक (जैसे, CPU उपयोग) और लक्ष्य मान निर्दिष्ट करता है।
क्यों: HPA इलास्टिक स्केलिंग को सक्षम बनाता है, लोड के तहत प्रदर्शन सुनिश्चित करता है जबकि शांत अवधियों के दौरान लागत बचाता है, बिना मैन्युअल हस्तक्षेप के।
संसाधन मांग से मेल खाने के लिए क्लस्टर से वर्कर नोड्स को स्वचालित रूप से जोड़ें या हटाएँ।
`Cluster Autoscaler` डिप्लॉय करें। यह उन Pods की निगरानी करता है जिन्हें शेड्यूल नहीं किया जा सकता है (संसाधनों की कमी के कारण) और नोड्स जोड़ता है, या कम उपयोग किए गए नोड्स को हटाता है।
क्यों: Cluster Autoscaler इंफ्रास्ट्रक्चर-स्तर की इलास्टिसिटी का प्रबंधन करता है, कार्यभार की जरूरतों के आधार पर क्लस्टर के आकार को समायोजित करने के लिए क्लाउड प्रदाताओं के साथ काम करता है।
स्वैच्छिक व्यवधानों (जैसे, नोड अपग्रेड) के दौरान एप्लिकेशन रेप्लिका की न्यूनतम संख्या उपलब्ध रहे, यह सुनिश्चित करें।
Pods के एक सेट के लिए `minAvailable` या `maxUnavailable` निर्दिष्ट करते हुए एक `PodDisruptionBudget` (PDB) बनाएँ।
क्यों: PDBs `kubectl drain` जैसी कार्रवाइयों को एक बार में बहुत अधिक रेप्लिका को बंद करने से रोकते हैं, जिससे एप्लिकेशन की उपलब्धता सुरक्षित रहती है।
एक स्टेटलेस एप्लिकेशन के लिए शून्य-डाउनटाइम अपडेट करें।
डिफ़ॉल्ट `RollingUpdate` रणनीति के साथ एक `Deployment` का उपयोग करें। अपडेट प्रक्रिया को नियंत्रित करने के लिए `maxSurge` और `maxUnavailable` कॉन्फ़िगर करें।
क्यों: रोलिंग अपडेट धीरे-धीरे पुराने Pods को नए के साथ बदलते हैं, यह सुनिश्चित करते हुए कि अपडेट के दौरान सेवा उपलब्ध रहे।
संस्करण नियंत्रण और एक ऑडिट ट्रेल के साथ बुनियादी ढांचे और एप्लिकेशन डिप्लॉयमेंट को घोषणात्मक रूप से प्रबंधित करें।
GitOps लागू करें। Git रिपॉजिटरी को सत्य के एकमात्र स्रोत के रूप में उपयोग करें। Git के साथ क्लस्टर स्थिति को स्वचालित रूप से सिंक करने के लिए Argo CD या Flux जैसे टूल का उपयोग करें।
क्यों: GitOps सभी परिवर्तनों का एक स्पष्ट, ऑडिटेबल इतिहास प्रदान करता है और Git कमिट्स को वापस करके आसान रोलबैक को सक्षम बनाता है। यह इंफ्रास्ट्रक्चर ऐज़ कोड को क्रियान्वित करता है।
पुनः प्रयोज्य और संस्करणबद्ध तरीके से जटिल कुबेरनेट्स एप्लिकेशनों को पैकेज, कॉन्फ़िगर और डिप्लॉय करें।
कुबेरनेट्स के लिए पैकेज मैनेजर `Helm` का उपयोग करें। टेम्पलेटेड मैनिफेस्ट और कॉन्फ़िगर करने योग्य `values.yaml` फ़ाइलों के साथ एप्लिकेशनों को `Charts` के रूप में पैकेज करें।
क्यों: Helm कई घटकों वाले जटिल एप्लिकेशनों के प्रबंधन को सरल बनाता है, निर्भरताओं, संस्करणों और जीवनचक्र प्रबंधन को संभालता है।
टेम्प्लेट का उपयोग किए बिना विभिन्न परिवेशों के लिए कुबेरनेट्स मैनिफेस्ट को अनुकूलित करें।
`Kustomize` का उपयोग करें। एक `kustomization.yaml` फ़ाइल परिभाषित करें जो एक बेस कॉन्फ़िगरेशन निर्दिष्ट करती है और प्रत्येक परिवेश के लिए पैच या ओवरले लागू करती है।
क्यों: Kustomize कॉन्फ़िगरेशन वेरिएंट्स को प्रबंधित करने का एक घोषणात्मक, टेम्पलेट-मुक्त तरीका प्रदान करता है, जो टेक्स्ट-आधारित टेम्पलेटिंग की तुलना में सरल और कम त्रुटि-प्रवण हो सकता है।
पूर्ण रोलआउट से पहले उत्पादन ट्रैफ़िक के एक छोटे उपसमूह के साथ एक नए एप्लिकेशन संस्करण का परीक्षण करें।
नए संस्करण को पुराने के साथ डिप्लॉय करें। नए "canary" संस्करण पर ट्रैफ़िक का एक छोटा प्रतिशत (जैसे, 5%) रूट करने के लिए एक सेवा मेश या इनग्रेस कंट्रोलर का उपयोग करें।
क्यों: Canary रिलीज़ ब्लास्ट रेडियस को सीमित करके और उत्पादन परीक्षण की अनुमति देकर एक खराब रिलीज़ पेश करने के जोखिम को कम करती हैं।
शून्य डाउनटाइम और तत्काल रोलबैक क्षमता के साथ एक नया एप्लिकेशन संस्करण डिप्लॉय करें।
नए "ग्रीन" संस्करण को मौजूदा "ब्लू" संस्करण के साथ डिप्लॉय करें। एक बार जब ग्रीन संस्करण सत्यापित हो जाता है, तो Service/राउटर स्तर पर 100% ट्रैफ़िक को ब्लू से ग्रीन में स्विच करें।
क्यों: ब्लू-ग्रीन डिप्लॉयमेंट डाउनटाइम को खत्म करते हैं। रोलबैक उतना ही सरल है जितना ट्रैफ़िक को ब्लू परिवेश में वापस स्विच करना।
एक जटिल एप्लिकेशन को छोटी, स्वतंत्र और ढीले-युग्मित सेवाओं के संग्रह के रूप में डिज़ाइन करें।
एप्लिकेशन को माइक्रोसेवाओं के रूप में संरचित करें, प्रत्येक एक व्यावसायिक क्षमता के इर्द-गिर्द व्यवस्थित। प्रत्येक सेवा का अपना डेटा होना चाहिए और अच्छी तरह से परिभाषित API के माध्यम से संचार करना चाहिए।
क्यों: यह आर्किटेक्चर सेवाओं के स्वतंत्र विकास, डिप्लॉयमेंट और स्केलिंग को सक्षम बनाता है, जिससे एजिलिटी और लचीलापन बेहतर होता है।
स्थापित सर्वोत्तम प्रथाओं का पालन करते हुए एक पोर्टेबल, स्केलेबल और क्लाउड-नेटिव एप्लिकेशन बनाएँ।
बारह-फैक्टर ऐप मेथोडोलॉजी का पालन करें। एक प्रमुख सिद्धांत यह है कि सभी कॉन्फ़िगरेशन जो परिवेशों के बीच भिन्न होते हैं, उन्हें पर्यावरण चर में संग्रहीत किया जाए।
क्यों: यह कॉन्फ़िग को कोड से सख्ती से अलग करता है, जिससे एक ही कंटेनर इमेज को बिना किसी बदलाव के परिवेशों में प्रचारित किया जा सकता है।
जटिल सेवा-से-सेवा संचार का प्रबंधन करें, ट्रैफ़िक प्रबंधन, सुरक्षा और अवलोकन क्षमता प्रदान करें।
एक सेवा मेश (जैसे, Istio, Linkerd) लागू करें। यह सभी नेटवर्क ट्रैफ़िक को इंटरसेप्ट और प्रबंधित करने के लिए प्रत्येक Pod में एक साइडकार प्रॉक्सी इंजेक्ट करता है।
क्यों: एक सेवा मेश एप्लिकेशन कोड से नेटवर्क संबंधी चिंताओं (mTLS, रिट्राई, सर्किट ब्रेकिंग) को अमूर्त करता है, उन्हें प्लेटफॉर्म स्तर पर लागू करता है।
एप्लिकेशन कंटेनर की कार्यक्षमता को उसके कोड को संशोधित किए बिना विस्तारित या बढ़ाएँ।
मुख्य एप्लिकेशन के समान Pod में एक "साइडकार" कंटेनर डिप्लॉय करें। यह एक ही नेटवर्क और स्टोरेज साझा करता है।
क्यों: साइडकार का उपयोग क्रॉस-कटिंग चिंताओं जैसे लॉगिंग, मॉनिटरिंग, या प्रॉक्सीइंग (जैसा कि एक सेवा मेश में होता है) के लिए किया जाता है, जिससे चिंताओं का अलगाव बढ़ता है।
समस्या निवारण को सुविधाजनक बनाने के लिए एक वितरित प्रणाली के व्यवहार में गहरी अंतर्दृष्टि प्राप्त करें।
अवलोकन क्षमता के तीन स्तंभों को लागू करें: `Metrics` (एकत्रित संख्यात्मक डेटा), `Logs` (असतत घटनाएँ), और `Traces` (एंड-टू-एंड अनुरोध प्रवाह)।
क्यों: साथ मिलकर, ये डेटा प्रकार सिस्टम स्वास्थ्य और प्रदर्शन का एक व्यापक दृश्य प्रदान करते हैं, जो जटिल माइक्रोसेवा आर्किटेक्चर के लिए आवश्यक है।
