अवधारणाएँ

• 1: अवलोकन
• 2: सर्विसेज, लोड बैलेंसिंग और नेटवर्किंग
• 3: सुरक्षा (Security)
• 3.1: पॉड सुरक्षा नीतियां (Pod Security Policies)
• 3.2: लिनक्स नोड्स के लिए सुरक्षा
• 3.3: विंडोज़ नोड्स के लिए सुरक्षा
• 4: नीतियाँ
• 5: शेड्यूलिंग, प्रीइम्प्शन और इविक्शन

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 सर्विस प्रॉक्सींग का एक डिफ़ॉल्ट कार्यान्वयन प्रदान करता है, जिसे क्यूब-प्रॉक्सी कहा जाता है, लेकिन कुछ पॉड नेटवर्क कार्यान्वयन इसके बजाय अपने स्वयं के सर्विस प्रॉक्सी का उपयोग करते हैं जो शेष कार्यान्वयन के साथ अधिक दृढ़ता से एकीकृत होता है।

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

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

आगे क्या है

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

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

3 - सुरक्षा (Security)

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

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

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

कुबेरनेट्स सुरक्षा तंत्र (Kubernetes security mechanisms)

कुबेरनेट्स में कई API और सुरक्षा नियंत्रण (security controls) शामिल हैं, साथ ही नीतियां (policies) परिभाषित करने के तरीके भी हैं जो यह तय कर सकते हैं कि आप सूचना सुरक्षा का प्रबंधन कैसे करते हैं।

कंट्रोल प्लेन सुरक्षा (Control plane protection)

किसी भी कुबेरनेट्स क्लस्टर के लिए एक प्रमुख सुरक्षा तंत्र कुबेरनेट्स API तक पहुंच को नियंत्रित करना है।

कुबेरनेट्स आपसे अपेक्षा करता है कि आप कंट्रोल प्लेन के भीतर, और कंट्रोल प्लेन और इसके क्लाइंट्स के बीच डेटा एन्क्रिप्शन इन ट्रांज़िट (data encryption in transit) प्रदान करने के लिए TLS को कॉन्फ़िगर और उपयोग करें। आप कुबेरनेट्स कंट्रोल प्लेन के भीतर संग्रहीत डेटा के लिए एन्क्रिप्शन एट रेस्ट (encryption at rest) भी सक्षम कर सकते हैं; यह आपके स्वयं के वर्कलोड के डेटा के लिए एन्क्रिप्शन एट रेस्ट का उपयोग करने से अलग है, जो एक अच्छा विचार भी हो सकता है।

सीक्रेट्स (Secrets)

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

वर्कलोड सुरक्षा (Workload protection)

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

नेटवर्क नीतियां (Network policies) आपको Pods के बीच, या Pods और आपके क्लस्टर के बाहर के नेटवर्क के बीच नेटवर्क ट्रैफ़िक को नियंत्रित करने देती हैं।

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

एडमिशन कंट्रोल (Admission control)

एडमिशन कंट्रोलर (Admission controllers) प्लगइन्स (plugins) हैं जो कुबेरनेट्स API अनुरोधों को इंटरसेप्ट करते हैं और अनुरोध में विशिष्ट फ़ील्ड के आधार पर अनुरोधों को मान्य (validate) या परिवर्तित (mutate) कर सकते हैं। इन नियंत्रकों को सोच-समझकर डिज़ाइन करने से अनपेक्षित व्यवधानों से बचने में मदद मिलती है क्योंकि संस्करण अपडेट (version updates) में कुबेरनेट्स API बदलते हैं। डिज़ाइन संबंधी विचारों (design considerations) के लिए, एडमिशन वेबहुक गुड प्रैक्टिसेज (Admission Webhook Good Practices) देखें।

ऑडिटिंग (Auditing)

कुबेरनेट्स ऑडिट लॉगिंग क्लस्टर में क्रियाओं के अनुक्रम (sequence of actions) का दस्तावेजीकरण करने वाले सुरक्षा-प्रासंगिक (security-relevant), कालानुक्रमिक रिकॉर्ड प्रदान करता है। क्लस्टर उपयोगकर्ताओं द्वारा, कुबेरनेट्स API का उपयोग करने वाले एप्लिकेशन द्वारा, और स्वयं कंट्रोल प्लेन द्वारा उत्पन्न गतिविधियों का ऑडिट करता है।

क्लाउड प्रदाता सुरक्षा (Cloud provider security)

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

नीतियां (Policies)

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

