अवधारणाएँ

• 1: अवलोकन
• 2: सर्विसेज, लोड बैलेंसिंग और नेटवर्किंग
• 3: सुरक्षा
• 3.1: क्लाउड नेटिव सुरक्षा और Kubernetes
• 4: नीतियाँ

1 - अवलोकन

यह पृष्ठ कुबेरनेट्स का एक अवलोकन है।

कुबेरनेट्स कंटेनरीकृत वर्कलोड और सेवाओं के प्रबंधन के लिए एक पोर्टेबल, एक्स्टेंसिबल, ओपन-सोर्स प्लेटफॉर्म है, जो घोषणात्मक कॉन्फ़िगरेशन और स्वचालन दोनों की सुविधा प्रदान करता है। इसका एक बड़ा, तेजी से बढ़ता हुआ पारिस्थितिकी तंत्र है। कुबेरनेट्स सेवाएँ, समर्थन और उपकरण व्यापक रूप से उपलब्ध हैं।

कुबेरनेट्स नाम ग्रीक से उत्पन्न हुआ है, जिसका अर्थ है हेल्समैन या पायलट। K8s एक संक्षिप्त नाम के रूप में "K" और "s" के बीच आठ अक्षरों को गिनने का परिणाम है। Google ने 2014 में कुबेरनेट्स प्रोजेक्ट को ओपन-सोर्स किया। कुबेरनेट्स गूगल के 15 से अधिक वर्षों के अनुभव को समुदाय से सर्वोत्तम नस्ल के विचारों और प्रथाओं के साथ बड़े पैमाने पर उत्पादन कार्यभार को जोड़ती है।

काल में वापस जाना

आइए काल में वापस जाकर एक नज़र डालते हैं कि कुबेरनेट्स इतना उपयोगी क्यों है।

पारंपरिक डिप्लॉयमेंट युग: प्रारंभ में, संगठनों ने भौतिक (physical) सर्वरों पर एप्लिकेशन चलाए। भौतिक (physical) सर्वर में एप्लिकेशनो के लिए संसाधन सीमाओं को परिभाषित करने का कोई तरीका नहीं था, और इससे संसाधन आवंटन समस्याएं उत्पन्न हुईं। उदाहरण के लिए, यदि एक से अधिक एप्लिकेशने एक भौतिक सर्वर पर चलते हैं, तो ऐसे उदाहरण हो सकते हैं जहां एक एप्लिकेशन अधिकांश संसाधनों को ले लेगा, और इसके परिणामस्वरूप, अन्य एप्लिकेशने खराब प्रदर्शन करेंगे। इसका एक समाधान यह होगा कि प्रत्येक एप्लिकेशन को एक अलग भौतिक सर्वर पर चलाया जाए। लेकिन यह पैमाना नहीं था क्योंकि संसाधनों का कम उपयोग किया गया था, और संगठनों के लिए कई भौतिक सर्वरों को बनाए रखना महंगा था।

वर्चुअलाइज्ड डिप्लॉयमेंट युग: एक समाधान के रूप में, वर्चुअलाइजेशन पेश किया गया था। यह आपको एक भौतिक सर्वर के सीपीयू (CPU) पर कई वर्चुअल मशीन (वीएम) चलाने की अनुमति देता है। वर्चुअलाइजेशन एप्लिकेशनो को वीएम (VM) के बीच अलग-थलग करने की अनुमति देता है और सुरक्षा का एक स्तर प्रदान करता है क्योंकि एक एप्लिकेशन की जानकारी को दूसरे एप्लिकेशन द्वारा स्वतंत्र रूप से एक्सेस नहीं किया जा सकता है।

वर्चुअलाइजेशन एक भौतिक सर्वर में संसाधनों के बेहतर उपयोग की अनुमति देता है और बेहतर मापनीयता की अनुमति देता है क्योंकि एक एप्लिकेशन को आसानी से जोड़ा या अपडेट किया जा सकता है, हार्डवेयर लागत को कम करता है, और बहुत कुछ। वर्चुअलाइजेशन के साथ आप भौतिक संसाधनों का एक सेट डिस्पोजेबल वर्चुअल मशीनों के समूह के रूप में प्रस्तुत कर सकते हैं।

प्रत्येक वीएम वर्चुअलाइज्ड हार्डवेयर के शीर्ष पर अपने स्वयं के ऑपरेटिंग सिस्टम सहित सभी घटकों को चलाने वाली एक पूर्ण मशीन है।

कंटेनर डिप्लॉयमेंट युग: कंटेनर VMs के समान होते हैं, लेकिन उनके पास एप्लिकेशनो के बीच ऑपरेटिंग सिस्टम (OS) को साझा करने के लिए अलगाव गुण होते हैं। इसलिए, कंटेनरों को हल्का माना जाता है। वीएम (VM) के समान, एक कंटेनर का अपना फाइल सिस्टम, सीपीयू का हिस्सा, मेमोरी, प्रोसेस स्पेस और बहुत कुछ होता है। चूंकि वे अंतर्निहित बुनियादी ढांचे से अलग हो गए हैं, वे बादलों और ओएस (OS) वितरण में पोर्टेबल हैं।

कंटेनर लोकप्रिय हो गए हैं क्योंकि वे अतिरिक्त लाभ प्रदान करते हैं, जैसे:

• अजाइल (Agile) एप्लिकेशन निर्माण और डिप्लॉयमेंट: VM इमेज उपयोग की तुलना में कंटेनर इमेज निर्माण की आसानी और दक्षता में वृद्धि हुई है।
• निरंतर विकास, एकीकरण और डिप्लॉयमेंट: विश्वसनीय और लगातार कंटेनर इमेज निर्माण और त्वरित और कुशल रोलबैक के साथ तैनाती (इमेज अपरिवर्तनीयता के कारण) प्रदान करता है।
• डेव (Dev) और ऑप्स (Ops) चिंताओं का पृथक्करण: डिप्लॉयमेंट समय के बजाय बिल्ड/रिलीज़ समय पर एप्लिकेशन कंटेनर इमेजेस (images) बनाएं, जिससे बुनियादी ढांचे से एप्लिकेशनो को अलग किया जा सके।
• अवलोकन: न केवल ओएस-स्तर की जानकारी और मेट्रिक्स को सतह पर रखता है, बल्कि एप्लिकेशन स्वास्थ्य और अन्य संकेतों को भी लागू करता है।
• विकास, परीक्षण और उत्पादन में पर्यावरणीय स्थिरता: लैपटॉप पर वैसे ही चलता है जैसे क्लाउड में चलता है।
• क्लाउड और ओएस (OS) वितरण पोर्टेबिलिटी: उबंटू, RHEL, coreOS, ऑन-प्रिमाइसेस, प्रमुख सार्वजनिक क्लाउड पर और कहीं भी चलता है।
• एप्लिकेशन-केंद्रित प्रबंधन: वर्चुअल हार्डवेयर पर OS चलाने से लेकर तार्किक संसाधनों का उपयोग करके OS पर एप्लिकेशन चलाने तक अमूर्तता के स्तर को बढ़ाता है ।
• शिथिल युग्मित, वितरित, लोचदार, मुक्त सूक्ष्म सेवाएँ: एप्लिकेशन को छोटे, स्वतंत्र टुकड़ों में तोड़ा जाता है और उन्हें गतिशील रूप से तैनात और प्रबंधित किया जा सकता है - एक बड़ी एकल-उद्देश्य वाली मशीन पर चलने वाला एक मोनोलिथिक स्टैक नहीं।
• संसाधन अलगाव: अनुमानित एप्लिकेशन प्रदर्शन।
• संसाधन उपयोग: उच्च दक्षता और घनत्व।

