यह इस खंड का बहु-पृष्ठ प्रिंट योग्य दृश्य है। प्रिंट करने के लिए यहां क्लिक करें.

अवधारणाएँ

1: अवलोकन

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

3: नीतियाँ

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

4.1: टेंट्स और टॉलरेशन

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

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 - नीतियाँ

नीतियों के साथ सुरक्षा और सर्वोत्तम प्रथाओं को प्रबंधित करें।

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

टिप्पणी: यह खंड अन्य पक्ष परियोजनाओं से जुड़ा है जो कुबेरनेट्स द्वारा आवश्यक कार्यक्षमता प्रदान करते हैं। कुबेरनेट्स परियोजना के लेखक इन परियोजनाओं के लिए जिम्मेदार नहीं हैं। यह पृष्ठ CNCF वेबसाइट दिशानिर्देश का अनुसरण करते हुए परियोजनाओं को वर्णानुक्रम में सूचीबद्ध करता है। इस सूची में कोई नई परियोजना जोड़ने से पहले यह विषय मार्गदर्शक पृष्ट पढ़के ही परिवर्तन करें।

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

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

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

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

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

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

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

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

शेड्यूलिंग

पॉड व्यवधान

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

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

4.1 - टेंट्स और टॉलरेशन

नोड एफिनिटी पॉड्स की एक ऐसी विशेषता है जो उन्हें नोड्स के एक समूह की ओर आकर्षित करती है (प्राथमिकता के रूप में या कठोर आवश्यकता के रूप में)। टेंट्स इसके विपरीत हैं -- वे एक नोड को पॉड्स के एक समूह को अस्वीकार करने की अनुमति देते हैं।

टॉलरेशन पॉड्स पर लागू होती हैं। टॉलरेशन शेड्यूलर को मिलान करने वाले टेंट्स वाले पॉड्स को शेड्यूल करने की अनुमति देती हैं। टॉलरेशन शेड्यूलिंग की अनुमति देती हैं लेकिन शेड्यूलिंग की गारंटी नहीं देतीं: शेड्यूलर अपने कार्य के भाग के रूप में अन्य मापदंडों का भी मूल्यांकन करता है।

टेंट्स और टॉलरेशन मिलकर यह सुनिश्चित करते हैं कि पॉड्स अनुचित नोड्स पर शेड्यूल न हों। एक या अधिक टेंट्स एक नोड पर लागू किए जाते हैं; यह दर्शाता है कि नोड उन पॉड्स को स्वीकार नहीं करेगा जो टेंट्स को टॉलरेट नहीं करते।

अवधारणाएं

आप kubectl taint का उपयोग करके एक नोड पर टेंट जोड़ सकते हैं। उदाहरण के लिए,

kubectl taint nodes node1 key1=value1:NoSchedule

नोड node1 पर एक टेंट लगाता है। इस टेंट की key key1, value value1, और टेंट effect NoSchedule है। इसका अर्थ है कि कोई भी पॉड node1 पर शेड्यूल नहीं हो सकेगा जब तक उसके पास मिलान करने वाली टॉलरेशन न हो।

ऊपर दिए गए कमांड से जोड़े गए टेंट को हटाने के लिए, आप यह चला सकते हैं:

kubectl taint nodes node1 key1=value1:NoSchedule-

आप PodSpec में पॉड के लिए टॉलरेशन निर्दिष्ट करते हैं। निम्नलिखित दोनों टॉलरेशन ऊपर की kubectl taint लाइन से बने टेंट से "मिलान" करती हैं, और इसलिए इनमें से किसी भी टॉलरेशन वाला पॉड node1 पर शेड्यूल हो सकता है:

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"

tolerations:
- key: "key1"
  operator: "Exists"
  effect: "NoSchedule"

डिफ़ॉल्ट Kubernetes शेड्यूलर किसी विशेष पॉड को चलाने के लिए नोड चुनते समय टेंट्स और टॉलरेशन को ध्यान में रखता है। हालांकि, यदि आप किसी पॉड के लिए .spec.nodeName मैन्युअल रूप से निर्दिष्ट करते हैं, तो वह क्रिया शेड्यूलर को बाईपास कर देती है; पॉड तब उस नोड पर बाउंड हो जाता है जहाँ आपने उसे असाइन किया था, भले ही उस नोड पर NoSchedule टेंट्स हों। यदि ऐसा होता है और नोड पर NoExecute टेंट भी सेट है, तो kubelet पॉड को बाहर कर देगा जब तक उचित tolerance सेट न हो।

