CNCF Certified Cloud Native Platform Engineer
अंतिम समीक्षा: मई 2026
CNPE परीक्षा द्वारा परखे जाने वाले architectural patterns का स्कैन-योग्य संदर्भ। ऊपर से नीचे पढ़ें या किसी section पर जाएं।
परियोजना करें और Kubernetes-नेटिव, डिक्लेरेटिव API का उपयोग करके मल्टी-क्लाउड इंफ्रास्ट्रक्चर का प्रबंधन करें।
Crossplane का उपयोग करें। क्लाउड प्रदाता CRDs (जैसे, provider-aws) स्थापित करें। Composition और CompositeResourceDefinition (XRD) के साथ प्लेटफ़ॉर्म एब्स्ट्रैक्शन को परिभाषित करें।
क्यों: एकल कंट्रोल प्लेन और GitOps वर्कफ़्लो के तहत एप्लिकेशन और इंफ्रास्ट्रक्चर प्रबंधन को एकीकृत करता है, प्रदाता-विशिष्ट विवरणों को डेवलपर्स से अमूर्त करता है।
विभिन्न प्रदाताओं में कई Kubernetes क्लस्टरों के लाइफसाइकल (बनाना, अपग्रेड करना, हटाना) को डिक्लेरेटिव रूप से प्रबंधित करें।
प्रासंगिक इंफ्रास्ट्रक्चर प्रदाताओं (जैसे AWS के लिए CAPA, Azure के लिए CAPZ) के साथ Cluster API (CAPI) लागू करें। क्लस्टरों को एक प्रबंधन क्लस्टर में Kubernetes संसाधनों के रूप में परिभाषित करें।
क्यों: क्लस्टर लाइफसाइकल को कोड के रूप में मानता है, जिससे क्लस्टर के लिए GitOps सक्षम होता है। CAPI MachineHealthChecks स्वचालित नोड रिमेडिएशन प्रदान करते हैं।
साझे Kubernetes प्लेटफ़ॉर्म पर टेनेंट वर्कलोड के बीच मजबूत आइसोलेशन प्रदान करें।
समर्पित नोड पूल्स (कंप्यूट), NetworkPolicies (नेटवर्क), RBAC (API), ResourceQuotas (संसाधन), और Pod Security Standards (सुरक्षा) को मिलाएं। कंट्रोल प्लेन आइसोलेशन के लिए वर्चुअल क्लस्टर (vCluster) पर विचार करें।
क्यों: एक डीप-डिफेंस रणनीति की आवश्यकता है। कोई भी एक सुविधा पूर्ण आइसोलेशन प्रदान नहीं करती है। प्रत्येक परत टेनेंसी के एक अलग पहलू को संबोधित करती है।
एक केंद्रीय बिंदु से बड़ी संख्या में डाउनस्ट्रीम क्लस्टरों के लिए कॉन्फ़िगरेशन और वर्कलोड का प्रबंधन करें।
प्लेटफ़ॉर्म कंट्रोल प्लेन टूल्स (ArgoCD, Flux, Crossplane, पॉलिसी इंजन) को होस्ट करने के लिए एक "हब" क्लस्टर नामित करें। "स्पोक" क्लस्टर वर्कलोड चलाते हैं और हब से प्रबंधित होते हैं।
क्यों: प्रबंधन, नीति प्रवर्तन और ऑब्ज़र्वेबिलिटी को केंद्रीकृत करता है, जिससे मल्टी-क्लस्टर ऑपरेशंस सरल होते हैं और निरंतरता सुनिश्चित होती है।
भौतिक क्लस्टरों के ओवरहेड के बिना विकास टीमों को अलग-थलग, क्लस्टर-एडमिन-जैसे वातावरण प्रदान करें।
vCluster का उपयोग करें। प्रत्येक vCluster एक होस्ट क्लस्टर नेमस्पेस के भीतर पॉड्स के रूप में एक अलग K8s कंट्रोल प्लेन चलाता है, जो होस्ट वर्कर नोड्स को साझा करता है।
क्यों: पूर्ण क्लस्टरों की तुलना में कम लागत पर मजबूत API-स्तर का आइसोलेशन प्रदान करता है। vCluster सिंकर होस्ट क्लस्टर पर आवश्यक संसाधनों को साकार करता है।
कम RPO/RTO के साथ स्टेटफुल वर्कलोड के लिए डिजास्टर रिकवरी सुनिश्चित करें।
एक CSI ड्राइवर का उपयोग करें जो सिंक्रोनस या एसिंक्रोनस क्रॉस-रीजन/क्रॉस-क्लस्टर डेटा प्रतिकृति (जैसे, Rook-Ceph, Portworx) का समर्थन करता है।
क्यों: क्षेत्रीय विफलता में डेटा उपलब्धता के लिए प्रतिकृति महत्वपूर्ण है। स्थानीय स्नैपशॉट या उच्च-प्रदर्शन स्तर क्रॉस-साइट DR को संबोधित नहीं करते हैं।
विफलता डोमेन में प्रतिकृतियों को वितरित करके एप्लिकेशन उपलब्धता में सुधार करें।
वर्कलोड स्पेक्स में Pod Topology Spread Constraints का उपयोग करें। `topologyKey` (जैसे, `topology.kubernetes.io/zone`) और `whenUnsatisfiable: ScheduleAnyway` या `DoNotSchedule` को परिभाषित करें।
क्यों: किसी सेवा की सभी प्रतिकृतियों को एक ही ज़ोन या एक ही नोड पर शेड्यूल होने से रोकता है, जिससे स्थानीय इंफ्रास्ट्रक्चर विफलताओं के प्रभाव को कम किया जा सके।
पदानुक्रमित संगठनात्मक संरचनाओं वाली टीमों के लिए नीतियों और RBAC का प्रबंधन करें।
Hierarchical Namespace Controller (HNC) लागू करें। RBAC, NetworkPolicies और ResourceQuotas को प्रसारित करने के लिए पैरेंट-चाइल्ड नेमस्पेस संबंध बनाएं।
क्यों: HNC प्लेटफ़ॉर्म एडमिन्स को टीम/संगठन स्तर (पैरेंट नेमस्पेस) पर नीतियां निर्धारित करने की अनुमति देकर प्रबंधन को सरल बनाता है, जो सभी सब-नेमस्पेस द्वारा स्वचालित रूप से विरासत में मिलती हैं।
मेट्रिक-आधारित विश्लेषण और रोलबैक के साथ कैनरी या ब्लू-ग्रीन जैसी उन्नत, स्वचालित डिप्लॉयमेंट रणनीतियों को लागू करें।
Argo Rollouts का उपयोग करें। एक रणनीति (जैसे, कैनरी) के साथ एक Rollout संसाधन परिभाषित करें जिसमें ट्रैफिक राउटिंग कॉन्फ़िगरेशन (एक सर्विस मेश के लिए) और Prometheus जैसे मेट्रिक्स प्रदाता को संदर्भित करने वाला एक AnalysisTemplate शामिल हो।
क्यों: डिप्लॉयमेंट को एप्लिकेशन लॉजिक से अलग करता है। ट्रैफिक शिफ्टिंग और विश्लेषण को स्वचालित करता है, रिलीज़ को सुरक्षित रूप से बढ़ावा देता है और विफलता पर स्वचालित रूप से रोलबैक करता है, जिससे डिप्लॉयमेंट जोखिम कम होता है।
Git में प्लेनटेक्स्ट क्रेडेंशियल स्टोर किए बिना GitOps वर्कफ़्लो में सीक्रेट्स का प्रबंधन करें।
Sealed Secrets (एक विशिष्ट क्लस्टर के लिए सीक्रेट्स को एन्क्रिप्ट करता है) या External Secrets Operator (Vault, AWS/GCP/Azure सीक्रेट मैनेजर्स से सिंक करता है) का उपयोग करें। केवल एन्क्रिप्टेड सीक्रेट या संदर्भ संसाधन को Git पर कमिट करें।
क्यों: संवेदनशील डेटा को Git से बाहर रखता है, जबकि सीक्रेट्स को GitOps वर्कफ़्लो के हिस्से के रूप में डिक्लेरेटिव रूप से प्रबंधित करने की अनुमति देता है, जिससे सत्य का एकल स्रोत बना रहता है।
कई क्लस्टरों, वातावरणों, या माइक्रोसर्विसेज के लिए ArgoCD एप्लिकेशन के निर्माण और प्रबंधन को स्वचालित करें।
एक ApplicationSet का उपयोग करें। एप्लिकेशन के लिए एक टेम्पलेट परिभाषित करें और क्लस्टर सूचियों, Git डायरेक्टरीज़, या अन्य स्रोतों के आधार पर गतिशील रूप से एप्लिकेशन बनाने के लिए एक जनरेटर (जैसे, क्लस्टर, Git, मैट्रिक्स) का उपयोग करें।
क्यों: मैनुअल एप्लिकेशन निर्माण को समाप्त करता है, जिससे एक ही परिभाषा से सैकड़ों एप्लिकेशन या क्लस्टरों का स्केलेबल प्रबंधन सक्षम होता है।
डेवलपर्स को पुल रिक्वेस्ट में परिवर्तनों का परीक्षण करने के लिए क्षणिक पूर्वावलोकन वातावरण प्रदान करें।
Pull Request जनरेटर के साथ ArgoCD ApplicationSet का उपयोग करें। जब एक PR खोला जाता है तो यह स्वचालित रूप से एक एप्लिकेशन बनाता है और जब PR बंद/मर्ज हो जाता है तो इसे हटा देता है।
क्यों: डेवलपर्स को मर्ज करने से पहले एक लाइव वातावरण में परिवर्तनों को मान्य करने में सक्षम बनाता है, जिससे कोड गुणवत्ता में सुधार होता है और एकीकरण समस्याओं को कम किया जा सकता है, बिना मैन्युअल वातावरण प्रबंधन के।
ArgoCD के साथ अनुप्रयोगों और प्लेटफ़ॉर्म घटकों के एक बड़े, जटिल सेट को संरचित तरीके से प्रबंधित करें।
App-of-Apps पैटर्न को लागू करें। एक रूट एप्लिकेशन अन्य चाइल्ड एप्लिकेशन का प्रबंधन करता है, जो बदले में अन्य एप्लिकेशन का प्रबंधन कर सकते हैं, एक पदानुक्रमित संरचना का निर्माण करते हुए।
क्यों: एक क्लस्टर या वातावरण को बूटस्ट्रैप करने के लिए एक एकल प्रवेश बिंदु प्रदान करता है, जबकि व्यक्तिगत एप्लिकेशन सेटों के मॉड्यूलर, टीम-आधारित प्रबंधन की अनुमति देता है।
सुनिश्चित करें कि संसाधन सही क्रम में डिप्लॉय किए गए हैं (जैसे, CRs से पहले CRDs, एप्लिकेशन से पहले इंफ्रास्ट्रक्चर)।
ArgoCD में, Sync Waves और संसाधन स्वास्थ्य जांच का उपयोग करें। Flux में, Kustomization या HelmRelease संसाधनों में `dependsOn` का उपयोग करें।
क्यों: डिक्लेरेटिव सिस्टम डिफ़ॉल्ट रूप से समानांतर में संसाधनों को लागू करते हैं। संसाधनों के बीच निर्भरताओं का प्रबंधन करने के लिए स्पष्ट ऑर्डरिंग तंत्र की आवश्यकता होती है।
Flux का उपयोग करके एक पूर्ण GitOps पाइपलाइन लागू करें।
Flux कंट्रोलर को मिलाएं: Source Controller (Git/Helm/OCI स्रोतों के लिए), Kustomize Controller (मेनिफेस्ट को लागू करने के लिए), और Helm Controller (HelmReleases के लिए)। अलर्ट के लिए Notification Controller का उपयोग करें।
क्यों: Flux विशेष नियंत्रकों का एक संयोज्य सेट है। Flux-आधारित कंटीन्यूअस डिलीवरी के निर्माण और समस्या निवारण के लिए प्रत्येक की भूमिका को समझना महत्वपूर्ण है।
सुनिश्चित करें कि लाइव क्लस्टर स्थिति Git में वांछित स्थिति से लगातार मेल खाती है, किसी भी मैन्युअल परिवर्तन को वापस करती है।
ArgoCD एप्लिकेशन को `syncPolicy.automated.selfHeal: true` के साथ कॉन्फ़िगर करें। ArgoCD विचलन का पता लगाएगा और अनधिकृत परिवर्तनों को वापस करने के लिए स्वचालित रूप से सिंक करेगा।
क्यों: सेल्फ-हीलिंग एक कोर GitOps सिद्धांत है जो Git को सत्य के एकल स्रोत के रूप में लागू करता है और कॉन्फ़िगरेशन विचलन को रोकता है, जो अनुपालन और स्थिरता के लिए महत्वपूर्ण है।
उचित ऑडिट और अप्रूवल गेट्स के साथ वातावरणों (देव -> स्टेजिंग -> प्रोड) में एप्लिकेशन संस्करणों को बढ़ावा दें।
Git में प्रति वातावरण अलग-अलग डायरेक्टरीज़ या शाखाओं का उपयोग करें। पुल रिक्वेस्ट बनाकर परिवर्तनों को बढ़ावा दें (जैसे, स्टेजिंग से प्रोड शाखा/डायरेक्टरी तक)। PR रिव्यूज को लागू करें।
क्यों: ऑडिट ट्रेल्स और अप्रूवल के लिए Git का लाभ उठाता है। PR प्रक्रिया औपचारिक प्रमोशन गेट बन जाती है, यह सुनिश्चित करते हुए कि उत्पादन तक पहुंचने से पहले परिवर्तनों की समीक्षा की जाती है।
साझे ArgoCD इंस्टेंस में मल्टी-टेनेंसी लागू करें, टीमों को उनके अपने संसाधनों तक सीमित करें।
प्रत्येक टीम के लिए ArgoCD प्रोजेक्ट बनाएं। प्रोजेक्ट्स को स्रोत Git रिपॉजिटरीज़, डेस्टिनेशन क्लस्टर/नेमस्पेस, और अनुमत संसाधन प्रकारों को प्रतिबंधित करने के लिए कॉन्फ़िगर करें। SSO के साथ एकीकृत करें और समूहों को प्रोजेक्ट भूमिकाओं से मैप करें।
क्यों: प्रोजेक्ट ArgoCD में मल्टी-टेनेंट आइसोलेशन और RBAC के लिए प्राथमिक तंत्र हैं, जो सुरक्षित सेल्फ-सर्विस एप्लिकेशन डिप्लॉयमेंट को सक्षम करते हैं।
डेवलपर्स के लिए एक सेल्फ-सर्विस API डिज़ाइन करें ताकि वे क्लाउड-विशिष्ट ज्ञान की आवश्यकता के बिना इंफ्रास्ट्रक्चर को प्रोविजन कर सकें।
CompositeResourceDefinition (XRD) के साथ एक उच्च-स्तरीय API परिभाषित करें। एक Composition के साथ API को लागू करें जो उच्च-स्तरीय फ़ील्ड को अंतर्निहित प्रबंधित संसाधनों से मैप करता है। डेवलपर्स एक साधारण Composite Resource Claim (XRC) के साथ इंटरैक्ट करते हैं।
क्यों: यह तीन-परत मॉडल (दावा -> संरचना -> प्रबंधित संसाधन) उपयोगकर्ता-सामने वाले API को कार्यान्वयन से अलग करता है, एक स्वच्छ अमूर्तता प्रदान करता है और प्लेटफ़ॉर्म शासन को सक्षम करता है।
डेवलपर्स को नए प्रोजेक्ट्स, माइक्रोसर्विसेज, या इंफ्रास्ट्रक्चर को डिक्लेरेटिव रूप से और संगठनात्मक मानकों के अनुपालन में बूटस्ट्रैप करने में सक्षम करें।
Backstage सॉफ्टवेयर टेम्पलेट बनाएं। टेम्पलेट इनपुट पैरामीटर (एक फॉर्म UI) और स्कैफ़ोल्डर क्रियाओं की एक श्रृंखला (जैसे, स्केलेटन प्राप्त करें, Git रेपो बनाएं, कैटलॉग में रजिस्टर करें) को परिभाषित करता है।
क्यों: "गोल्डन पाथ" वर्कफ़्लो को स्वचालित करता है, डेवलपर के संज्ञानात्मक भार को कम करता है, निरंतरता सुनिश्चित करता है, और मिनटों से सेकंडों में प्रोजेक्ट सेटअप को गति देता है।
एक संगठन के भीतर सभी सॉफ्टवेयर, सेवाओं, API, और उनके स्वामित्व को खोजने के लिए एक एकल, केंद्रीकृत स्थान बनाएं।
Backstage सॉफ्टवेयर कैटलॉग लागू करें। सॉफ्टवेयर घटकों और उनके संबंधों का एक खोज योग्य ग्राफ बनाने के लिए Git रिपॉजिटरीज़ से `catalog-info.yaml` इकाई डिस्क्रिप्टर को इनजेस्ट करें।
क्यों: कैटलॉग एक IDP का मूल है, जो खोज क्षमता और TechDocs, API डॉक्स, और CI/CD स्थिति दृश्यता जैसी अन्य सुविधाओं के लिए एक आधार प्रदान करता है।
एक Kubernetes ऑपरेटर को बाहरी संसाधनों (जैसे, क्लाउड स्टोरेज, DNS रिकॉर्ड) को तब साफ करने की आवश्यकता होती है जब एक कस्टम संसाधन हटाया जाता है।
फाइनललाइज़र का उपयोग करें। कंट्रोलर में, CR निर्माण पर एक फाइनललाइज़र जोड़ें। रिकंसीलिएशन लूप में, यदि `deletionTimestamp` सेट है, तो क्लीनअप लॉजिक को निष्पादित करें और फिर फाइनललाइज़र को हटा दें।
क्यों: फाइनललाइज़र Kubernetes को संसाधन को हटाने से रोकते हैं जब तक कि कंट्रोलर ने अपने क्लीनअप कार्यों को सफलतापूर्वक पूरा नहीं कर लिया हो, जिससे अनाथ बाहरी संसाधनों को रोका जा सके।
स्थिर क्रेडेंशियल प्रबंधित किए बिना Kubernetes वर्कलोड को क्लाउड प्रदाता API तक सुरक्षित, अल्पकालिक पहुंच प्रदान करें।
क्लाउड प्रदाता Workload Identity सॉल्यूशंस (AWS IRSA, GCP Workload Identity, Azure Workload Identity) का उपयोग करें। यह एक Kubernetes ServiceAccount को क्लाउड IAM भूमिका से लिंक करता है, जिससे पॉड्स को अस्थायी क्रेडेंशियल प्राप्त करने की अनुमति मिलती है।
क्यों: लंबे समय तक चलने वाले स्थिर क्रेडेंशियल्स के जोखिम को समाप्त करता है। यह पॉड्स को क्लाउड अनुमतियां प्रदान करने के लिए सबसे सुरक्षित पैटर्न है।
उपयोगकर्ताओं और ऑटोमेशन टूल्स को एक कस्टम संसाधन रिकंसीलिएशन की स्थिति और प्रगति को वापस सूचित करें।
CRD परिभाषा में स्टेटस सब-रिसोर्स को सक्षम करें। कंट्रोलर को शर्तों (जैसे, `Type: Ready`, `Status: True`) और देखी गई स्थिति के साथ स्थिति को अपडेट करना चाहिए।
क्यों: वांछित स्थिति (स्पेक) को देखी गई स्थिति (स्टेटस) से अलग करता है। ग्राहकों के लिए संसाधन स्वास्थ्य और तत्परता को समझने के लिए एक मानक, देखने योग्य तंत्र प्रदान करता है।
मौजूदा ग्राहकों या उपयोगकर्ताओं को तोड़े बिना प्लेटफ़ॉर्म API (CRDs) को विकसित करें।
Kubernetes API वर्जनिंग परंपराओं (v1alpha1 -> v1beta1 -> v1) का पालन करें। ब्रेकिंग परिवर्तन पेश करते समय, एक नया संस्करण बनाएं और संग्रहीत और सेवा किए गए संस्करणों के बीच अनुवाद करने के लिए एक कन्वर्जन वेबहुक लागू करें।
क्यों: कन्वर्जन वेबहुक API सर्वर को एक संसाधन के कई संस्करणों को एक साथ सेवा देने की अनुमति देते हैं, जबकि एक एकल स्टोरेज संस्करण बनाए रखते हैं, जिससे सहज API विकास सक्षम होता है।
सेवा विश्वसनीयता लक्ष्यों के आधार पर कार्रवाई योग्य अलर्ट बनाएं जो संवेदनशीलता को अलर्ट थकान से बचने के साथ संतुलित करते हैं।
SLOs को परिभाषित करें और एरर बजट की गणना करें। मल्टी-विंडो, मल्टी-बर्न-रेट अलर्टिंग लागू करें जो तब ट्रिगर होता है जब एरर बजट खपत की दर SLO को खतरा देती है।
क्यों: एरर बजट बर्न पर अलर्ट करना साधारण थ्रेशोल्ड अलर्ट की तुलना में अधिक सार्थक है। यह सीधे अलर्ट को उपयोगकर्ता-सामने वाले प्रभाव और SLO उल्लंघनों से जोड़ता है।
ऑब्ज़र्वेबिलिटी सिग्नल (ट्रेस, मेट्रिक्स, लॉग) को एकत्र करने, संसाधित करने और निर्यात करने के लिए एक वेंडर-अज्ञेयवादी, एकीकृत पाइपलाइन लागू करें।
OpenTelemetry Collector को डिप्लॉय करें। रिसीवर (जैसे, OTLP, Jaeger), प्रोसेसर (जैसे, बैच, एट्रिब्यूट्स), और एक्सपोर्टर (जैसे, Prometheus, Loki, Tempo, वेंडर बैकएंड) के साथ पाइपलाइन कॉन्फ़िगर करें।
क्यों: इंस्ट्रूमेंटेशन को ऑब्ज़र्वेबिलिटी बैकएंड से अलग करता है, जिससे प्लेटफ़ॉर्म को एप्लिकेशन को फिर से इंस्ट्रूमेंट किए बिना बैकएंड को स्विच या जोड़ने की अनुमति मिलती है। प्रोसेसिंग और संवर्धन के लिए एक केंद्रीय बिंदु प्रदान करता है।
Kubernetes वर्कलोड से मेट्रिक्स को खोजने और स्क्रैप करने के लिए Prometheus को डिक्लेरेटिव रूप से कॉन्फ़िगर करें।
Prometheus ऑपरेटर का उपयोग करें। `ServiceMonitor` या `PodMonitor` कस्टम संसाधन बनाएं जो लेबल चयनकर्ताओं का उपयोग करते हैं यह परिभाषित करने के लिए कि Prometheus को किन सेवाओं या पॉड्स को स्क्रैप करना चाहिए।
क्यों: स्क्रैप कॉन्फ़िगरेशन का प्रबंधन करने का एक Kubernetes-नेटिव तरीका प्रदान करता है, जो एप्लिकेशन डिप्लॉयमेंट और GitOps वर्कफ़्लो के साथ सहजता से एकीकृत होता है।
किसी घटना की जांच के दौरान, एक असामान्य मेट्रिक (जैसे, लेटेंसी स्पाइक) से उन विशिष्ट अनुरोधों तक तेज़ी से नेविगेट करें जिन्होंने इसे कारण बनाया।
Prometheus उदाहरणों का उपयोग करें। मेट्रिक अवलोकनों में ट्रेस ID संलग्न करने के लिए एप्लिकेशन को इंस्ट्रूमेंट करें। Prometheus और Grafana को उदाहरण प्रदर्शित करने के लिए कॉन्फ़िगर करें, Tempo या Jaeger जैसे ट्रेसिंग बैकएंड में मेट्रिक्स से ट्रेसेस तक सीधे लिंक प्रदान करें।
क्यों: "क्या" (मेट्रिक) को "क्यों" (ट्रेस) से सीधे जोड़कर MTTR को नाटकीय रूप से कम करता है, जिससे मैन्युअल सहसंबंध प्रयासों को समाप्त किया जा सके।
किसी भी उपयोगकर्ता-सामने या महत्वपूर्ण सेवा के स्वास्थ्य की निगरानी के लिए एक आधारभूत रेखा स्थापित करें।
चार "गोल्डन सिग्नल" की निगरानी करें: लेटेंसी (प्रतिक्रिया समय), ट्रैफिक (प्रति सेकंड अनुरोध), एरर (विफल अनुरोधों की दर), और सैचुरेशन (संसाधन उपयोग)।
क्यों: ये चार सिग्नल सेवा स्वास्थ्य और उपयोगकर्ता अनुभव का एक व्यापक, उच्च-स्तरीय दृश्य प्रदान करते हैं, जो लगभग किसी भी प्रकार की सेवा पर लागू होते हैं।
टीमों को चार्जबैक या शोबैक के लिए उनके Kubernetes वर्कलोड की लागत में दृश्यता प्रदान करें।
OpenCost या Kubecost जैसे एक ओपन-सोर्स टूल को डिप्लॉय करें। ये उपकरण क्लाउड लागत को Kubernetes संसाधनों (पॉड्स, नेमस्पेस, लेबल) को उनके संसाधन अनुरोधों और उपयोग के आधार पर आवंटित करते हैं।
क्यों: इंफ्रास्ट्रक्चर बिलों को सार्थक, एप्लिकेशन-केंद्रित लागत डेटा में अनुवादित करता है, जिससे टीमों को उनके संसाधन खपत को समझने और अनुकूलित करने में सक्षम बनाया जा सके।
बड़े पैमाने पर आउटेज के दौरान लक्षणात्मक अलर्ट को दबाकर अलर्ट शोर को कम करें।
Alertmanager में `inhibit_rules` कॉन्फ़िगर करें। उदाहरण के लिए, यदि एक "ClusterUnreachable" अलर्ट पहले से ही फायर हो रहा है, तो एक विशिष्ट क्लस्टर के लिए सभी अलर्ट को रोकें।
क्यों: एक "अलर्ट स्टॉर्म" को रोकता है, कम-प्राथमिकता वाले अलर्ट को चुप कराकर जो उच्च-प्राथमिकता वाले, मूल-कारण अलर्ट के लक्षण हैं, जिससे ऑन-कॉल वास्तविक समस्या पर ध्यान केंद्रित कर सके।
नियंत्रित तरीके से विफलताओं को इंजेक्ट करके प्लेटफ़ॉर्म और एप्लिकेशन लचीलेपन का सक्रिय रूप से परीक्षण करें।
Chaos Mesh या Litmus जैसे अराजकता इंजीनियरिंग उपकरण का उपयोग करें। एक सीमित ब्लास्ट रेडियस (जैसे, विशिष्ट नेमस्पेस या लेबल) और SLOs या महत्वपूर्ण मेट्रिक्स के आधार पर स्वचालित स्टॉप स्थितियों के साथ प्रयोगों को परिभाषित करें।
क्यों: प्रतिक्रियाशील घटना प्रतिक्रिया से आगे बढ़कर सिस्टम में कमजोरियों को सक्रिय रूप से खोजने की ओर बढ़ता है, इससे पहले कि वे उत्पादन आउटेज का कारण बनें।
एक Kubernetes प्लेटफ़ॉर्म पर गार्डरेल्स को लागू करने के लिए एक पॉलिसी इंजन चुनें।
Kubernetes-नेटिव YAML-आधारित नीतियों के लिए Kyverno या एक अधिक शक्तिशाली, सामान्य-उद्देश्य वाली नीति भाषा (Rego) के लिए OPA/Gatekeeper चुनें।
क्यों: Kyverno में Kubernetes इंजीनियरों के लिए प्रवेश की बाधा कम है। OPA/Gatekeeper अधिक लचीला है और Kubernetes के बाहर भी उपयोग किया जा सकता है लेकिन इसकी सीखने की अवस्था कठिन है।
प्लेटफ़ॉर्म नीतियां लागू करें जो गैर-अनुपालन संसाधनों को ब्लॉक कर सकती हैं, डिफ़ॉल्ट मान जोड़ सकती हैं, या स्वचालित रूप से संबंधित संसाधन बना सकती हैं।
Kyverno जैसे एक पॉलिसी इंजन का उपयोग करें। `validate` नियमों का उपयोग ब्लॉक/ऑडिट करने के लिए करें, डिफ़ॉल्ट मान (जैसे, securityContext, लेबल) जोड़ने के लिए `mutate` नियमों का उपयोग करें, और संसाधन बनाने के लिए `generate` नियमों का उपयोग करें (जैसे, डिफ़ॉल्ट NetworkPolicy)।
क्यों: विभिन्न नीति प्रकार विभिन्न उद्देश्यों की पूर्ति करते हैं। उन्हें संयोजित करने से एक मजबूत, बहु-आयामी शासन रणनीति की अनुमति मिलती है जो उपयोगकर्ताओं को अनुपालन करने में मदद करती है और लागू भी करती है।
प्लेटफ़ॉर्म पर चल रहे सभी पॉड्स के लिए बेसलाइन सुरक्षा सुदृढीकरण लागू करें।
अंतर्निहित Pod Security Admission कंट्रोलर के माध्यम से Pod Security Standards (PSS) का उपयोग करें। नेमस्पेस को `pod-security.kubernetes.io/enforce=baseline` या `restricted` से लेबल करें।
क्यों: PSS विशेषाधिकार वृद्धि और होस्ट नेमस्पेस एक्सेस जैसी सामान्य सुरक्षा समस्याओं को रोकने के लिए एक मानकीकृत, अंतर्निहित तंत्र प्रदान करता है, जो एक मूलभूत सुरक्षा परत बनाता है।
सुनिश्चित करें कि केवल विश्वसनीय कंटेनर इमेज, जो आधिकारिक CI/CD पाइपलाइन द्वारा बनाई गई हैं, ही क्लस्टर में डिप्लॉय की जा सकें।
Sigstore/Cosign का उपयोग करके CI में इमेज साइनिंग लागू करें। एक पॉलिसी इंजन (Kyverno, Gatekeeper) का उपयोग एक एडमिशन कंट्रोलर के रूप में करें ताकि एक पॉड बनाने की अनुमति देने से पहले एक विश्वसनीय कुंजी के विरुद्ध इमेज हस्ताक्षर को सत्यापित किया जा सके।
क्यों: क्रिप्टोग्राफिक सत्यापन इमेज की उत्पत्ति और अखंडता के बारे में मजबूत गारंटी प्रदान करता है, जिससे छेड़छाड़ की गई या अनधिकृत इमेज के डिप्लॉयमेंट को रोका जा सके।
एक ज़ीरो-ट्रस्ट सुरक्षा मॉडल लागू करें जहां सेवा-से-सेवा संचार को क्रिप्टोग्राफिक वर्कलोड पहचान द्वारा प्रमाणित किया जाता है, न कि नेटवर्क स्थान द्वारा।
वर्कलोड को अल्पकालिक, घुमाए जाने योग्य क्रिप्टोग्राफिक पहचान (SVIDs) जारी करने के लिए SPIFFE/SPIRE का उपयोग करें। एक सर्विस मेश का उपयोग करके म्यूचुअल TLS (mTLS) लागू करें, जो हर अनुरोध पर SVIDs को मान्य करता है।
क्यों: सुरक्षा को नेटवर्क परिधि नियंत्रणों से वर्कलोड-केंद्रित पहचान पर ले जाता है, आंतरिक ट्रैफिक के लिए भी मजबूत प्रमाणीकरण प्रदान करता है और समझौता किए गए नोड या पॉड के ब्लास्ट रेडियस को सीमित करता है।
नेटवर्क स्तर पर वर्कलोड को अलग करें, एक "डिफ़ॉल्ट-डिनाई" मुद्रा लागू करें और केवल आवश्यक संचार पथों की अनुमति दें।
Kubernetes NetworkPolicies लागू करें। प्रत्येक नेमस्पेस पर एक डिफ़ॉल्ट-डिनाई नीति लागू करें, फिर विशिष्ट इनग्रेस/इग्रेस नीतियां जोड़ें जो पॉड/नेमस्पेस लेबलों के आधार पर ट्रैफिक की अनुमति देती हैं।
क्यों: लेटरल मूवमेंट अटैक सतह को कम करता है। एक पॉड का समझौता स्वचालित रूप से क्लस्टर में अन्य सभी सेवाओं तक नेटवर्क पहुंच प्रदान नहीं करता है।
सुरक्षा और अनुपालन के लिए Kubernetes API सर्वर पर की गई सभी कार्रवाइयों का एक व्यापक और छेड़छाड़-रोधी ऑडिट ट्रेल बनाएं।
API सर्वर पर Kubernetes ऑडिट लॉगिंग सक्षम करें। प्रासंगिक घटनाओं (जैसे, सभी राइट रिक्वेस्ट) को लॉग करने के लिए एक ऑडिट नीति कॉन्फ़िगर करें। ऑडिट लॉग को एक सुरक्षित, अपरिवर्तनीय स्टोरेज बैकएंड या SIEM पर भेजें।
क्यों: ऑडिट लॉग घटना जांच, अनुपालन रिपोर्टिंग (जैसे, PCI-DSS, SOC2), और असामान्य API गतिविधि का पता लगाने के लिए आवश्यक हैं।