आपको कुबेरनेट्स की आवश्यकता क्यों है और यह क्या कर सकता है

कंटेनर आपके एप्लिकेशनो को बंडल करने और चलाने का एक अच्छा तरीका है। उत्पादन के माहौल में, आप को उन कंटेनरों को प्रबंधित करने की आवश्यकता होती है जो एप्लिकेशने चलाते हैं और सुनिश्चित करते हैं कि कोई डाउनटाइम नहीं है। उदाहरण के लिए, यदि एक कंटेनर बंद हो जाता है, तो दूसरे कंटेनर को शुरू करने की आवश्यकता होती है। क्या यह आसान नहीं होगा यदि इस व्यवहार को एक प्रणाली द्वारा नियंत्रित किया जा सके ?

इस तरह कुबेरनेट्स बचाव के लिए आता है! कुबेरनेट्स आपको वितरित सिस्टम को लचीलेपन से चलाने के लिए एक ढांचा प्रदान करता है। यह आपके एप्लिकेशन के लिए स्केलिंग और फेलओवर का ख्याल रखता है, डिप्लॉयमेंट पैटर्न प्रदान करता है, और भी बहुत कुछ। उदाहरण के लिए, कुबेरनेट्स आपके सिस्टम के लिए कैनरी डिप्लॉयमेंट को आसानी से प्रबंधित कर सकता है।

कुबेरनेट्स आपको प्रदान करता है:

• सेवा की खोज और लोड संतुलन कुबेरनेट्स DNS नाम का उपयोग करके या अपने स्वयं के आईपी (IP) पते का उपयोग करके एक कंटेनर को उजागर कर सकता हैं। यदि एक कंटेनर में ट्रैफ़िक अधिक है, तो कुबेरनेट्स लोड बैलेंस करने और नेटवर्क ट्रैफ़िक को वितरित करने में सक्षम है ताकि डिप्लॉयमेंट स्थिर हो।
• स्टोरेज ऑर्केस्ट्रेशन कुबेरनेट्स आपको अपनी पसंद के स्टोरेज सिस्टम को स्वचालित रूप से माउंट करने की अनुमति देता है, जैसे कि स्थानीय स्टोरेज, पब्लिक क्लाउड प्रोवाइडर, और बहुत कुछ।
• स्वचालित रोलआउट और रोलबैक आप कुबेरनेट्स का उपयोग करके अपने तैनात कंटेनरों के लिए वांछित स्थिति का वर्णन कर सकते हैं, और यह वास्तविक स्थिति को नियंत्रित दर पर वांछित स्थिति में बदल सकता है। उदाहरण के लिए, आप अपने डिप्लॉयमेंट के लिए नए कंटेनर बनाने के लिए कुबेरनेट्स को स्वचालित कर सकते हैं, मौजूदा कंटेनरों को हटा सकते हैं और उनके सभी संसाधनों को नए कंटेनर में अपना सकते हैं।
• **स्वचालित बिन पैकिंग ** आप कुबेरनेट्स को नोड्स के एक समूह के साथ प्रदान करते हैं जिसका उपयोग वह कंटेनरीकृत कार्यों को चलाने के लिए कर सकता है। आप कुबेरनेट्स को बताते हैं कि प्रत्येक कंटेनर को कितना सीपीयू और मेमोरी (रैम) चाहिए। कुबेरनेट्स आपके संसाधनों का सर्वोत्तम उपयोग करने के लिए कंटेनरों को आपके नोड्स में फिट कर सकता है।
• सेल्फ-हीलिंग कुबेरनेट्स विफल कंटेनरों को फिर से शुरू करता है, कंटेनरों को बदल देता है, उन कंटेनरों को नष्ट कर देता है जो आपकी उपयोगकर्ता-परिभाषित स्वास्थ्य जांच का जवाब नहीं देते हैं, और जब तक वे सेवा के लिए तैयार नहीं होते हैं, तब तक ग्राहकों को उनका विज्ञापन नहीं करते हैं।
• सीक्रेट और कॉन्फ़िगरेशन प्रबंधन कुबेरनेट्स आपको पासवर्ड, OAuth टोकन और SSH कुंजियों जैसी संवेदनशील जानकारी को संग्रहीत और प्रबंधित करने देता है। आप अपनी कंटेनर इमेजेस (images) के पुनर्निर्माण के बिना, और अपने स्टैक कॉन्फ़िगरेशन में रहस्यों को उजागर किए बिना रहस्यों और एप्लिकेशन कॉन्फ़िगरेशन को तैनात और अपडेट कर सकते हैं।

कुबेरनेट्स क्या नहीं है :

कुबेरनेट्स एक पारंपरिक, सर्व-समावेशी PaaS (एक सेवा के रूप में प्लेटफ़ॉर्म) प्रणाली नहीं है। चूंकि कुबेरनेट्स हार्डवेयर स्तर के बजाय कंटेनर स्तर पर काम करता है, यह कुछ सामान्य रूप से लागू सुविधाओं को प्रदान करता है, जैसे कि तैनाती, स्केलिंग, लोड बैलेंसिंग, और उपयोगकर्ताओं को उनके लॉगिंग, निगरानी और अलर्ट समाधान को एकीकृत करने देता है। हालाँकि, कुबेरनेट्स मोनोलिथिक नहीं है, और ये डिफ़ॉल्ट समाधान वैकल्पिक और प्लग करने योग्य हैं। कुबेरनेट्स डेवलपर प्लेटफॉर्म के निर्माण के लिए बिल्डिंग ब्लॉक्स प्रदान करता है, लेकिन जहां यह महत्वपूर्ण है वहां उपयोगकर्ता की पसंद और लचीलेपन को बरकरार रखता है।