यहाँ एक पॉड का उदाहरण है जिसमें कुछ टॉलरेशन परिभाषित हैं:

    pods/pod-with-toleration.yaml
    
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: "example-key"
    operator: "Exists"
    effect: "NoSchedule"

operator का डिफ़ॉल्ट मान Equal है।

एक टॉलरेशन एक टेंट से "मिलान" करती है यदि keys समान हों और effects समान हों, और:

operator Exists है (इस स्थिति में कोई value निर्दिष्ट नहीं होनी चाहिए), या
operator Equal है और values समान होनी चाहिए।

टिप्पणी:

दो विशेष मामले हैं:

यदि key खाली है, तो operator Exists होना चाहिए, जो सभी keys और values से मिलान करता है। ध्यान दें कि effect को अभी भी एक साथ मिलान करना होगा।

एक खाली effect key key1 के साथ सभी effects से मिलान करता है।

ऊपर दिए गए उदाहरण में NoSchedule के effect का उपयोग किया गया था। वैकल्पिक रूप से, आप PreferNoSchedule के effect का उपयोग कर सकते हैं।

effect फ़ील्ड के लिए अनुमत मान हैं:

NoExecute

यह उन पॉड्स को प्रभावित करता है जो नोड पर पहले से चल रहे हैं, इस प्रकार:

जो पॉड्स टेंट को टॉलरेट नहीं करते उन्हें तुरंत बाहर कर दिया जाता है
जो पॉड्स टेंट को टॉलरेट करते हैं और अपनी टॉलरेशन विनिर्देश में tolerationSeconds निर्दिष्ट नहीं करते वे हमेशा के लिए बाउंड रहते हैं
जो पॉड्स टेंट को निर्दिष्ट tolerationSeconds के साथ टॉलरेट करते हैं, निर्दिष्ट समय तक बाउंड रहते हैं। उस समय के बाद, नोड lifecycle controller पॉड्स को नोड से बाहर कर देता है।

NoSchedule

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

PreferNoSchedule

PreferNoSchedule, NoSchedule का एक "प्राथमिकता" या "सॉफ्ट" संस्करण है। कंट्रोल प्लेन उस पॉड को टेंटेड नोड पर रखने से बचने की कोशिश करेगा जो टेंट को टॉलरेट नहीं करता, लेकिन यह गारंटीकृत नहीं है।

आप एक ही नोड पर कई टेंट्स और एक ही पॉड पर कई टॉलरेशन रख सकते हैं। Kubernetes कई टेंट्स और टॉलरेशन को एक फ़िल्टर की तरह प्रोसेस करता है: नोड के सभी टेंट्स से शुरू करें, फिर उन टेंट्स को अनदेखा करें जिनके लिए पॉड के पास मिलान करने वाली टॉलरेशन है; शेष अनदेखे न किए गए टेंट्स पॉड पर इंगित effects देते हैं। विशेष रूप से,

यदि NoSchedule effect वाला कम से कम एक अनदेखा न किया गया टेंट है तो Kubernetes पॉड को उस नोड पर शेड्यूल नहीं करेगा
यदि NoSchedule effect वाला कोई अनदेखा न किया गया टेंट नहीं है लेकिन कम से कम एक PreferNoSchedule effect वाला अनदेखा न किया गया टेंट है तो Kubernetes पॉड को उस नोड पर शेड्यूल न करने की कोशिश करेगा
यदि NoExecute effect वाला कम से कम एक अनदेखा न किया गया टेंट है तो पॉड को नोड से बाहर कर दिया जाएगा (यदि वह नोड पर पहले से चल रहा है), और नोड पर शेड्यूल नहीं होगा (यदि वह अभी नोड पर नहीं चल रहा)।

उदाहरण के लिए, मान लीजिए आप एक नोड को इस तरह टेंट करते हैं

kubectl taint nodes node1 key1=value1:NoSchedule
kubectl taint nodes node1 key1=value1:NoExecute
kubectl taint nodes node1 key2=value2:NoSchedule