हालाँकि, आप कुबेरनेट्स के आसपास के व्यापक इकोसिस्टम से नीति कार्यान्वयन पर भी भरोसा कर सकते हैं। कुबेरनेट्स उन इकोसिस्टम परियोजनाओं को स्रोत कोड समीक्षा (source code review), कंटेनर इमेज अनुमोदन (container image approval), API पहुंच नियंत्रण, नेटवर्किंग और बहुत कुछ पर अपने स्वयं के नीति नियंत्रण (policy controls) लागू करने देने के लिए विस्तार तंत्र (extension mechanisms) प्रदान करता है।

नीति तंत्र (policy mechanisms) और कुबेरनेट्स के बारे में अधिक जानकारी के लिए, नीतियां (Policies) पढ़ें।

आगे क्या है

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

• अपने क्लस्टर को सुरक्षित करना
• कुबेरनेट्स में ज्ञात कमजोरियां (Known vulnerabilities) (और अधिक जानकारी के लिंक)
• कंट्रोल प्लेन के लिए डेटा एन्क्रिप्शन इन ट्रांज़िट
• डेटा एन्क्रिप्शन एट रेस्ट
• कुबेरनेट्स API तक पहुंच को नियंत्रित करना
• Pods के लिए नेटवर्क नीतियां
• कुबेरनेट्स में सीक्रेट्स
• पॉड सुरक्षा मानक
• RuntimeClasses

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

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

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

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

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

3.1 - पॉड सुरक्षा नीतियां (Pod Security Policies)

PodSecurityPolicy का उपयोग करने के बजाय, आप इनमें से किसी एक या दोनों का उपयोग करके Pods पर समान प्रतिबंध लागू कर सकते हैं:

• पॉड सुरक्षा स्वीकृति (Pod Security Admission)
• एक तृतीय-पक्ष (3rd party) एडमिशन प्लगइन, जिसे आप स्वयं तैनात (deploy) और कॉन्फ़िगर करते हैं

माइग्रेशन गाइड के लिए, PodSecurityPolicy से Built-In PodSecurity एडमिशन कंट्रोलर पर माइग्रेट करें देखें। इस API को हटाए जाने के बारे में अधिक जानकारी के लिए, PodSecurityPolicy का हटाया जाना: अतीत, वर्तमान और भविष्य (Past, Present, and Future) देखें।

यदि आप Kubernetes v1.36 नहीं चला रहे हैं, तो अपने Kubernetes संस्करण के लिए दस्तावेज़ देखें।

3.2 - लिनक्स नोड्स के लिए सुरक्षा

यह पृष्ठ लिनक्स ऑपरेटिंग सिस्टम के लिए विशिष्ट सुरक्षा संबंधी विचारों और सर्वोत्तम प्रथाओं का वर्णन करता है।

नोड्स पर सीक्रेट (Secret) डेटा के लिए सुरक्षा

लिनक्स नोड्स पर, मेमोरी-समर्थित वॉल्यूम (जैसे कि secret वॉल्यूम माउंट्स, या emptyDir के साथ medium: Memory) tmpfs फाइल सिस्टम के साथ कार्यान्वित (implemented) किए जाते हैं।

यदि आपने स्वैप (swap) कॉन्फ़िगर किया है और एक पुराने लिनक्स कर्नेल का उपयोग करते हैं (या वर्तमान कर्नेल और कुबेरनेट्स का असमर्थित कॉन्फ़िगरेशन), तो मेमोरी (memory) समर्थित वॉल्यूम का डेटा परसिस्टेंट स्टोरेज (persistent storage) में लिखा जा सकता है।

लिनक्स कर्नेल आधिकारिक तौर पर संस्करण 6.3 से noswap विकल्प का समर्थन करता है, इसलिए यह अनुशंसा की जाती है कि यदि नोड पर स्वैप सक्षम (enabled) है, तो उपयोग किया जाने वाला कर्नेल संस्करण 6.3 या बाद का हो, या बैकपोर्ट (backport) के माध्यम से noswap विकल्प का समर्थन करता हो।

अधिक जानकारी के लिए स्वैप मेमोरी प्रबंधन (swap memory management) पढ़ें।

3.3 - विंडोज़ नोड्स के लिए सुरक्षा

यह पृष्ठ विंडोज़ ऑपरेटिंग सिस्टम के लिए विशिष्ट सुरक्षा संबंधी विचारों और सर्वोत्तम प्रथाओं का वर्णन करता है।

नोड्स पर सीक्रेट (Secret) डेटा के लिए सुरक्षा

विंडोज़ पर, सीक्रेट्स (Secrets) का डेटा नोड के स्थानीय स्टोरेज (local storage) पर स्पष्ट पाठ (clear text) में लिखा जाता है (लिनक्स पर tmpfs / इन-मेमोरी फ़ाइल सिस्टम के उपयोग की तुलना में)। एक क्लस्टर ऑपरेटर के रूप में, आपको निम्नलिखित दोनों अतिरिक्त उपाय करने चाहिए:

1. सीक्रेट्स की फ़ाइल स्थान (file location) को सुरक्षित करने के लिए फ़ाइल ACL का उपयोग करें।
2. BitLocker का उपयोग करके वॉल्यूम-स्तर एन्क्रिप्शन लागू करें।

कंटेनर उपयोगकर्ता (Container users)

विंडोज़ पॉड्स या कंटेनरों के लिए RunAsUsername निर्दिष्ट किया जा सकता है ताकि कंटेनर प्रक्रियाओं (processes) को विशिष्ट उपयोगकर्ता (user) के रूप में निष्पादित (execute) किया जा सके। यह लगभग RunAsUser के समतुल्य है।

विंडोज़ कंटेनर दो डिफ़ॉल्ट उपयोगकर्ता खाते प्रदान करते हैं, ContainerUser और ContainerAdministrator। इन दो उपयोगकर्ता खातों के बीच के अंतर को माइक्रोसॉफ्ट के Secure Windows containers दस्तावेज़ के भीतर When to use ContainerAdmin and ContainerUser user accounts में कवर किया गया है।

कंटेनर निर्माण (build) प्रक्रिया के दौरान स्थानीय उपयोगकर्ताओं (Local users) को कंटेनर छवियों (images) में जोड़ा जा सकता है।

विंडोज़ कंटेनर Group Managed Service Accounts का उपयोग करके सक्रिय निर्देशिका पहचानों (Active Directory identities) के रूप में भी चल सकते हैं।

पॉड-स्तरीय सुरक्षा अलगाव (Pod-level security isolation)

लिनक्स-विशिष्ट पॉड सुरक्षा संदर्भ तंत्र (security context mechanisms) (जैसे SELinux, AppArmor, Seccomp, या कस्टम POSIX क्षमताएं) विंडोज़ नोड्स पर समर्थित नहीं हैं।

विशेषाधिकार प्राप्त कंटेनर (Privileged containers) विंडोज़ पर समर्थित नहीं हैं। इसके बजाय लिनक्स पर विशेषाधिकार प्राप्त कंटेनरों द्वारा किए जाने वाले कई कार्यों को करने के लिए विंडोज़ पर HostProcess containers का उपयोग किया जा सकता है।

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 उच्च-प्रदर्शन और विलंब-संवेदनशील वर्कलोड्स के लिए कंप्यूट, मेमोरी, और डिवाइस संसाधनों का प्रबंधन कर सकते हैं।

5 - शेड्यूलिंग, प्रीइम्प्शन और इविक्शन

कुबेरनेट्स में शेड्यूलिंग का मतलब है कि, किस पॉड को किस नोड पे चलाना है ये निर्धारित किया जा सके ताकि क्यूबलेट उन्हें उस नोड पर चला सके।

प्रीइम्प्शन का मतलब है कि वो पॉड्स जिनकी प्रायोरिटी कम है उन्हें किसी नोड से हटा के वो पॉड्स चला सकें जिनकी प्रायोरिटी ज्यादा है।

इविक्शन का मतलब है कि एक या एक से अधिक पॉड्स को समाप्त किया जा सके।

शेड्यूलिंग

• कुबेरनेट्स शेड्यूलर
• नोड्स को पॉड्स आवंटित करना
• पॉड ओवरहेड
• पॉड टोपोलॉजी स्प्रेड प्रतिबंध
• टेन्ट्स एंड टॉलरेशंस
• शेड्यूलिंग रूपरेखा
• गतिशील संसाधन आवंटन
• शेड्यूलर परफॉरमेंस ट्यूनिंग
• विस्तारित संसाधनों के लिए संसाधन बिन पैकिंग
• पॉड शेड्यूलिंग तत्परता
• पॉड-समूह शेड्यूलिंग
• गैंग शेड्यूलिंग
• टोपोलॉजी-सचेत शेड्यूलिंग
• वर्कलोड-सचेत प्रिएम्प्शन
• डीशेड्यूलर
• नोड घोषित विशेषताएं

पॉड व्यवधान

पॉड विघटन वह प्रक्रिया है जिसके द्वारा नोड्स पर पॉड्स को स्वेच्छा से या अनैच्छिक रूप से समाप्त कर दिया जाता है।

स्वैच्छिक विघटन एप्लीकेशन मालिक या फिर क्लस्टर प्रशासक अभिप्रायपूर्वक चालू करते है। अनैच्छिक विघटन अनजाने में होते है और वो अपरिहार्य वजह से उत्पन्न हो सकते हैं जैसे कि नोड्स के पास संसाधन ख़तम हो जाना या आकस्मिक विलोपन।

• पॉड प्रायोरिटी और प्रीइम्प्शन
• नोड-प्रेशर इविक्शन
• एपीआई के द्वारा शुरू की गई इविक्शन