कुबेरनेट्स:

• समर्थित एप्लिकेशनो के प्रकारों को सीमित नहीं करता है। कुबेरनेट्स का उद्देश्य स्टेटलेस, स्टेटफुल और डेटा-प्रोसेसिंग वर्कलोड सहित अत्यंत विविध प्रकार के वर्कलोड का समर्थन करना है। यदि कोई एप्लिकेशन कंटेनर में चल सकता है, तो उसे कुबेरनेट्स पर बहुत अच्छा चलना चाहिए।
• स्रोत कोड डेप्लॉय नहीं करता है और आपके एप्लिकेशन का निर्माण नहीं करता है। कंटीन्यूअस इंटीग्रेशन, डिलीवरी और डिप्लॉयमेंट(CI/CD) कार्यप्रवाह संगठन संस्कृतियों और प्राथमिकताओं के साथ-साथ तकनीकी आवश्यकताओं द्वारा निर्धारित किए जाते हैं।
• एप्लिकेशन-स्तरीय सेवाएं प्रदान नहीं करता है, जैसे कि मिडलवेयर (उदाहरण के लिए, message buses), डेटा-प्रोसेसिंग फ्रेमवर्क (उदाहरण के लिए, spark), डेटाबेस (उदाहरण के लिए, MySQL), कैश, और न ही क्लस्टर स्टोरेज सिस्टम (उदाहरण के लिए, Ceph) अंतर्निहित सेवाओं के रूप में। ऐसे घटक कुबेरनेट्स पर चल सकते हैं, और/या ओपन सर्विस ब्रोकर जैसे पोर्टेबल तंत्र के माध्यम से कुबेरनेट्स पर चल रहे एप्लिकेशनो द्वारा एक्सेस किए जा सकते हैं।
• लॉगिंग, मॉनिटरिंग या अलर्टिंग सॉल्यूशंस को निर्देशित नहीं करता है। यह अवधारणा के प्रमाण के रूप में कुछ एकीकरण प्रदान करता है, और मेट्रिक्स एकत्र करने और निर्यात करने के लिए तंत्र प्रदान करता है।
• कॉन्फ़िगरेशन भाषा/सिस्टम (उदाहरण के लिए, Jsonnet) प्रदान नहीं करता है और न ही अनिवार्य करता है। यह एक घोषणात्मक API प्रदान करता है जिसे घोषणात्मक विनिर्देशों के मनमाने रूपों द्वारा लक्षित किया जा सकता है।
• कोई व्यापक मशीन कॉन्फ़िगरेशन, रखरखाव, प्रबंधन, या स्वयं-उपचार प्रणाली प्रदान नहीं करता है और न ही अपनाता है।
• इसके अतिरिक्त, कुबेरनेट्स केवल एक ऑर्केस्ट्रेशन प्रणाली नहीं है। वास्तव में, यह ऑर्केस्ट्रेशन की आवश्यकता को समाप्त करता है। ऑर्केस्ट्रेशन की तकनीकी परिभाषा एक परिभाषित वर्कफ़्लो का निष्पादन है: पहले ए (A) करें, फिर बी (B), फिर सी (C)। इसके विपरीत, कुबेरनेट्स में स्वतंत्र, कंपोज़ेबल नियंत्रण प्रक्रियाओं का एक सेट शामिल है जो वर्तमान स्थिति को प्रदान की गई वांछित स्थिति की ओर लगातार चलता है। इससे कोई फर्क नहीं पड़ता कि आप ए से सी कैसे प्राप्त करते हैं। केंद्रीकृत नियंत्रण की भी आवश्यकता नहीं है। इसका परिणाम एक ऐसी प्रणाली में होता है जो उपयोग में आसान और अधिक शक्तिशाली, मजबूत, लचीला और एक्स्टेंसिबल है।

आगे क्या है

• कुबेरनेट्स के घटक पर एक नज़र डालें ।
• क्या आप शुरू करने के लिए तैयार हैं?

2 - सर्विसेज, लोड बैलेंसिंग और नेटवर्किंग

कुबेर्नेट्स नेटवर्क मॉडल

कुबेर्नेट्स नेटवर्क मॉडल कई हिस्सों से बना है:

• क्लस्टर में प्रत्येक पॉड को अपना विशिष्ट क्लस्टर-व्यापी IP एड्रेस मिलता है।

क्लस्टर में प्रत्येक पॉड को अपना विशिष्ट क्लस्टर-व्यापी IP एड्रेस मिलता है।

• एक पॉड का अपना निजी नेटवर्क नेमस्पेस होता है जिसे उस पॉड के सभी कंटेनर आपस में साझा करते हैं। एक ही पॉड में अलग-अलग कंटेनरों में चलने वाले प्रोसेस localhost के माध्यम से एक-दूसरे से बात कर सकते हैं।

• पॉड नेटवर्क (जिसे क्लस्टर नेटवर्क भी कहा जाता है) पॉड्स के बीच संचार को संभालता है। यह सुनिश्चित करता है कि (जानबूझकर नेटवर्क विभाजन को छोड़कर):

  • सभी पॉड्स सभी अन्य पॉड्स से बात कर सकते हैं, चाहे वे एक ही नोड पर हों या अलग-अलग नोड्स पर। पॉड्स सीधे एक-दूसरे से बिना किसी प्रॉक्सी या एड्रेस ट्रांसलेशन (NAT) के बात कर सकते हैं।

    Windows पर, यह नियम होस्ट-नेटवर्क पॉड्स पर लागू नहीं होता।

  • नोड पर एजेंट (जैसे सिस्टम डेमॉन या kubelet) उस नोड पर सभी पॉड्स से बात कर सकते हैं।