और एक पॉड के पास दो टॉलरेशन हैं:

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"

इस मामले में, पॉड नोड पर शेड्यूल नहीं हो सकेगा, क्योंकि तीसरे टेंट से मिलान करने वाली कोई टॉलरेशन नहीं है। लेकिन यदि टेंट जोड़े जाने के समय पॉड पहले से नोड पर चल रहा है तो वह चलते रहने में सक्षम होगा, क्योंकि तीसरा टेंट तीनों में से अकेला ऐसा है जो पॉड द्वारा टॉलरेट नहीं किया जाता।

सामान्यतः, यदि NoExecute effect वाला टेंट एक नोड पर जोड़ा जाता है, तो जो पॉड्स टेंट को टॉलरेट नहीं करते उन्हें तुरंत बाहर कर दिया जाता है, और जो पॉड्स टेंट को टॉलरेट करते हैं उन्हें कभी बाहर नहीं किया जाता। हालांकि, NoExecute effect वाली टॉलरेशन एक वैकल्पिक tolerationSeconds फ़ील्ड निर्दिष्ट कर सकती है जो यह बताती है कि टेंट जोड़े जाने के बाद पॉड कितने समय तक नोड से बाउंड रहेगा। उदाहरण के लिए,

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"
  tolerationSeconds: 3600

इसका अर्थ है कि यदि यह पॉड चल रहा है और नोड पर एक मिलान करने वाला टेंट जोड़ा जाता है, तो पॉड 3600 सेकंड तक नोड से बाउंड रहेगा, और फिर बाहर हो जाएगा। यदि उस समय से पहले टेंट हटा दिया जाता है, तो पॉड बाहर नहीं होगा।

संख्यात्मक तुलना ऑपरेटर

फ़ीचर स्थिति: Kubernetes v1.35 [alpha](disabled by default)

Equal और Exists के अलावा, आप पूर्णांक मानों वाले टेंट्स से मिलान करने के लिए संख्यात्मक तुलना ऑपरेटर (Gt और Lt) का उपयोग कर सकते हैं। यह threshold-आधारित शेड्यूलिंग के लिए उपयोगी है, जैसे reliability level या SLA tier के अनुसार नोड्स का मिलान करना।

Gt तब मिलान करता है जब टेंट value टॉलरेशन value से अधिक हो।
Lt तब मिलान करता है जब टेंट value टॉलरेशन value से कम हो।

संख्यात्मक ऑपरेटरों के लिए, टॉलरेशन और टेंट दोनों values वैध पूर्णांक होने चाहिए। यदि कोई भी value पूर्णांक के रूप में parse नहीं हो सकती, तो टॉलरेशन मिलान नहीं करती।

टिप्पणी:

जब आप Gt या Lt टॉलरेशन ऑपरेटर का उपयोग करने वाला पॉड बनाते हैं, तो API server यह validate करता है कि टॉलरेशन values वैध पूर्णांक हैं। नोड्स पर टेंट values को नोड registration के समय validate नहीं किया जाता। यदि किसी नोड के पास non-numeric टेंट value है (उदाहरण के लिए, servicelevel.organization.example/agreed-service-level=high:NoSchedule), संख्यात्मक तुलना ऑपरेटर वाले पॉड्स उस टेंट से मिलान नहीं करेंगे और उस नोड पर शेड्यूल नहीं हो सकते।

उदाहरण के लिए, यदि नोड्स को service level agreement (SLA) दर्शाने वाली value के साथ टेंट किया जाता है:

kubectl taint nodes node1 servicelevel.organization.example/agreed-service-level=950:NoSchedule

एक पॉड 900 से अधिक SLA वाले नोड्स को टॉलरेट कर सकता है:

    pods/pod-with-numeric-toleration.yaml
    
apiVersion: v1
kind: Pod
metadata:
  name: nginx-numeric-toleration
  labels:
    env: test
spec:
  containers:
    - name: nginx
      image: nginx
      imagePullPolicy: IfNotPresent
  tolerations:
    - key: "servicelevel.organization.example/agreed-service-level"
      operator: "Gt"
      value: "900"
      effect: "NoSchedule"