• सर्विस API आपको एक स्थायी IP एड्रेस या होस्टनेम प्रदान करता है जो एक या अधिक बैकएंड पॉड्स द्वारा चलाई जा रही सर्विस के लिए होता है। सर्विस बनाने वाले पॉड्स समय के साथ बदल सकते हैं।

  • कुबेर्नेट्स अपने आप एंडपॉइंटस्लाइस ऑब्जेक्ट्स को मैनेज करता है ताकि सर्विस के वर्तमान पॉड्स की जानकारी उपलब्ध रहे।

  • एक सर्विस प्रॉक्सी इम्प्लीमेंटेशन Service और EndpointSlice ऑब्जेक्ट्स के सेट की निगरानी करता है और डेटा प्लेन को प्रोग्राम करता है ताकि सर्विस ट्रैफिक को उसके बैकएंड्स तक रूट किया जा सके। यह ऑपरेटिंग सिस्टम या क्लाउड प्रोवाइडर के API का उपयोग करके पैकेट्स को इंटरसेप्ट या रीराइट करता है।

• गेटवे API (या इसका पहले का वर्जन, इंग्रेस) आपको क्लस्टर के बाहर के क्लाइंट्स के लिए सर्विसेज को एक्सेस करने की सुविधा देता है।

  • क्लस्टर में बाहर से एक्सेस के लिए एक सरल, लेकिन कम कॉन्फ़िगर करने योग्य तरीका सर्विस API के type: LoadBalancer के माध्यम से उपलब्ध है, जब एक सपोर्टेड क्लाउड प्रदाता (Cloud Provider) का उपयोग किया जाता है।

• नेटवर्क पॉलिसी एक बिल्ट-इन Kubernetes API है जो आपको पॉड्स के बीच या पॉड्स और बाहरी दुनिया के बीच ट्रैफ़िक को नियंत्रित करने की अनुमति देता है।

पुराने कंटेनर सिस्टम में, विभिन्न होस्ट्स पर कंटेनरों के बीच स्वचालित कनेक्टिविटी नहीं होती थी, इसलिए कंटेनरों के बीच स्पष्ट लिंक बनाना या अन्य होस्ट्स पर कंटेनरों द्वारा उन्हें सुलभ बनाने के लिए कंटेनर पोर्ट्स को होस्ट पोर्ट्स पर मैप करना अक्सर आवश्यक होता था। Kubernetes में यह आवश्यक नहीं है; Kubernetes का मॉडल है कि पॉड्स को VMs या भौतिक होस्ट्स की तरह माना जा सकता है, पोर्ट आवंटन, नामकरण, सर्विस डिस्कवरी, लोड बैलेंसिंग, एप्लिकेशन कॉन्फ़िगरेशन और माइग्रेशन के दृष्टिकोण से।

इस मॉडल के केवल कुछ हिस्से ही Kubernetes द्वारा स्वयं लागू किए जाते हैं। अन्य भागों के लिए, Kubernetes API को परिभाषित करता है, लेकिन संबंधित कार्यक्षमता बाहरी घटकों द्वारा प्रदान की जाती है, जिनमें से कुछ वैकल्पिक हैं:

• पॉड नेटवर्क नेमस्पेस सेटअप कंटेनर रनटाइम इंटरफ़ेस को लागू करने वाले सिस्टम-स्तरीय सॉफ़्टवेयर द्वारा संभाला जाता है।

• पॉड नेटवर्क का प्रबंधन एक पॉड नेटवर्क कार्यान्वयन द्वारा किया जाता है। Linux पर, अधिकांश कंटेनर रनटाइम्स पॉड नेटवर्क कार्यान्वयन के साथ इंटरैक्ट करने के लिए कंटेनर नेटवर्किंग इंटरफ़ेस (CNI) का उपयोग करते हैं, इसलिए इन कार्यान्वयनों को अक्सर CNI प्लगइन्स कहा जाता है।

• Kubernetes सर्विस प्रॉक्सींग का एक डिफ़ॉल्ट कार्यान्वयन प्रदान करता है, जिसे kube-proxy कहा जाता है, लेकिन कुछ पॉड नेटवर्क कार्यान्वयन इसके बजाय अपने स्वयं के सर्विस प्रॉक्सी का उपयोग करते हैं जो शेष कार्यान्वयन के साथ अधिक दृढ़ता से एकीकृत होता है।

• NetworkPolicy आमतौर पर पॉड नेटवर्क कार्यान्वयन द्वारा भी लागू की जाती है। (कुछ सरल पॉड नेटवर्क कार्यान्वयन NetworkPolicy को लागू नहीं करते हैं, या एक व्यवस्थापक पॉड नेटवर्क को NetworkPolicy समर्थन के बिना कॉन्फ़िगर करना चुन सकता है। इन मामलों में, API अभी भी मौजूद होगा, लेकिन उसका कोई प्रभाव नहीं होगा।)

• गेटवे API के कई कार्यान्वयन हैं, जिनमें से कुछ विशेष क्लाउड ए

आगे क्या है

सर्विसेज के साथ अनुप्रयोगों को कनेक्ट करना ट्यूटोरियल आपको एक व्यावहारिक उदाहरण के साथ सर्विसेज और Kubernetes नेटवर्किंग के बारे में सीखने में मदद करता है।

क्लस्टर नेटवर्किंग बताता है कि अपने क्लस्टर के लिए नेटवर्किंग कैसे सेटअप करें, और शामिल प्रौद्योगिकियों का एक समीक्षा भी प्रदान करता है।

3 - सुरक्षा

यह Kubernetes दस्तावेज़ीकरण अनुभाग आपको वर्कलोड को अधिक सुरक्षित तरीके से चलाने और Kubernetes क्लस्टर को सुरक्षित रखने के आवश्यक पहलुओं के बारे में सीखने में मदद करता है।

Kubernetes एक क्लाउड-नेटिव आर्किटेक्चर पर आधारित है और क्लाउड नेटिव सूचना सुरक्षा के लिए अच्छे अभ्यास के बारे में CNCF की सलाह का उपयोग करता है।

अपने क्लस्टर और उस पर चलाए जा रहे एप्लिकेशन को सुरक्षित करने के व्यापक संदर्भ के लिए Cloud Native Security and Kubernetes पढ़ें।

Kubernetes सुरक्षा तंत्र

Kubernetes में कई API और सुरक्षा नियंत्रण शामिल हैं, साथ ही नीतियाँ परिभाषित करने के तरीके भी हैं जो सूचना सुरक्षा प्रबंधन का हिस्सा बन सकते हैं।

कंट्रोल प्लेन सुरक्षा

किसी भी Kubernetes क्लस्टर के लिए एक प्रमुख सुरक्षा तंत्र Kubernetes API तक पहुँच को नियंत्रित करना है। कुबेरनेट्स आपसे अपेक्षा करता है कि आप कंट्रोल प्लेन के भीतर और कंट्रोल प्लेन एवं उसके क्लाइंट्स के बीच ट्रांजिट में डेटा एन्क्रिप्शन प्रदान करने के लिए TLS को कॉन्फ़िगर और उपयोग करें। आप कुबेरनेट्स कंट्रोल प्लेन के भीतर संग्रहीत डेटा के लिए एट-रेस्ट एन्क्रिप्शन भी सक्षम कर सकते हैं; यह आपके अपने वर्कलोड के डेटा के लिए एट-रेस्ट एन्क्रिप्शन का उपयोग करने से अलग है, जो कि एक अच्छा विचार हो सकता है।

सीक्रेट्स

Secret API उन कॉन्फ़िगरेशन मानों के लिए बुनियादी सुरक्षा प्रदान करता है जिन्हें गोपनीयता की आवश्यकता होती है।

वर्कलोड सुरक्षा

Pod security standards लागू करें ताकि यह सुनिश्चित हो सके कि Pods और उनके कंटेनर उचित रूप से अलग हैं। यदि आवश्यक हो तो आप कस्टम अलगाव परिभाषित करने के लिए RuntimeClasses का भी उपयोग कर सकते हैं।

नेटवर्क नीतियाँ आपको पॉड्स के बीच, या पॉड्स और आपके क्लस्टर के बाहर के नेटवर्क के बीच नेटवर्क ट्रैफिक को नियंत्रित करने देती हैं।

आप पॉड्स, उनके कंटेनरों और उनमें चलने वाली छवियों (images) के आसपास निवारक या खोजी नियंत्रण लागू करने के लिए व्यापक इकोसिस्टम से सुरक्षा नियंत्रण तैनात कर सकते हैं।

एडमिशन कंट्रोल

Admission controllers ऐसे प्लगइन हैं जो Kubernetes API अनुरोधों को इंटरसेप्ट करते हैं और अनुरोध में विशिष्ट फ़ील्ड के आधार पर अनुरोधों को मान्य या परिवर्तित कर सकते हैं। इन नियंत्रकों को विचारपूर्वक डिज़ाइन करने से Kubernetes APIs के संस्करण अपडेट में बदलने पर अनपेक्षित व्यवधानों से बचने में मदद मिलती है। डिज़ाइन संबंधी विचारों के लिए, Admission Webhook Good Practices देखें।

ऑडिटिंग

Kubernetes audit logging एक सुरक्षा-प्रासंगिक, कालानुक्रमिक रिकॉर्ड सेट प्रदान करता है जो क्लस्टर में कार्यों के अनुक्रम को दस्तावेज़ीकरण करता है। क्लस्टर उपयोगकर्ताओं द्वारा, Kubernetes API का उपयोग करने वाले एप्लिकेशन द्वारा, और कंट्रोल प्लेन द्वारा उत्पन्न गतिविधियों का ऑडिट करता है।

क्लाउड प्रदाता सुरक्षा

यदि आप अपने हार्डवेयर या किसी भिन्न क्लाउड प्रदाता पर Kubernetes क्लस्टर चला रहे हैं, तो सुरक्षा सर्वोत्तम प्रथाओं के लिए अपने दस्तावेज़ीकरण से परामर्श करें। नीचे कुछ लोकप्रिय क्लाउड प्रदाताओं के सुरक्षा दस्तावेज़ीकरण के लिंक दिए गए हैं:

नीतियाँ

आप Kubernetes-नेटिव तंत्रों का उपयोग करके सुरक्षा नीतियाँ परिभाषित कर सकते हैं, जैसे NetworkPolicy (नेटवर्क पैकेट फ़िल्टरिंग पर घोषणात्मक नियंत्रण) या ValidatingAdmissionPolicy (Kubernetes API का उपयोग करके कोई कौन से परिवर्तन कर सकता है इस पर घोषणात्मक प्रतिबंध)।

हालाँकि, आप कुबेरनेट्स के आसपास के व्यापक इकोसिस्टम (ecosystem) से नीति कार्यान्वयन पर भी भरोसा कर सकते हैं। कुबेरनेट्स ऐसे एक्सटेंशन तंत्र प्रदान करता है जिससे वे इकोसिस्टम प्रोजेक्ट्स सोर्स कोड समीक्षा, कंटेनर इमेज अनुमोदन, API एक्सेस कंट्रोल, नेटवर्किंग और बहुत कुछ पर अपने स्वयं के नीति नियंत्रण लागू कर सकें।

नीति तंत्रों और Kubernetes के बारे में अधिक जानकारी के लिए, Policies पढ़ें।

संबंधित Kubernetes सुरक्षा विषयों के बारे में जानें:

• अपने क्लस्टर को सुरक्षित करना
• ज्ञात कमज़ोरियाँ (और आगे की जानकारी के लिंक)
• ट्रांज़िट में डेटा एन्क्रिप्शनकंट्रोल प्लेन के लिए
• रेस्ट में डेटा एन्क्रिप्शन
• Kubernetes API तक पहुँच नियंत्रित करना
• पॉड्स के लिए नेटवर्क नीतियाँ
• Kubernetes में सीक्रेट्स
• Pod security standards
• RuntimeClasses

संदर्भ जानें:

• क्लाउड नेटिव सुरक्षा और कुबेरनेट्स

प्रमाणित हों:

• Certified Kubernetes Security Specialist प्रमाणन और आधिकारिक प्रशिक्षण पाठ्यक्रम।

इस अनुभाग में और पढ़ें:

3.1 - क्लाउड नेटिव सुरक्षा और Kubernetes

Kubernetes एक क्लाउड नेटिव आर्किटेक्चर पर आधारित है और क्लाउड नेटिव सूचना सुरक्षा के लिए अच्छे अभ्यास के बारे में CNCF की सलाह का उपयोग करता है।

आगे पढ़ें और जानें कि Kubernetes आपको एक सुरक्षित क्लाउड नेटिव प्लेटफ़ॉर्म तैनात करने में कैसे मदद करने के लिए डिज़ाइन किया गया है।

क्लाउड नेटिव सूचना सुरक्षा

क्लाउड नेटिव सुरक्षा पर CNCF का श्वेत पत्र सुरक्षा नियंत्रणों और प्रथाओं को परिभाषित करता है जो विभिन्न जीवनचक्र चरणों के लिए उपयुक्त हैं।

Develop जीवनचक्र चरण