यह टॉलरेशन node1 पर टेंट से मिलान करती है क्योंकि 950 > 900 (Gt ऑपरेटर के लिए टेंट value टॉलरेशन value से अधिक है)। इसी तरह, आप Lt ऑपरेटर का उपयोग उन टेंट्स से मिलान करने के लिए कर सकते हैं जहाँ टेंट value टॉलरेशन value से कम हो:

tolerations:
- key: "servicelevel.organization.example/agreed-service-level"
  operator: "Lt"
  value: "1000"
  effect: "NoSchedule"

टिप्पणी:

संख्यात्मक तुलना ऑपरेटर का उपयोग करते समय:

टॉलरेशन और टेंट दोनों values वैध signed 64-bit पूर्णांक होने चाहिए (zero leading numbers (जैसे, "0550") अनुमत नहीं हैं)।
यदि कोई value पूर्णांक के रूप में parse नहीं हो सकती, तो टॉलरेशन मिलान नहीं करती।
संख्यात्मक ऑपरेटर सभी टेंट effects के साथ काम करते हैं: NoSchedule, PreferNoSchedule, और NoExecute।
PreferNoSchedule के साथ संख्यात्मक ऑपरेटर के लिए: यदि पॉड की टॉलरेशन संख्यात्मक तुलना संतुष्ट नहीं करती (जैसे, Gt उपयोग करते समय टेंट value < टॉलरेशन value), तो शेड्यूलर नोड को कम प्राथमिकता देता है लेकिन यदि कोई बेहतर विकल्प नहीं है तो वहाँ शेड्यूल भी कर सकता है।

चेतावनी:

TaintTolerationComparisonOperators feature gate disable करने से पहले:

आपको controller hot-loops से बचने के लिए Gt या Lt ऑपरेटर का उपयोग करने वाले सभी workloads की पहचान करनी चाहिए।
सभी workload controller templates को Equal या Exists ऑपरेटर का उपयोग करने के लिए अपडेट करें
Gt या Lt ऑपरेटर का उपयोग करने वाले pending पॉड्स को delete करें
validation errors में spikes के लिए apiserver_request_total metric की निगरानी करें

उपयोग के उदाहरण

टेंट्स और टॉलरेशन पॉड्स को नोड्स से दूर करने या उन पॉड्स को बाहर करने का एक लचीला तरीका है जो नहीं चलने चाहिए। कुछ उपयोग के मामले हैं:

समर्पित नोड्स: यदि आप किसी विशेष उपयोगकर्ताओं के समूह के एकल उपयोग के लिए नोड्स का एक समूह समर्पित करना चाहते हैं, तो आप उन नोड्स पर एक टेंट जोड़ सकते हैं (जैसे, kubectl taint nodes nodename dedicated=groupName:NoSchedule) और फिर उनके पॉड्स में संबंधित टॉलरेशन जोड़ सकते हैं (यह सबसे आसानी से एक custom admission controller लिखकर किया जाता है)। टॉलरेशन वाले पॉड्स तब टेंटेड (समर्पित) नोड्स के साथ-साथ cluster के किसी भी अन्य नोड का उपयोग करने में सक्षम होंगे। यदि आप नोड्स को उनके लिए समर्पित करना चाहते हैं और यह सुनिश्चित करना चाहते हैं कि वे केवल समर्पित नोड्स का उपयोग करें, तो आपको नोड्स के उसी समूह पर टेंट के समान एक label भी जोड़ना चाहिए (जैसे dedicated=groupName), और admission controller को अतिरिक्त रूप से एक node affinity जोड़नी चाहिए जिसमें आवश्यकता हो कि पॉड्स केवल dedicated=groupName से labeled नोड्स पर शेड्यूल हो सकें।
विशेष हार्डवेयर वाले नोड्स: एक ऐसे cluster में जहाँ नोड्स के एक छोटे उपसमूह के पास विशेष हार्डवेयर है (उदाहरण के लिए GPUs), यह वांछनीय है कि विशेष हार्डवेयर की आवश्यकता न होने वाले पॉड्स को उन नोड्स से दूर रखा जाए, इस प्रकार बाद में आने वाले पॉड्स के लिए जगह बचाई जाए जिन्हें विशेष हार्डवेयर की आवश्यकता है। यह विशेष हार्डवेयर वाले नोड्स को टेंट करके (जैसे kubectl taint nodes nodename special=true:NoSchedule या kubectl taint nodes nodename special=true:PreferNoSchedule) और विशेष हार्डवेयर का उपयोग करने वाले पॉड्स में संबंधित टॉलरेशन जोड़कर किया जा सकता है।
टेंट आधारित निष्कासन: नोड समस्याएं होने पर per-pod-configurable निष्कासन व्यवहार, जो अगले अनुभाग में वर्णित है।