• विकास परिवेशों की अखंडता सुनिश्चित करें।
• अपने संदर्भ के लिए उपयुक्त सूचना सुरक्षा की अच्छी प्रथाओं का पालन करते हुए एप्लिकेशन डिज़ाइन करें।
• समाधान डिज़ाइन के हिस्से के रूप में अंतिम उपयोगकर्ता सुरक्षा पर विचार करें।

इसे प्राप्त करने के लिए, आप यह कर सकते हैं:

1. एक ऐसी आर्किटेक्चर अपनाएँ, जैसे zero trust, जो आंतरिक खतरों के लिए भी अटैक सर्फेस को कम करती है।
2. एक कोड समीक्षा प्रक्रिया परिभाषित करें जो सुरक्षा संबंधी चिंताओं पर विचार करे।
3. अपने सिस्टम या एप्लिकेशन का एक थ्रेट मॉडल बनाएँ जो ट्रस्ट सीमाओं की पहचान करे। उस थ्रेट मॉडल का उपयोग जोखिमों की पहचान करने और उन्हें कैसे संभालना है यह निर्धारित करने के लिए करें।
4. उन्नत सुरक्षा स्वचालन शामिल करें, जैसे fuzzing और security chaos engineering, जहाँ यह उचित हो।

Distribute जीवनचक्र चरण

• आप जो कंटेनर इमेज निष्पादित करते हैं उनकी सप्लाई चेन की सुरक्षा सुनिश्चित करें।
• क्लस्टर और अन्य घटकों की सप्लाई चेन की सुरक्षा सुनिश्चित करें जो आपका एप्लिकेशन निष्पादित करते हैं। उदाहरण के लिए, इसमें एक बाहरी डेटाबेस शामिल हो सकता है जिसे आपका क्लाउड नेटिव एप्लिकेशन persistence के लिए उपयोग करता है।

इसे प्राप्त करने के लिए, आप यह कर सकते हैं:

1. ज्ञात कमज़ोरियों के लिए कंटेनर इमेज और अन्य आर्टिफैक्ट स्कैन करें।
2. सुनिश्चित करें कि सॉफ़्टवेयर वितरण ट्रांज़िट में एन्क्रिप्शन का उपयोग करे, सॉफ़्टवेयर स्रोत के लिए विश्वास की श्रृंखला के साथ।
3. अपडेट उपलब्ध होने पर, विशेष रूप से सुरक्षा घोषणाओं के जवाब में, dependencies अपडेट करने की प्रक्रियाएँ अपनाएँ और उनका पालन करें।
4. सप्लाई चेन आश्वासन के लिए डिजिटल प्रमाणपत्र जैसे सत्यापन तंत्र का उपयोग करें।
5. सुरक्षा जोखिमों के बारे में सचेत करने के लिए फ़ीड और अन्य तंत्रों की सदस्यता लें।
6. आर्टिफैक्ट तक पहुँच प्रतिबंधित करें। कंटेनर इमेज को एक प्राइवेट रजिस्ट्री में रखें जो केवल अधिकृत क्लाइंट को इमेज pull करने की अनुमति देती है।

Deploy जीवनचक्र चरण

यह सुनिश्चित करें कि क्या तैनात किया जा सकता है, कौन इसे तैनात कर सकता है, और इसे कहाँ तैनात किया जा सकता है, इस पर उचित प्रतिबंध हों। आप distribute चरण के उपाय लागू कर सकते हैं, जैसे कंटेनर इमेज आर्टिफैक्ट की क्रिप्टोग्राफ़िक पहचान सत्यापित करना।

आप विभिन्न एप्लिकेशन और क्लस्टर घटकों को अलग-अलग namespaces में तैनात कर सकते हैं। कंटेनर और namespaces दोनों अलगाव तंत्र प्रदान करते हैं जो सूचना सुरक्षा के लिए प्रासंगिक हैं।

जब आप Kubernetes तैनात करते हैं, तो आप अपने एप्लिकेशन के रनटाइम परिवेश की नींव भी रखते हैं: एक Kubernetes क्लस्टर (या कई क्लस्टर)। उस इंफ्रास्ट्रक्चर को वे सुरक्षा गारंटी प्रदान करनी होगी जिनकी उच्च परतें अपेक्षा करती हैं।

Runtime जीवनचक्र चरण

Runtime चरण में तीन महत्वपूर्ण क्षेत्र शामिल हैं: एक्सेस, कंप्यूट, और स्टोरेज।

Runtime सुरक्षा: एक्सेस

Kubernetes API ही आपके क्लस्टर को काम करवाती है। इस API की सुरक्षा करना प्रभावी क्लस्टर सुरक्षा प्रदान करने की कुंजी है।

Kubernetes दस्तावेज़ीकरण के अन्य पृष्ठों में एक्सेस नियंत्रण के विशिष्ट पहलुओं को कैसे सेट करें इस बारे में अधिक विवरण है। security checklist आपके क्लस्टर के लिए सुझाए गए बुनियादी जाँच प्रदान करती है।

इसके अलावा, आपके क्लस्टर को सुरक्षित करने का अर्थ है API एक्सेस के लिए प्रभावी authentication और authorization लागू करना। वर्कलोड और क्लस्टर घटकों के लिए सुरक्षा पहचान प्रदान करने और प्रबंधित करने के लिए ServiceAccounts का उपयोग करें।

Kubernetes API ट्रैफ़िक की सुरक्षा के लिए TLS का उपयोग करता है; सुनिश्चित करें कि आप TLS का उपयोग करके क्लस्टर तैनात करें (नोड्स और कंट्रोल प्लेन के बीच ट्रैफ़िक सहित) और एन्क्रिप्शन कुंजियों की सुरक्षा करें। यदि आप CertificateSigningRequests के लिए Kubernetes के अपने API का उपयोग करते हैं, तो वहाँ दुरुपयोग को प्रतिबंधित करने पर विशेष ध्यान दें।

Runtime सुरक्षा: कंप्यूट

Containers दो चीज़ें प्रदान करते हैं: एप्लिकेशन के बीच अलगाव और उन अलग-अलग एप्लिकेशन को एक ही होस्ट कंप्यूटर पर चलाने के लिए संयोजित करने का एक तंत्र। वे दो पहलू—अलगाव और एकत्रीकरण—का अर्थ है कि रनटाइम सुरक्षा में ट्रेडऑफ़ की पहचान करना और एक उचित संतुलन खोजना शामिल है।

Kubernetes कंटेनर सेट अप और चलाने के लिए एक container runtime पर निर्भर करता है। Kubernetes प्रोजेक्ट किसी विशिष्ट कंटेनर रनटाइम की अनुशंसा नहीं करता है, और आपको यह सुनिश्चित करना चाहिए कि आपके द्वारा चुना गया रनटाइम आपकी सूचना सुरक्षा आवश्यकताओं को पूरा करता है।

रनटाइम पर अपने कंप्यूट की सुरक्षा के लिए, आप यह कर सकते हैं:

1. एप्लिकेशन के लिए Pod Security Standards लागू करें ताकि यह सुनिश्चित हो सके कि वे केवल आवश्यक privileges के साथ चलें।

2. अपने नोड्स पर एक विशेष ऑपरेटिंग सिस्टम चलाएँ जो विशेष रूप से containerized वर्कलोड चलाने के लिए डिज़ाइन किया गया हो। यह आमतौर पर एक रीड-ओनली ऑपरेटिंग सिस्टम (immutable image) पर आधारित होता है जो केवल कंटेनर चलाने के लिए आवश्यक सेवाएँ प्रदान करता है।

   कंटेनर-विशिष्ट ऑपरेटिंग सिस्टम सिस्टम घटकों को अलग करने में मदद करते हैं और कंटेनर एस्केप की स्थिति में एक कम अटैक सर्फेस प्रस्तुत करते हैं।

3. साझा संसाधनों को उचित रूप से आवंटित करने के लिए ResourceQuotas परिभाषित करें, और यह सुनिश्चित करने के लिए कि Pods अपनी संसाधन आवश्यकताओं को निर्दिष्ट करें, LimitRanges जैसे तंत्रों का उपयोग करें।

4. अलगाव में सुधार के लिए वर्कलोड को विभिन्न नोड्स में विभाजित करें। यह सुनिश्चित करने के लिए कि विभिन्न ट्रस्ट संदर्भों वाले Pods अलग नोड सेट पर चलें, Kubernetes से या पारिस्थितिकी तंत्र से node isolation तंत्रों का उपयोग करें।

5. एक container runtime का उपयोग करें जो सुरक्षा प्रतिबंध प्रदान करता है।

6. Linux नोड्स पर, Linux सुरक्षा मॉड्यूल जैसे AppArmor या seccomp का उपयोग करें।

Runtime सुरक्षा: स्टोरेज

अपने क्लस्टर और उस पर चलने वाले एप्लिकेशन के लिए स्टोरेज की सुरक्षा के लिए, आप यह कर सकते हैं:

1. अपने क्लस्टर को एक बाहरी स्टोरेज प्लगइन के साथ एकीकृत करें जो volumes के लिए रेस्ट में एन्क्रिप्शन प्रदान करता है।
2. API ऑब्जेक्ट के लिए encryption at rest सक्षम करें।
3. बैकअप का उपयोग करके डेटा स्थायित्व की सुरक्षा करें, और सत्यापित करें कि आप जब भी आवश्यक हो उन्हें पुनर्स्थापित कर सकते हैं।
4. क्लस्टर नोड्स और उनके द्वारा उपयोग किए जाने वाले किसी भी नेटवर्क स्टोरेज के बीच कनेक्शन प्रमाणित करें।
5. अपने स्वयं के एप्लिकेशन के भीतर डेटा एन्क्रिप्शन लागू करें।

एन्क्रिप्शन कुंजियों के लिए, विशेष हार्डवेयर के भीतर इन्हें उत्पन्न करना प्रकटीकरण जोखिमों के विरुद्ध सर्वोत्तम सुरक्षा प्रदान करता है। एक hardware security module आपको क्रिप्टोग्राफ़िक ऑपरेशन करने की अनुमति दे सकता है बिना सुरक्षा कुंजी को कहीं और कॉपी होने दिए।

नेटवर्किंग और सुरक्षा

आपको नेटवर्क सुरक्षा उपायों पर भी विचार करना चाहिए, जैसे NetworkPolicy या एक service mesh। Kubernetes के कुछ नेटवर्क प्लगइन वर्चुअल प्राइवेट नेटवर्क (VPN) ओवरले जैसी तकनीकों का उपयोग करके आपके क्लस्टर नेटवर्क के लिए एन्क्रिप्शन प्रदान करते हैं। डिज़ाइन के अनुसार, Kubernetes आपको अपने क्लस्टर के लिए अपना नेटवर्किंग प्लगइन उपयोग करने देता है। यदि आप managed Kubernetes का उपयोग करते हैं, तो प्रदाता ने शायद पहले से ही आपके लिए एक नेटवर्क प्लगइन चुना हो।

आप जो नेटवर्क प्लगइन चुनते हैं और जिस तरह से आप इसे एकीकृत करते हैं, वह ट्रांज़िट में सूचना की सुरक्षा पर महत्वपूर्ण प्रभाव डाल सकता है।

अवलोकनीयता और रनटाइम सुरक्षा

Kubernetes आपको अतिरिक्त टूलिंग के साथ अपने क्लस्टर का विस्तार करने देता है। आप अपने एप्लिकेशन और उन्हें चलाने वाले क्लस्टर की निगरानी या समस्या निवारण में मदद के लिए थर्ड-पार्टी समाधान सेट अप कर सकते हैं। आपको Kubernetes में बनी हुई कुछ बुनियादी अवलोकनीयता सुविधाएँ भी मिलती हैं। कंटेनरों में चलने वाला आपका कोड लॉग उत्पन्न कर सकता है, मेट्रिक्स प्रकाशित कर सकता है, या अन्य अवलोकनीयता डेटा प्रदान कर सकता है; तैनाती के समय, आपको यह सुनिश्चित करना होगा कि आपका क्लस्टर वहाँ सुरक्षा का उचित स्तर प्रदान करे।

यदि आप कोई मेट्रिक्स डैशबोर्ड या इसी तरह की कोई चीज़ सेट करते हैं, तो उस डैशबोर्ड में डेटा भरने वाले घटकों की श्रृंखला के साथ-साथ डैशबोर्ड की भी समीक्षा करें। सुनिश्चित करें कि पूरी श्रृंखला पर्याप्त लचीलेपन और अखंडता सुरक्षा के साथ डिज़ाइन की गई है ताकि आप किसी घटना के दौरान भी इस पर भरोसा कर सकें जब आपका क्लस्टर डिग्रेड हो सकता है।

जहाँ उचित हो, Kubernetes परत के नीचे सुरक्षा उपाय तैनात करें, जैसे क्रिप्टोग्राफ़िक रूप से मापा गया बूट या समय का प्रमाणित वितरण (जो लॉग और ऑडिट रिकॉर्ड की निष्ठा सुनिश्चित करने में मदद करता है)।