टेंट आधारित निष्कासन

फ़ीचर स्थिति: Kubernetes v1.18 [stable]

नोड controller कुछ conditions के सत्य होने पर स्वचालित रूप से एक नोड को टेंट करता है। निम्नलिखित टेंट्स built-in हैं:

node.kubernetes.io/not-ready: नोड ready नहीं है। यह NodeCondition Ready के "False" होने से संबंधित है।
node.kubernetes.io/unreachable: नोड, node controller से unreachable है। यह NodeCondition Ready के "Unknown" होने से संबंधित है।
node.kubernetes.io/memory-pressure: नोड पर memory pressure है।
node.kubernetes.io/disk-pressure: नोड पर disk pressure है।
node.kubernetes.io/pid-pressure: नोड पर PID pressure है।
node.kubernetes.io/network-unavailable: नोड का network unavailable है।
node.kubernetes.io/unschedulable: नोड unschedulable है।
node.cloudprovider.kubernetes.io/uninitialized: जब kubelet एक "external" cloud provider के साथ शुरू किया जाता है, तो यह टेंट नोड पर set किया जाता है उसे unusable mark करने के लिए। cloud-controller-manager के एक controller द्वारा इस नोड को initialize करने के बाद, kubelet इस टेंट को हटा देता है।

यदि किसी नोड को drain करना हो, तो node controller या kubelet NoExecute effect के साथ संबंधित टेंट्स जोड़ता है। यह effect node.kubernetes.io/not-ready और node.kubernetes.io/unreachable टेंट्स के लिए डिफ़ॉल्ट रूप से जोड़ा जाता है। यदि fault condition सामान्य हो जाती है, तो kubelet या node controller संबंधित टेंट(s) हटा सकता है।

कुछ मामलों में जब नोड unreachable होता है, API server नोड पर kubelet के साथ communicate नहीं कर सकता। पॉड्स को delete करने का निर्णय kubelet को तब तक communicate नहीं किया जा सकता जब तक API server के साथ communication पुनः स्थापित न हो जाए। इस बीच, deletion के लिए scheduled पॉड्स partitioned नोड पर चलते रह सकते हैं।

टिप्पणी:

कंट्रोल प्लेन नोड्स में नए टेंट्स जोड़ने की दर को सीमित करता है। यह rate limiting उन निष्कासनों की संख्या को manage करता है जो तब trigger होते हैं जब बहुत सारे नोड्स एक साथ unreachable हो जाते हैं (उदाहरण के लिए: यदि network disruption होती है)।

आप एक पॉड के लिए tolerationSeconds निर्दिष्ट कर सकते हैं यह परिभाषित करने के लिए कि failing या unresponsive नोड पर वह पॉड कितने समय तक bound रहेगा।

उदाहरण के लिए, आप network partition होने पर बहुत सारी local state वाले application को नोड से काफी समय तक bound रखना चाहते हो सकते हैं, उम्मीद रखते हुए कि partition recover हो जाएगा और इसलिए पॉड निष्कासन से बचा जा सकता है। इस पॉड के लिए आप जो टॉलरेशन set करते हैं वह कुछ इस तरह लग सकती है:

tolerations:
- key: "node.kubernetes.io/unreachable"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 6000

टिप्पणी:

Kubernetes स्वचालित रूप से node.kubernetes.io/not-ready और node.kubernetes.io/unreachable के लिए tolerationSeconds=300 के साथ टॉलरेशन जोड़ता है, जब तक आप, या कोई controller, उन टॉलरेशन को स्पष्ट रूप से सेट न करें।

ये स्वचालित रूप से जोड़ी गई टॉलरेशन का अर्थ है कि पॉड्स इन समस्याओं में से किसी एक के detect होने के बाद 5 मिनट तक नोड्स से bound रहते हैं।