उच्च-आश्वासन परिवेश के लिए, यह सुनिश्चित करने के लिए क्रिप्टोग्राफ़िक सुरक्षा तैनात करें कि लॉग छेड़छाड़-रोधी और गोपनीय दोनों हों।

आगे क्या है

क्लाउड नेटिव सुरक्षा

• क्लाउड नेटिव सुरक्षा पर CNCF श्वेत पत्र।
• सॉफ़्टवेयर सप्लाई चेन को सुरक्षित करने की अच्छी प्रथाओं पर CNCF श्वेत पत्र।
• Fixing the Kubernetes clusterf**k: Understanding security from the kernel up (FOSDEM 2020)
• Kubernetes Security Best Practices (Kubernetes Forum Seoul 2019)
• Towards Measured Boot Out of the Box (Linux Security Summit 2016)

Kubernetes और सूचना सुरक्षा

• Kubernetes सुरक्षा
• अपने क्लस्टर को सुरक्षित करना
• कंट्रोल प्लेन के लिए ट्रांज़िट में डेटा एन्क्रिप्शन
• रेस्ट में डेटा एन्क्रिप्शन
• Kubernetes में सीक्रेट्स
• Kubernetes API तक पहुँच नियंत्रित करना
• Pods के लिए Network policies
• Pod security standards
• RuntimeClasses

4 - नीतियाँ

Kubernetes नीतियाँ वे कॉन्फ़िगरेशन होती हैं जो अन्य कॉन्फ़िगरेशन या रनटाइम व्यवहारों को प्रबंधित करती हैं। Kubernetes विभिन्न प्रकार की नीतियाँ प्रदान करता है, जो नीचे दी गई हैं:

API ऑब्जेक्ट्स का उपयोग करके नीतियाँ लागू करें

कुछ API ऑब्जेक्ट्स नीतियों के रूप में कार्य करते हैं। यहाँ कुछ उदाहरण दिए गए हैं:

• NetworkPolicies का उपयोग किसी वर्कलोड के लिए इनग्रेस और एग्रेस ट्रैफिक को प्रतिबंधित करने के लिए किया जा सकता है।
• LimitRanges विभिन्न ऑब्जेक्ट प्रकारों के बीच संसाधन आवंटन सीमाओं का प्रबंधन करते हैं।
• ResourceQuotas किसी नेमस्पेस के लिए संसाधन खपत को सीमित करती हैं।

Admission Controllers का उपयोग करके नीतियाँ लागू करें

एक admission controller API सर्वर में चलता है और API अनुरोधों को सत्यापित या बदल सकता है। कुछ admission controllers नीतियों को लागू करने के लिए कार्य करते हैं। उदाहरण के लिए, AlwaysPullImages admission controller प्रत्येक नए Pod में इमेज पुल नीति को Always पर सेट करने के लिए सक्षम करता है।

Kubernetes के पास कई अंतर्निहित admission controllers हैं जिन्हें API सर्वर --enable-admission-plugins फ्लैग के माध्यम से कॉन्फ़िगर किया जा सकता है।

Admission controllers के बारे में विस्तृत जानकारी, उपलब्ध admission controllers की पूरी सूची के साथ, एक समर्पित अनुभाग में प्रलेखित है:

• Admission Controllers

ValidatingAdmissionPolicy का उपयोग करके नीतियाँ लागू करें

Validating admission policies, API सर्वर में कॉन्फ़िगर करने योग्य सत्यापन जांचों को लागू करने की अनुमति देती हैं, जो Common Expression Language (CEL) का उपयोग करती हैं। उदाहरण के लिए, एक ValidatingAdmissionPolicy का उपयोग latest इमेज टैग के उपयोग को अस्वीकृत करने के लिए किया जा सकता है।

एक ValidatingAdmissionPolicy एक API अनुरोध पर कार्य करता है और गैर-अनुपालन कॉन्फ़िगरेशनों के बारे में उपयोगकर्ताओं को ब्लॉक, ऑडिट, और चेतावनी देने के लिए उपयोग किया जा सकता है।

ValidatingAdmissionPolicy API के बारे में विवरण, उदाहरणों सहित, एक समर्पित अनुभाग में प्रलेखित है:

• Validating Admission Policy

Dynamic admission control का उपयोग करके नीतियाँ लागू करें

Dynamic admission controllers (या admission webhooks) API सर्वर के बाहर एक अलग एप्लिकेशन के रूप में चलते हैं जो API अनुरोधों के सत्यापन या संशोधन के लिए वेबहुक अनुरोधों को प्राप्त करने के लिए पंजीकृत होते हैं।

Dynamic admission controllers का उपयोग API अनुरोधों पर नीतियाँ लागू करने और अन्य नीति-आधारित वर्कफ़्लोज़ को ट्रिगर करने के लिए किया जा सकता है। एक dynamic admission controller ऐसी जटिल जांच कर सकता है, जिसमें अन्य क्लस्टर संसाधनों और बाहरी डेटा की पुनर्प्राप्ति की आवश्यकता होती है। उदाहरण के लिए, एक इमेज सत्यापन जांच OCI रजिस्ट्रियों से डेटा प्राप्त करके कंटेनर इमेज हस्ताक्षर और प्रमाणपत्रों को मान्य करने के लिए उपयोग की जा सकती है।

Dynamic admission control के बारे में विवरण एक समर्पित अनुभाग में प्रलेखित है:

• Dynamic Admission Control

Implementations

Dynamic admission controllers जो फ्लेक्सिबल नीति इंजन के रूप में कार्य करते हैं, उन्हें कुबेरनेट्स इकोसिस्टम में विकसित किया जा रहा है, जैसे की:

• Kubewarden
• Kyverno
• OPA Gatekeeper
• Polaris

Kubelet कॉन्फ़िगरेशनों का उपयोग करके नीतियाँ लागू करें

Kubernetes प्रत्येक वर्कर नोड पर Kubelet को कॉन्फ़िगर करने की अनुमति देता है। कुछ Kubelet कॉन्फ़िगरेशन नीतियों के रूप में कार्य करते हैं:

• Process ID limits and reservations का उपयोग आवंटन योग्य PIDs को सीमित और आरक्षित करने के लिए किया जाता है।
• Node Resource Managers उच्च-प्रदर्शन और विलंब-संवेदनशील वर्कलोड्स के लिए कंप्यूट, मेमोरी, और डिवाइस संसाधनों का प्रबंधन कर सकते हैं।