DaemonSet पॉड्स निम्नलिखित टेंट्स के लिए बिना tolerationSeconds के NoExecute टॉलरेशन के साथ बनाए जाते हैं:

node.kubernetes.io/unreachable
node.kubernetes.io/not-ready

यह सुनिश्चित करता है कि DaemonSet पॉड्स इन समस्याओं के कारण कभी बाहर नहीं होते।

टिप्पणी:

नोड controller नोड्स में टेंट्स जोड़ने और पॉड्स को बाहर करने के लिए जिम्मेदार था। लेकिन 1.29 के बाद, taint-based eviction implementation को node controller से बाहर एक अलग, और स्वतंत्र component में स्थानांतरित कर दिया गया है जिसे taint-eviction-controller कहा जाता है। उपयोगकर्ता वैकल्पिक रूप से taint-based eviction को kube-controller-manager में --controllers=-taint-eviction-controller सेट करके disable कर सकते हैं।

स्थिति के अनुसार नोड्स को टेंट करना

कंट्रोल प्लेन, नोड controller का उपयोग करके, स्वचालित रूप से नोड conditions के लिए NoSchedule effect के साथ टेंट्स बनाता है।

शेड्यूलर scheduling decisions करते समय नोड conditions नहीं, टेंट्स check करता है। यह सुनिश्चित करता है कि नोड conditions सीधे scheduling को प्रभावित नहीं करतीं। उदाहरण के लिए, यदि DiskPressure नोड condition सक्रिय है, तो कंट्रोल प्लेन node.kubernetes.io/disk-pressure टेंट जोड़ता है और affected नोड पर नए पॉड्स शेड्यूल नहीं करता। यदि MemoryPressure नोड condition सक्रिय है, तो कंट्रोल प्लेन node.kubernetes.io/memory-pressure टेंट जोड़ता है।

आप नए बने पॉड्स के लिए संबंधित पॉड टॉलरेशन जोड़कर नोड conditions को अनदेखा कर सकते हैं। कंट्रोल प्लेन उन पॉड्स पर भी node.kubernetes.io/memory-pressure टॉलरेशन जोड़ता है जिनकी QoS class BestEffort के अलावा कोई और है। यह इसलिए है क्योंकि Kubernetes Guaranteed या Burstable QoS classes में पॉड्स को (चाहे उनके पास कोई memory request set न हो) ऐसे treat करता है जैसे वे memory pressure cope करने में सक्षम हैं, जबकि नए BestEffort पॉड्स affected नोड पर शेड्यूल नहीं होते।

DaemonSet controller स्वचालित रूप से निम्नलिखित NoSchedule टॉलरेशन सभी daemons में जोड़ता है, DaemonSets को break होने से रोकने के लिए।

node.kubernetes.io/memory-pressure
node.kubernetes.io/disk-pressure
node.kubernetes.io/pid-pressure (1.14 या बाद का)
node.kubernetes.io/unschedulable (1.10 या बाद का)
node.kubernetes.io/network-unavailable (केवल host network)

ये टॉलरेशन जोड़ना backward compatibility सुनिश्चित करता है। आप DaemonSets में arbitrary टॉलरेशन भी जोड़ सकते हैं।

डिवाइस टेंट्स और टॉलरेशन

पूरे नोड्स को टेंट करने की जगह, administrators individual devices को भी टेंट कर सकते हैं जब cluster विशेष हार्डवेयर manage करने के लिए dynamic resource allocation का उपयोग करता है। इसका फायदा यह है कि tainting को ठीक उस हार्डवेयर की ओर लक्षित किया जा सकता है जो faulty है या maintenance की आवश्यकता है। टॉलरेशन भी supported हैं और devices request करते समय निर्दिष्ट की जा सकती हैं। टेंट्स की तरह ये उन सभी पॉड्स पर लागू होती हैं जो समान allocated device share करते हैं।

आगे क्या है

नोड-pressure Eviction के बारे में पढ़ें और आप इसे कैसे configure कर सकते हैं
पॉड Priority के बारे में पढ़ें
device टेंट्स और टॉलरेशन के बारे में पढ़ें