This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

प्रलेखन

1 - कुबेरनेट्स प्रलेखन

कुबेरनेट्स कंटेनरीकृत एप्लीकेशन के परिनियोजन, स्केलिंग और प्रबंधन को स्वचालित करने के लिए एक ओपन सोर्स कंटेनर ऑर्केस्ट्रेशन इंजन है| यह ओपन सोर्स प्रोजेक्ट Cloud Native Computing Foundation द्वारा होस्ट किया गया है।

1.1 - प्रलेखन के उपलब्ध संस्करण

इस वेबसाइट में कुबेरनेट्स के वर्तमान और चार पिछले संस्करण के प्रलेखन शामिल हैं।

2 - शुरू करना

यह भाग कुबेरनेट्स को सेटअप करने और चलाने के विभिन्न तरीकों को सूचीबद्ध करता है। जब आप कुबेरनेट्स सेटअप करते हैं, तो इसके आधार पर एक इंस्टॉलेशन प्रकार चुनें: रखरखाव में आसानी, सुरक्षा, नियंत्रण, उपलब्ध संसाधन और क्लस्टर के संचालन और प्रबंधन के लिए आवश्यक विशेषज्ञता।

कुबेरनेट्स क्लस्टर को स्थानीय मशीन पर, क्लाउड में, या अपने स्वयं के डेटासेंटर में डिप्लॉय करने के लिए आप कुबेरनेट्स डाउनलोड कर सकते हैं।

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

सीखने का वातावरण

यदि आप कुबेरनेट्स सीख रहे हैं, तो कुबेरनेट्स समुदाय द्वारा समर्थित टूल का उपयोग करें,या स्थानीय मशीन पर कुबेरनेट्स क्लस्टर सेटअप करने के लिए इकोसिस्टम में उपलब्ध टूल का उपयोग करें।इंस्टॉल टूल्स देखें।

प्रोडक्शन वातावरण

प्रोडक्शन वातावरण के लिए समाधान का मूल्यांकन करते समय, विचार करें कि कुबेरनेट्स क्लस्टर के किन पहलुओं (या abstractions) का संचालन आप स्वयं प्रबंधित करना चाहते हैं और किसे आप एक प्रदाता को सौंपना पसंद करते हैं।

स्वयं प्रबंधित कर रहे कुबेरनेट्स क्लस्टर डिप्लॉय करने के लिए kubeadm आधिकारिक टूल है।

आगे क्या है

कुबेरनेट्स के कण्ट्रोल प्लेन को Linux पर चलाने के लिए डिज़ाइन किया गया है। अपने क्लस्टर के अंदर आप Linux या अन्य ऑपरेटिंग सिस्टम पर एप्लिकेशन चला सकते हैं, जिसमें windows भी शामिल हैं।

2.1 - सीखने का माहौल

2.2 - उत्पादन वातावरण

एक उत्पादन-गुणवत्ता वाला कुबेरनेट्स क्लस्टर बनाएं

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

उत्पादन विचार

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

जैसा कि आप तय करते हैं कि आप अपने उत्पादन कुबेरनेट्स वातावरण को कहाँ रखना चाहते हैं (परिसर या क्लाउड में) और प्रबंधन की मात्रा जिसे आप दूसरों को देना या सौंपना चाहते हैं, विचार करें कि कुबेरनेट्स क्लस्टर के लिए आपकी आवश्यकताएं निम्नलिखित मुद्दों से कैसे प्रभावित होती हैं:

  • उपलब्धता: सिंगल-मशीन कुबेरनेट्स सीखने का माहौल में विफलता का एक बिंदु है। अत्यधिक उपलब्ध क्लस्टर बनाने का अर्थ है:

    • कण्ट्रोल प्लेन को वर्कर नोड्स से अलग करना।
    • कई नोड्स पर कण्ट्रोल प्लेन घटकों की प्रतिकृति।
    • क्लस्टर के लिए संतुलन यातायात लोड करेंAPI server.
    • पर्याप्त वर्कर नोड्स उपलब्ध होना, या जल्दी से उपलब्ध होने में सक्षम होना, क्योंकि बदलते वर्कलोड इसे वारंट करते हैं।

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

  • सुरक्षा और एक्सेस मैनेजमेंट: आपके अपने कुबेरनेट्स लर्निंग क्लस्टर पर पूर्ण व्यवस्थापकीय विशेषाधिकार हैं। लेकिन महत्वपूर्ण कार्यभार के साथ साझा क्लस्टर, और एक या दो से अधिक उपयोगकर्ता, को क्लस्टर संसाधनों तक कौन और क्या एक्सेस कर सकता है, इसके लिए अधिक परिष्कृत दृष्टिकोण की आवश्यकता होती है। आप यह सुनिश्चित करने के लिए (भूमिका-आधारित एक्सेस कण्ट्रोल) और अन्य सुरक्षा तंत्रों का उपयोग कर सकते हैं कि उपयोगकर्ता और कार्यभार उन संसाधनों तक पहुँच प्राप्त कर सकते हैं जिनकी उन्हें आवश्यकता है, साथ ही में कार्यभार और क्लस्टर को साथ में सुरक्षित रख सके।आप नीतियों और कंटेनर संसाधन को प्रबंधित करके उन संसाधनों की सीमा निर्धारित कर सकते हैं जिन तक उपयोगकर्ता और कार्यभार पहुंच सकते हैं।

कुबेरनेट्स उत्पादन वातावरण को स्वयं बनाने से पहले, इस कार्य में से कुछ या सभी को सौंपने पर विचार करेंटर्नकी क्लाउड सॉल्यूशंस प्रदाता या अन्य कुबेरनेट्स पार्टनर्स विकल्पों में शामिल हैं:

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

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

उत्पादन क्लस्टर सेटअप

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

उत्पादन कण्ट्रोल प्लेन

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

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

  • डिप्लॉयमेंट टूल्स चुनें: आप kubeadm, kops, और kubespray जैसे टूल का उपयोग करके एक कण्ट्रोल प्लेन को तैनात कर सकते हैं। उनमें से प्रत्येक डिप्लॉयमेंट विधियों का उपयोग करके उत्पादन-गुणवत्ता डिप्लॉयमेंट के लिए युक्तियों को जानने के लिए डिप्लॉयमेंट टूल्स के साथ कुबेरनेट्स स्थापित करना देखें। आपके डिप्लॉयमेंट के साथ उपयोग करने के लिए विभिन्न कंटेनर रनटाइम उपलब्ध हैं।
  • सर्टिफ़िकेट प्रबंधित करे: कण्ट्रोल प्लेन सेवाओं के बीच सुरक्षित संचार सर्टिफ़िकेटस का उपयोग करके कार्यान्वित किया जाता है। डिप्लॉयमेंट के दौरान सर्टिफ़िकेट स्वचालित रूप से उत्पन्न होते हैं या आप अपने स्वयं के सर्टिफ़िकेट अथॉरिटी का उपयोग करके उन्हें उत्पन्न कर सकते हैं।विवरण के लिए PKI सर्टिफ़िकेटस और आवश्यकताएं देखें।
  • एपिसर्वर के लिए लोड बैलेंसर कॉन्फ़िगर करें: विभिन्न नोड्स पर चल रहे एपिसर्वर सर्विस इंस्टेंस के लिए बाहरी एपीआई अनुरोधों को वितरित करने के लिए लोड बैलेंसर को कॉन्फ़िगर करें। विवरण के लिए एक बाहरी लोड बैलेंसर बनाना देखें।
  • अलग और बैकअप etcd सेवा: अतिरिक्त सुरक्षा और उपलब्धता के लिए etcd सेवाएं या तो अन्य कंट्रोल प्लेन सेवाओं के समान मशीनों पर चल सकती हैं या अलग मशीनों पर चल सकती हैं। क्योंकि etcd क्लस्टर कॉन्फ़िगरेशन डेटा संग्रहीत करता है, etcd डेटाबेस का बैकअप नियमित रूप से किया जाना चाहिए ताकि यह सुनिश्चित हो सके कि यदि आवश्यक हो तो आप उस डेटाबेस की मरम्मत कर सकते हैं।etcd को कॉन्फ़िगर करने और उपयोग करने के विवरण के लिए etcd अक्सर पूछे जाने वाले प्रश्न देखें।विवरण के लिए कुबेरनेट्स के लिए ऑपरेटिंग etcd क्लस्टर और क्यूबएडीएम के साथ एक उच्च उपलब्धता etcd क्लस्टर स्थापित करें देखें।
  • मल्टीपल कण्ट्रोल प्लेन सिस्टम बनाएं: उच्च उपलब्धता के लिए, कण्ट्रोल प्लेन एक मशीन तक सीमित नहीं होना चाहिए। यदि कण्ट्रोल प्लेन सेवाएं एक init सेवा (जैसे systemd) द्वारा चलाई जाती हैं, तो प्रत्येक सेवा को कम से कम तीन मशीनों पर चलना चाहिए। हालाँकि, कुबेरनेट्स में पॉड्स के रूप में कण्ट्रोल प्लेन सेवाएं चलाना सुनिश्चित करता है कि आपके द्वारा अनुरोधित सेवाओं की प्रतिकृति संख्या हमेशा उपलब्ध रहेगी।अनुसूचक फॉल्ट सहने वाला होना चाहिए, लेकिन अत्यधिक उपलब्ध नहीं होना चाहिए। कुबेरनेट्स सेवाओं के नेता चुनाव करने के लिए कुछ डिप्लॉयमेंट उपकरण राफ्ट सर्वसम्मति एल्गोरिथ्म की स्थापना करते हैं। यदि प्राथमिक चला जाता है, तो दूसरी सेवा स्वयं को चुनती है और कार्यभार संभालती है।
  • कई क्षेत्रों में विस्तार करना: यदि अपने क्लस्टर को हर समय उपलब्ध रखना महत्वपूर्ण है, तो एक ऐसा क्लस्टर बनाने पर विचार करें, जो कई डेटा केंद्रों पर चलता हो, जिसे क्लाउड वातावरण में ज़ोन के रूप में संदर्भित किया जाता है। ज़ोन(zone) के समूहों को रीजन(region) कहा जाता है। एक ही क्षेत्र में कई क्षेत्रों में एक क्लस्टर फैलाकर, यह इस संभावना में सुधार कर सकता है कि एक क्षेत्र अनुपलब्ध होने पर भी आपका क्लस्टर कार्य करना जारी रखेगा।विवरण के लिए एक से अधिक ज़ोन मे चलाना देखें।
  • चल रही सुविधाओं का प्रबंधन: यदि आप अपने क्लस्टर को समय के साथ रखने की योजना बनाते हैं, तो इसके स्वास्थ्य और सुरक्षा को बनाए रखने के लिए आपको कुछ कार्य करने होंगे। उदाहरण के लिए, यदि आपने क्यूबएडीएम के साथ स्थापित किया है, तो आपको सर्टिफिकेट प्रबंधन और क्यूबएडीएम क्लस्टर्स को अपग्रेड करने में मदद करने के लिए निर्देश दिए गए हैं, कुबेरनेट्स प्रशासनिक कार्यों की लंबी सूची के लिए क्लस्टर का एडमिनिस्टर देखें।

जब आप कण्ट्रोल प्लेन सेवाएं चलाते हैं, तो उपलब्ध विकल्पों के बारे में जानने के लिए, kube-apiserver, क्यूब-कंट्रोलर-मैनेजर, देखें।और क्यूब-शेड्यूलर कॉम्पोनेन्ट पेज। अत्यधिक उपलब्ध कंट्रोल प्लेन उदाहरणों के लिए अत्यधिक उपलब्ध टोपोलॉजी के लिए विकल्प,kubeadm के साथ अत्यधिक उपलब्ध क्लस्टर बनाना, और कुबेरनेट्स के लिए ऑपरेटिंग etcd क्लस्टर। etcd बैकअप योजना बनाने के बारे में जानकारी के लिए etcd क्लस्टर का बैकअप लेना देखें।

उत्पादन वर्कर नोड्स

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

  • नोड्स कॉन्फ़िगर करें: नोड्स भौतिक या आभासी मशीन हो सकते हैं। यदि आप अपने स्वयं के नोड्स बनाना और प्रबंधित करना चाहते हैं, तो आप एक समर्थित ऑपरेटिंग सिस्टम स्थापित कर सकते हैं, फिर उपयुक्त जोड़ और चला सकते हैंनोड सेवाएं। विचार करना:
    • जब आप उपयुक्त मेमोरी, सीपीयू, और डिस्क स्पीड और स्टोरेज क्षमता उपलब्ध कराकर नोड्स सेट करते हैं तो आपके वर्कलोड की मांग।
    • क्या जेनेरिक कंप्यूटर सिस्टम करेंगे या आपके पास ऐसे वर्कलोड हैं जिन्हें GPU प्रोसेसर, Windows नोड्स या VM आइसोलेशन की आवश्यकता है।
  • वैलिदेट(Validate) नोड: यह सुनिश्चित करने के तरीके के बारे में जानकारी के लिए वैलिद(Valid) नोड सेटअप देखें कि एक नोड कुबेरनेट्स क्लस्टर में शामिल होने के लिए आवश्यकताओं को पूरा करता है।
  • क्लस्टर में नोड जोड़ें: यदि आप अपने स्वयं के क्लस्टर का प्रबंधन कर रहे हैं, तो आप अपनी स्वयं की मशीनें स्थापित करके और या तो उन्हें मैन्युअल रूप से जोड़कर या क्लस्टर के एपिसर्वर में खुद को पंजीकृत करवाकर नोड्स जोड़ सकते हैं। इन तरीकों से नोड्स जोड़ने के लिए कुबेरनेट्स को कैसे सेट करें, इस बारे में जानकारी के लिए नोड्स अनुभाग देखें।
  • क्लस्टर में Windows नोड्स जोड़ें: कुबेरनेट्स Windows वर्कर नोड्स के लिए समर्थन प्रदान करता है, जिससे आप Windows कंटेनरों में लागू वर्कलोड को चला सकते हैं। विवरण के लिए कुबेरनेट्स में Windows देखें।
  • स्केल नोड्स: आपके क्लस्टर को अंततः जिस क्षमता की आवश्यकता होगी, उसके विस्तार के लिए एक योजना बनाएं। आपको चलाने के लिए आवश्यक पॉड्स और कंटेनरों की संख्या के आधार पर, यह निर्धारित करने में सहायता के लिए बड़े समूहों के लिए विचार देखें कि आपको कितने नोड्स की आवश्यकता है। यदि आप स्वयं नोड्स का प्रबंधन कर रहे हैं, तो इसका अर्थ यह हो सकता है कि आप अपने स्वयं के भौतिक उपकरण खरीदना और स्थापित करना चाहते हैं।
  • ऑटोस्केल नोड्स: अधिकांश क्लाउड प्रदाता अस्वस्थ नोड्स को बदलने के लिए क्लस्टर ऑटोस्केलर का समर्थन करते हैं या मांग के अनुसार नोड्स की संख्या को बढ़ाते और घटाते हैं। विभिन्न क्लाउड प्रदाताओं द्वारा इसे कैसे कार्यान्वित किया जाता है, इसके लिए अक्सर पूछे जाने वाले प्रश्न ऑटोस्केलर कैसे काम करता है और डिप्लॉयमेंट देखें। ऑन-प्रिमाइसेस के लिए, कुछ वर्चुअलाइजेशन प्लेटफॉर्म हैं जिन्हें मांग के आधार पर नए नोड्स को स्पिन करने के लिए स्क्रिप्ट किया जा सकता है।
  • नोड स्वास्थ्य जांच सेट करें: महत्वपूर्ण कार्यभार के लिए, आप यह सुनिश्चित करना चाहते हैं कि उन नोड्स पर चलने वाले नोड और पॉड स्वस्थ हैं। नोड समस्या डिटेक्टर डेमॉन का उपयोग करके, आप सुनिश्चित कर सकते हैं कि आपके नोड स्वस्थ हैं।

उत्पादन उपयोगकर्ता प्रबंधन

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

उत्पादन-गुणवत्ता वाले क्लस्टर को लेने का अर्थ है यह तय करना कि आप कैसे हैं अन्य उपयोगकर्ताओं द्वारा चुनिंदा रूप से पहुंच की अनुमति देना चाहते हैं। विशेष रूप से, आपको उन लोगों की पहचान को सत्यापित करने के लिए रणनीतियों का चयन करने की आवश्यकता है जो आपके क्लस्टर (प्रमाणीकरण) तक पहुंचने का प्रयास करते हैं और यह तय करते हैं कि क्या उनके पास वह करने की अनुमति है जो वे पूछ रहे हैं (प्राधिकरण):

  • प्रमाणीकरण: apiserver क्लाइंट का उपयोग करके उपयोगकर्ताओं को प्रमाणित कर सकता है प्रमाण पत्र, वाहक टोकन, एक प्रमाणीकरण प्रॉक्सी, या HTTP मूल प्रमाणीकरण। आप चुन सकते हैं कि आप किन प्रमाणीकरण विधियों का उपयोग करना चाहते हैं। प्लगइन्स का उपयोग करके, apiserver आपके संगठन की मौजूदा प्रमाणीकरण विधियों, जैसे LDAP या Kerberos का लाभ उठा सकता है। कुबेरनेट्स उपयोगकर्ताओं को प्रमाणित करने के इन विभिन्न तरीकों के विवरण के लिए प्रमाणीकरण देखो।
  • प्राधिकरण: जब आप अपने नियमित उपयोगकर्ताओं को अधिकृत करने के लिए निकलते हैं, तो आप शायद आरबीएसी और एबीएसी प्राधिकरण के बीच चयन करेंगे। उपयोगकर्ता खातों को अधिकृत करने के लिए विभिन्न तरीकों की समीक्षा करने के लिए प्राधिकरण अवलोकन देखें (साथ ही आपके क्लस्टर में सेवा खाते तक पहुंच):
    • भूमिका-आधारित अभिगम नियंत्रण (RBAC): प्रमाणित उपयोगकर्ताओं को अनुमतियों के विशिष्ट सेट की अनुमति देकर आप अपने क्लस्टर तक पहुँच प्रदान कर सकते हैं। अनुमतियाँ एक विशिष्ट नेमस्पेस्स (भूमिका) या संपूर्ण क्लस्टर (ClusterRole) के लिए असाइन की जा सकती हैं। फिर रोलबाइंडिंग और क्लस्टररोलबाइंडिंग का उपयोग करके, उन अनुमतियों को विशेष उपयोगकर्ताओं से जोड़ा जा सकता है।
    • विशेषता-आधारित अभिगम नियंत्रण (ABAC): आपको क्लस्टर में संसाधन विशेषताओं के आधार पर नीतियां बनाने देता है और उन विशेषताओं के आधार पर पहुंच की अनुमति देगा या अस्वीकार करेगा। नीति फ़ाइल की प्रत्येक पंक्ति विषय (उपयोगकर्ता या समूह), संसाधन संपत्ति, गैर-संसाधन संपत्ति (/ संस्करण या / एपिस), और केवल पढ़ने के लिए संस्करण गुणों (एपीआई संस्करण और प्रकार) और विशिष्ट गुणों के मानचित्र की पहचान करती है। विवरण के लिए देखें उदाहरण।

जब कोई आपके उत्पादन कुबेरनेट्स क्लस्टर पर प्रमाणीकरण और प्राधिकरण सेटअप कर रहा हो, तो यहां कुछ बातों पर विचार करना चाहिए:

  • प्राधिकरण मोड सेट करें: जब कुबेरनेट्स एपीआई सर्वर(kube-apiserver) शुरू होता है, समर्थित प्रमाणीकरण मोड को --authorization-mode फ़्लैग का उपयोग करके सेट किया जाना चाहिए। उदाहरण के लिए, kube-adminserver.yaml फ़ाइल में वह फ़्लैग (/etc/kubernetes/manifests में) नोड, आरबीएसी पर सेट किया जा सकता है। यह प्रमाणित अनुरोधों के लिए नोड और आरबीएसी प्राधिकरण की अनुमति देगा।
  • उपयोगकर्ता प्रमाणपत्र और रोल बाइंडिंग (RBAC) बनाएं: यदि आप आरबीएसी प्राधिकरण का उपयोग कर रहे हैं, तो उपयोगकर्ता एक सर्टिफिकेट साइनिंग रिक्वेस्ट (सीएसआर) बना सकते हैं जिस पर क्लस्टर सीए द्वारा हस्ताक्षर किए जा सकते हैं। फिर आप प्रत्येक उपयोगकर्ता के लिए रोल्स और क्लस्टररोल्स को बाध्य कर सकते हैं।विवरण के लिए प्रमाणपत्र पर हस्ताक्षर करने के अनुरोध देखें।
  • ऐसी नीतियां बनाएं जो विशेषताओं को जोड़ती हैं (ABAC): यदि आप एबीएसी प्राधिकरण का उपयोग कर रहे हैं, तो आप चुनिंदा उपयोगकर्ताओं या समूहों को विशेष संसाधनों (जैसे पॉड), नेमस्पेस, या एपीग्रुप तक पहुंचने के लिए अधिकृत करने के लिए नीतियां बनाने के लिए विशेषताओं के संयोजन असाइन कर सकते हैं। अधिक जानकारी के लिए देखें उदाहरण।
  • प्रवेश नियंत्रकों पर विचार करें: एपीआई सर्वर के माध्यम से आने वाले अनुरोधों के लिए प्राधिकरण के अतिरिक्त रूपों में शामिल हैंवेबहुक टोकन प्रमाणीकरण। वेबहुक और अन्य विशेष प्राधिकरण प्रकारों को एपीआई सर्वर में प्रवेश नियंत्रक जोड़कर सक्षम करने की आवश्यकता है।

कार्यभार संसाधनों पर सीमा निर्धारित करें

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

  • नेमस्पेस्स की सीमा निर्धारित करें: मेमोरी और सीपीयू जैसी चीजों पर प्रति नेमस्पेस कोटा सेट करें। विवरण के लिए मेमोरी, सीपीयू और एपीआई संसाधन प्रबंधित करें देखें।आप इनहेरिट करने की सीमा के लिए हिरार्चीकैल नेमस्पेस्स भी सेट कर सकते हैं।
  • DNS मांग के लिए तैयार करें: यदि आप वर्कलोड के बड़े पैमाने पर बढ़ने की उम्मीद करते हैं, तो आपकी DNS सेवा भी बड़े पैमाने पर तैयार होनी चाहिए।क्लस्टर में DNS सेवा को ऑटोस्केल करना देखें।
  • अतिरिक्त सेवा खाते बनाएं: उपयोगकर्ता खाते यह निर्धारित करते हैं कि उपयोगकर्ता क्लस्टर पर क्या कर सकते हैं, जबकि एक सेवा खाता किसी विशेष नेमस्पेस्स के भीतर पॉड एक्सेस को परिभाषित करता है। डिफ़ॉल्ट रूप से, एक पॉड अपने नेमस्पेस्स से डिफ़ॉल्ट सेवा खाता लेता है।नया सेवा खाता बनाने के बारे में जानकारी के लिए सेवा खातों का प्रबंधन देखें।उदाहरण के लिए, आप शायद यह करना चाहें:

आगे क्या है

2.2.1 - कंटेनर रनटाइम

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

कुबेरनेट्स 1.35 के लिए आवश्यक है कि आप एक रनटाइम का उपयोग करें जो कंटेनर रनटाइम इंटरफ़ेस (CRI)के अनुरूप है।

अधिक जानकारी के लिए CRI version support देखें।

यह पृष्ठ Linux पर कुबेरनेट्स के साथ कई सामान्य कंटेनर रनटाइम का उपयोग करने के विवरण सूचीबद्ध करता है:

टिप्पणी:

अन्य ऑपरेटिंग सिस्टम के लिए, अपने प्लेटफ़ॉर्म के अनुसार विशिष्ट प्रलेखन देखें।

Cgroup ड्राइवर

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

जब Linux वातावरण के लिए init सिस्टम, systemd को चुना जाता है, तब init प्रक्रिया रुट(root) control group (cgroup) उत्पन्न करती है और उपभोग करती है तथा cgroup मैनेजर की तरह काम करता है।Systemd और cgroups एकीकृत हैं और प्रत्येक systemd यूनिट को एक cgroup आवंटित होता है। अपने कन्टैनर रनटाइम और kubelet को cgroupfs प्रयोग करने के लिए कॉन्फ़िगर करना संभव है। systemd के साथ cgroupfs प्रयोग करने के कारण दो अलग cgroup मैनेजर होंगे।

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

सेटिंग्स को इस तरह बदलना कि आपका कंटेनर रनटाइम और kubelet systemd का उपयोग करें क्योंकि cgroup ड्राइवर सिस्टम को स्थिर करता है। डॉकर के लिए इसे कॉन्फ़िगर करने के लिए, native.cgroupdriver=systemd सेट करें।

सावधान:

क्लस्टर में शामिल होने वाले नोड के cgroup ड्राइवर को बदलना एक संवेदनशील ऑपरेशन है। यदि kubelet ने एक सीग्रुप ड्राइवर के सिमेंटिक्स (semantics) का उपयोग करके पॉड्स बनाए हैं, तो कंटेनर रनटाइम को दूसरे सीग्रुप ड्राइवर में बदलने से मौजूदा पॉड्स के पॉड सैंडबॉक्स को फिर से बनाते समय त्रुटियां हो सकती हैं। kubelet को पुनरारंभ करने से ऐसी त्रुटियों का समाधान नहीं हो सकता है।

यदि आपके पास स्वचालन है जो इसे व्यवहार्य बनाता है, तो अद्यतन किए गए कॉन्फ़िगरेशन का उपयोग करके नोड को दूसरे के साथ बदलें, या स्वचालन का उपयोग करके इसे पुनर्स्थापित करें।

Cgroup v2

Cgroup v2, cgroup Linux API का अगला संस्करण है। Cgroup v1 से अलग, प्रत्येक कंट्रोलर के लिए एक अलग अनुक्रम के बजाय एक पदानुक्रम है।

नया संस्करण cgroup v1 पर कई सुधार प्रदान करता है, इनमें से कुछ सुधार हैं:

  • API का उपयोग करने का स्पष्ट और आसान तरीका
  • कंटेनरों के लिए सुरक्षित उप-वृक्ष प्रतिनिधिमंडल
  • प्रेशर स्टॉल की जानकारी जैसी नई सुविधाएँ

भले ही कर्नेल हाइब्रिड कॉन्फ़िगरेशन का समर्थन करता हो, जहां कुछ नियंत्रक cgroup v1 द्वारा प्रबंधित किए जाते हैं और कुछ अन्य cgroup v2 द्वारा, Kubernetes सभी नियंत्रकों को प्रबंधित करने के लिए केवल उसी cgroup संस्करण का समर्थन करता है।

यदि सिस्टमड (Systemd) डिफ़ॉल्ट रूप से cgroup v2 का उपयोग नहीं करता है, तो आप कर्नेल कमांड लाइन में systemd.unified_cgroup_hierarchy=1 जोड़कर सिस्टम को इसका उपयोग करने के लिए कॉन्फ़िगर कर सकते हैं।

# यह उदाहरण एक Linux OS के लिए है जो DNF पैकेज मैनेजर का उपयोग करता है
# आपका सिस्टम कमांड लाइन सेट करने के लिए एक अलग विधि का उपयोग कर सकता है
# लिनक्स कर्नेल का उपयोग करता है।
sudo dnf install -y grubby && \
  sudo grubby \
  --update-kernel=ALL \
  --args="systemd.unified_cgroup_hierarchy=1"

यदि आप कर्नेल के लिए कमांड लाइन बदलते हैं, तो आपको अपने से पहले नोड को रिबूट करना होगा परिवर्तन प्रभावी होता है।

Cgroup v2 में स्विच करते समय उपयोगकर्ता अनुभव में कोई उल्लेखनीय अंतर नहीं होना चाहिए, जब तक कि उपयोगकर्ता सीग्रुप फाइल सिस्टम को सीधे नोड पर या कंटेनरों के भीतर से एक्सेस कर रहे हैं।

इसका उपयोग करने के लिए, Cgroup v2 को CRI रनटाइम द्वारा भी सपोर्टेड (supported) होना चाहिए।

Kubeadm प्रबंधित क्लस्टर में systemd ड्राइवर में माइग्रेट करना

यदि आप मौजूदा kubeadm प्रबंधित क्लस्टर में systemd cgroup ड्राइवर में माइग्रेट करना चाहते हैं, तो माइग्रेशन गाइड का पालन करें।

CRI संस्करण समर्थन

आपके कंटेनर रनटाइम को कंटेनर रनटाइम इंटरफ़ेस के कम से कम v1alpha2 का समर्थन करना चाहिए।

कुबेरनेट्स 1.35 डिफ़ॉल्ट रूप से CRI API के v1 का उपयोग करता है।यदि कंटेनर रनटाइम v1 API का समर्थन नहीं करता है, तो क्यूबलेट वापस आ जाता है इसके बजाय (बहिष्कृत) v1alpha2 API का उपयोग करना।

कंटेनर रनटाइम

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

कंटेनरडी

यह खंड कंटेनरडी को CRI रनटाइम के रूप में उपयोग करने के लिए आवश्यक कदम है।

अपने सिस्टम पर containerd इंस्टॉल करने के लिए निम्नलिखित कमांड का उपयोग करें:

पूर्वापेक्षाएँ इंस्टॉल और कॉन्फ़िगर करें:

cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter
# सेटअप आवश्यक sysctl params, ये रिबूट के दौरान बने रहते हैं।
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables  = 1
net.ipv4.ip_forward                 = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
# रिबूट के बिना sysctl params लागू करें
sudo sysctl --system

कंटेनरडी इंस्टॉल करें:

  1. आधिकारिक डॉकर रिपॉजिटरी से containerd.io पैकेज इंस्टॉल करें।
    अपने संबंधित लिनक्स वितरण के लिए डॉकर रिपॉजिटरी इंस्टॉल करने और containerd.io पैकेज इंस्टॉल करने के निर्देश यहां देखे जा सकते हैंडॉकर इंजन इंस्टॉल करें.

  2. कंटेनरडी कॉन्फ़िगर करें:

    sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

  3. कंटेनरडी को पुनरारंभ करें:

    sudo systemctl restart containerd

Powershell सत्र प्रारंभ करें, $Version को वांछित संस्करण पर सेट करें (उदाहरण: $Version=1.4.3), और फिर निम्न आदेश चलाएँ:

  1. कंटेनरडी डाउनलोड करें:

    curl.exe -L https://github.com/containerd/containerd/releases/download/v$Version/containerd-$Version-windows-amd64.tar.gz -o containerd-windows-amd64.tar.gz
tar.exe xvf .\containerd-windows-amd64.tar.gz

  2. एक्सट्रेक्ट एंड कॉन्फ़िगर:

    Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd"    -Recurse -Force
cd $Env:ProgramFiles\containerd\
.\containerd.exe config default | Out-File config.toml -Encoding         ascii
# कॉन्फ़िगरेशन की समीक्षा करें। सेटअप के आधार पर आप समायोजित करना चाह सकते हैं:
# - सैंडबॉक्स_इमेज (कुबेरनेट्स पॉज़ इमेज)
# - cni bin_dir और conf_dir स्थान
Get-Content config.toml
# (वैकल्पिक - लेकिन अत्यधिक अनुशंसित) विंडोज डिफेंडर स्कैन से कंटेनर को बाहर करें
Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe"

  3. कंटेनरडी शुरू करें:

    .\containerd.exe --register-service
Start-Service containerd

systemd` cgroup ड्राइवर का उपयोग करें

systemd cgroup ड्राइवर {#containerd-systemd} का उपयोग करनाrunc के साथ /etc/containerd/config.toml में systemd cgroup ड्राइवर का उपयोग करने के लिए, सेट करें

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
  ...
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
    SystemdCgroup = true

यदि आप इस परिवर्तन को लागू करते हैं,तो सुनिश्चित करें कि आप फिर से कंटेनरडी को पुनरारंभ करें:

sudo systemctl restart containerd

जब आप kubeadm का उपयोग करें, मैन्युअल रूप से कॉन्फ़िगर करेंक्यूबलेट के लिए cgroup ड्राइवर मैन्युअल रूप से कॉन्फ़िगर करें।

CRI-O

इस खंड में CRI-O को कंटेनर रनटाइम के रूप में इंस्टॉल करने के लिए आवश्यक जानकारी है।

अपने सिस्टम पर CRI-O इंस्टॉल करने के लिए निम्नलिखित कमांड का उपयोग करें:

टिप्पणी:

CRI-O के प्रमुख और छोटे संस्करणों को Kubernetes के प्रमुख और छोटे संस्करणों से मेल खाना चाहिए। अधिक जानकारी के लिए CRI-O compatibility matrix देखें।

पूर्वापेक्षाएँ इंस्टॉल और कॉन्फ़िगर करें:

# बूटअप पर मॉड्यूल लोड करने के लिए .conf फाइल बनाएं
cat <<EOF | sudo tee /etc/modules-load.d/crio.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter
# आवश्यक sysctl params सेट करें, ये रिबूट के दौरान बने रहते हैं।
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables  = 1
net.ipv4.ip_forward                 = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
sudo sysctl --system

निम्नलिखित ऑपरेटिंग सिस्टम पर CRI-O स्थापित करने के लिए, एनवायरनमेंट वेरिएबलOS को निम्न तालिका से उपयुक्त मान पर सेट करें:

ऑपरेटिंग सिस्टम $OS
Debian Unstable Debian_Unstable
Debian Testing Debian_Testing

फिर, सेट करें `$VERSION`CRI-O संस्करण में जो आपके Kubernetes संस्करण से मेल खाता है। उदाहरण के लिए, यदि आप CRI-O 1.20 इंस्टॉल करना चाहते हैं, तो `VERSION=1.20` सेट करें। आप अपनी स्थापना को किसी विशिष्ट रिलीज़ पर पिन कर सकते हैं। संस्करण 1.20.0 स्थापित करने के लिए, `VERSION=1.20:1.20.0` सेट करें।

कृपया यह करें

cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /
EOF
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /
EOF
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
sudo apt-get update
sudo apt-get install cri-o cri-o-runc

निम्नलिखित ऑपरेटिंग सिस्टम पर स्थापित करने के लिए, एनवायरनमेंट वेरिएबल OS सेट करें निम्न तालिका में उपयुक्त फ़ील्ड के लिए:

ऑपरेटिंग सिस्टम $OS
Ubuntu 20.04 xUbuntu_20.04
Ubuntu 19.10 xUbuntu_19.10
Ubuntu 19.04 xUbuntu_19.04
Ubuntu 18.04 xUbuntu_18.04

फिर, `$VERSION` को CRI-O संस्करण में सेट करें जो आपके Kubernetes संस्करण से मेल खाता हो। उदाहरण के लिए, यदि आप CRI-O 1.20 इंस्टॉल करना चाहते हैं, तो `VERSION=1.20` सेट करें। आप अपनी स्थापना को किसी विशिष्ट रिलीज़ पर पिन कर सपर पिन कर सकते हैं। संस्करण 1.20.0 स्थापित करने के लिए, `VERSION=1.20:1.20.0` सेट करें।

कृपया यह करें

cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /
EOF
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /
EOF
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers-cri-o.gpg add -
sudo apt-get update
sudo apt-get install cri-o cri-o-runc

निम्नलिखित ऑपरेटिंग सिस्टम पर स्थापित करने के लिए, एनवायरनमेंट वे वेरिएबलOS सेट करें निम्न तालिका में उपयुक्त फ़ील्ड के लिए:

ऑपरेटिंग सिस्टम $OS
Centos 8 CentOS_8
Centos 8 Stream CentOS_8_Stream
Centos 7 CentOS_7

फिर, `$VERSION` को CRI-O संस्करण में सेट करें जो आपके Kubernetes संस्करण से मेल खाता हो। उदाहरण के लिए, यदि आप CRI-O 1.20 इंस्टॉल करना चाहते हैं, तो `VERSION=1.20` सेट करें। आप अपनी स्थापना को किसी विशिष्ट रिलीज़ पर पिन कर सकते हैं। संस्करण 1.20.0 स्थापित करने के लिए, `VERSION=1.20:1.20.0` सेट करें।

कृपया यह करें

sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo
sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo
sudo yum install cri-o


sudo zypper install cri-o

$VERSION को CRI-O संस्करण में सेट करें जो आपके Kubernetes संस्करण से मेल खाता हो।उदाहरण के लिए, यदि आप CRI-O 1.20, VERSION=1.20 स्थापित करना चाहते हैं।

आप इसके साथ उपलब्ध संस्करण पा सकते हैं:

sudo dnf module list cri-o

CRI-O फेडोरा पर विशिष्ट रिलीज के लिए पिनिंग का समर्थन नहीं करता है।

तब इसे करें:

sudo dnf module enable cri-o:$VERSION
sudo dnf install cri-o

CRI-O शुरू करें :

sudo systemctl daemon-reload
sudo systemctl enable crio --now

अधिक जानकारी के लिए CRI-O इंस्टॉलेशन गाइड देखें।

cgroup ड्राइवर

CRI-O डिफ़ॉल्ट रूप से systemd cgroup ड्राइवर का उपयोग करता है।cgroupfs cgroup ड्राइवर पर स्विच करने के लिए, या तो /etc/crio/crio.conf संपादित करें या /etc/crio/crio.conf.d/02-cgroup-manager.conf में ड्रॉप-इन कॉन्फ़िगरेशन रखें। उदाहरण के लिए:

[crio.runtime]
conmon_cgroup = "pod"
cgroup_manager = "cgroupfs"

कृपया बदले हुए conmon_cgroup पर भी ध्यान दें, जिसे cgroupfs के साथ CRI-O का उपयोग करते समय पॉड मान पर सेट करना होगा।आमतौर पर क्यूबलेट के cgroup ड्राइवर कॉन्फ़िगरेशन (आमतौर पर kubeadm के माध्यम से किया जाता है) और CRI-O को सिंक में रखना आवश्यक है।

डॉकर इंजन

डॉकर इंजन कंटेनर रनटाइम है जिसने यह सब शुरू किया। पूर्व में सिर्फ डॉकर के रूप में जाना जाता था,यह कंटेनर रनटाइम विभिन्न रूपों में उपलब्ध है। डॉकर इंजन इंस्टॉल करें आपके विकल्पों की व्याख्या करता है इस रनटाइम को इंस्टॉल करने के लिए।

डॉकर इंजन कुबेरनेट्स 1.35 के साथ सीधे संगत है, जो कि बहिष्कृत dockershim घटक का उपयोग करता है। अधिक जानकारी के लिए और संदर्भ, Dockershim deprecation FAQ देखें।

आप तृतीय-पक्ष एडेप्टर भी पा सकते हैं जो आपको कुबेरनेट्स के साथ डॉकर इंजन का उपयोग करने देता है, समर्थित Container Runtime Interface के माध्यम से(CRI)।

निम्नलिखित CRI एडेप्टर डॉकर इंजन के साथ काम करने के लिए डिज़ाइन किए गए हैं:

मिरांटिस कंटेनर रनटाइम

Mirantis Container Runtime (MCR) एक व्यावसायिक रूप से है उपलब्ध कंटेनर रनटाइम जिसे पहले डॉकर एंटरप्राइज एडिशन के नाम से जाना जाता था।

आप खुले स्रोत का उपयोग करके कुबेरनेट्स के साथ मिरांटिस कंटेनर रनटाइम का उपयोग कर सकते हैं cri-dockerd घटक, MCR के साथ शामिल है।

2.2.2 - Turnkey Cloud Solutions

यह पृष्ठ कुबेरनेट्स प्रमाणित समाधान प्रदाताओं की एक सूची प्रदान करता है। हर एक प्रदाता पृष्ठ से आप सीख सकते हैं कि उत्पादन योग्य क्लस्टर को इंस्टॉल और सेटअप कैसे करें।

2.2.3 - परिनियोजन टूल के साथ कुबेरनेट्स स्थापित करे

अपना स्वयं का प्रोडक्शन कुबेरनेट्स क्लस्टर स्थापित करने के लिए कई विधियाँ और उपकरण है। उदाहरण के लिए:

  • kubeadm

  • kops: एक स्वचालित क्लस्टर प्रावधान उपकरण। ट्यूटोरियल, सर्वोत्तम प्रथाओं, कॉन्फ़िगरेशन विकल्पों और समुदाय तक पहुंचने की जानकारी के लिए, कृपया kOps वेबसाइट देखें।

  • kubespray: सामान्य OS/कुबेरनेट्स क्लस्टर कॉन्फ़िगरेशन प्रबंधन कार्यों के लिए अन्सिबल प्लेबुकस, इन्वेंट्री, प्रोविजनिंग टूल और डोमेन ज्ञान की एक संरचना। आप स्लैक चैनल #kubespray पर समुदाय को संपर्क कर सकते है।

2.2.4 - कुबेरनेट्स में Windows

2.3 - उत्तम प्रथाएं

3 - अवधारणाएँ

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

3.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)। इसके विपरीत, कुबेरनेट्स में स्वतंत्र, कंपोज़ेबल नियंत्रण प्रक्रियाओं का एक सेट शामिल है जो वर्तमान स्थिति को प्रदान की गई वांछित स्थिति की ओर लगातार चलता है। इससे कोई फर्क नहीं पड़ता कि आप ए से सी कैसे प्राप्त करते हैं। केंद्रीकृत नियंत्रण की भी आवश्यकता नहीं है। इसका परिणाम एक ऐसी प्रणाली में होता है जो उपयोग में आसान और अधिक शक्तिशाली, मजबूत, लचीला और एक्स्टेंसिबल है।

आगे क्या है

3.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.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 की पूरी सूची के साथ, एक समर्पित अनुभाग में प्रलेखित है:

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

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

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

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

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

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

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

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

Implementations

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

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

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

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

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

4 - कार्य

कुबेरनेट्स प्रलेखन के इस खंड के पृष्ठ एकल कार्य करने का तरीका दिखाते हैं। आमतौर पर, कार्य पृष्ठ दिखाता है कि किसी एक काम को कई छोटे चरणों में विभाजित करके कैसे करना है।

यदि आप एक कार्य पृष्ठ लिखना चाहते हैं, तो देखेंप्रलेखन के लिए एक पुल अनुरोध (Pull Request) बनाएं.

4.1 - उपकरण स्थापित करें

अपने कंप्यूटर पर कुबेरनेट्स टूल सेटअप करें।

kubectl

कुबेरनेट्स कमांड-लाइन टूल, kubectl, आपको कुबेरनेट्स क्लस्टर पर कमांड चलाने की अनुमति देता है।

आप एप्लिकेशन को डिप्लॉय करने, क्लस्टर संसाधनों का निरीक्षण और प्रबंधन करने और लॉग देखने के लिए kubectl का उपयोग कर सकते हैं।

kubectl संचालन की पूरी सूची सहित अधिक जानकारी के लिए, देखें kubectl संदर्भ प्रलेखन.

kubectl विभिन्न प्रकार के Linux प्लेटफॉर्म, macOS और Windows पर इंस्टॉल करने योग्य है।नीचे अपना उपयुक्त ऑपरेटिंग सिस्टम खोजें।

kind

kind आपको अपने कंप्यूटर पर कुबेरनेट्स चलाने देता है।इस उपकरण के लिए आवश्यक है कि आपके पास Docker इंस्टॉल और कॉन्फ़िगर किया गया हो।

kind क्विक स्टार्ट पृष्ठ आपको दिखाता है कि kind चलाने के लिए आपको क्या करने की आवश्यकता है।

kind क्विक स्टार्ट गाइड देखें

minikube

kind की तरह, minikube एक उपकरण है जो आपको स्थानीय स्तर पर कुबेरनेट्स चलाने देता है। minikube आपके कंप्यूटर (windows, macOS और linux पीसी सहित) पर सिंगल-नोड कुबेरनेट्स क्लस्टर चलाता है ताकि आप कुबेरनेट्स सीख सकें या डेवलपमेंट कर सकें।

यदि आपका ध्यान उपकरण को इंस्टॉल करने पर है तो आप मुख्य आरंभ करें! गाइड का अनुसरण कर सकते हैं।

minikube क्विक स्टार्ट गाइड देखें

एक बार जब आपके पास minikube काम कर रहा हो, तो आप इसका उपयोग नमूना एप्लिकेशन चलाने के लिए कर सकते हैं।

kubeadm

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

kubeadm इंस्टॉल करना आपको दिखाता है कि kubeadm को कैसे इंस्टॉल किया जाए।एक बार इंस्टॉल होने के बाद, आप इसका उपयोग क्लस्टर बनाने के लिए कर सकते हैं।

kubeadm इंस्टॉल गाइड देखें

4.1.1 - Linux पर kubectl इंस्टॉल और सेट अप करें

शुरू करने से पहले

आप kubectl संस्करण का उपयोग करे जो आपके क्लस्टर के एक माइनर संस्करण के भीतर हो। उदाहरण के लिए, v1.35 क्लाइंट v1.34, v1.35 और v1.36 कण्ट्रोल प्लेन के साथ संवाद कर सकते हैं।kubectl के नवीनतम संस्करण का उपयोग करने से अप्रत्याशित मुद्दों से बचने में मदद मिलती है।

Linux पर kubectl इंस्टॉल करें

Linux पर kubectl संस्थापित करने के लिए निम्नलिखित विधियाँ मौजूद हैं:

Linux पर curl के माध्यम से kubectl बाइनरी इंस्टॉल करें

  1. कमांड से नवीनतम रिलीज डाउनलोड करें:

    curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

    टिप्पणी:

    एक विशिष्ट संस्करण डाउनलोड करने के लिए, कमांड के $(curl -L -s https://dl.k8s.io/release/stable.txt) हिस्से को विशिष्ट संस्करण से बदलें।

    उदाहरण के लिए, लिनक्स पर 1.35.0 संस्करण डाउनलोड करने के लिए, टाइप करें:

    curl -LO https://dl.k8s.io/release/v1.35.0/bin/linux/amd64/kubectl

  2. बाइनरी को मान्य करें (वैकल्पिक)

kubectl चेकसम फाइल डाउनलोड करें:

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"

चेकसम फ़ाइल से kubectl बाइनरी को मान्य करें:

echo "$(<kubectl.sha256) kubectl" | sha256sum --check

यदि मान्य है, तो आउटपुट है:

kubectl: OK

अगर चेक फेल हो जाता है, तो sha256 nonzero स्थिति के साथ बाहर निकलता है और इस आउटपुट के समान प्रिंट करता है:

kubectl: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

टिप्पणी:

बाइनरी और चेकसम का एक ही संस्करण डाउनलोड करें।

  1. kubectl इंस्टॉल करें

    sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

    टिप्पणी:

    यदि आपके पास टारगेट सिस्टम पर रुट एक्सेस नहीं है, आप तब भी kubectl को ~/.local/bin डायरेक्टरी में इंस्टॉल कर सकते हैं:

    chmod +x kubectl
mkdir -p ~/.local/bin/kubectl
mv ./kubectl ~/.local/bin/kubectl
# and then add ~/.local/bin/kubectl to $PATH

  2. यह सुनिश्चित करने के लिए परीक्षण करें कि आपके द्वारा इंस्टॉल किया गया संस्करण उप-टू-डेट है:

    kubectl version --client

नेटिव पैकेज मैनेजमेंट के माध्यम से इंस्टॉल करें

  1. apt पैकेज इंडेक्स को अपडेट करे और कुबेरनेट्स apt रिपॉजिटरी का उपयोग करने के लिए आवश्यक पैकेज इंस्टॉल करें:

    sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl gnupg

  2. गूगल क्लाउड पब्लिक साइनिंग कुंजी (key) डाउनलोड करें:

    sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg

  3. कुबेरनेट्स apt रिपॉजिटरी को जोड़े:

    echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

  4. नए रिपॉजिटरी के साथ apt पैकेज इंडेक्स अपडेट करें और kubectl इंस्टॉल करें:

    sudo apt-get update
sudo apt-get install -y kubectl



cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
yum install -y kubectl

अन्य पैकेज मैनेजमेंट के माध्यम से इंस्टॉल करें

यदि आप Ubuntu या किसी अन्य Linux डिस्ट्रीब्यूशन पर हैं जो snap पैकेज मैनेजर को सपोर्ट करता है, तो kubectl snap एप्लिकेशन के रूप में उपलब्ध है।

snap install kubectl --classic
kubectl version --client

यदि आप Linux पर Homebrew पैकेज मैनेजर का उपयोग कर रहे हैं, तो kubectl इंस्टालेशन के लिए उपलब्ध है।

brew install kubectl
kubectl version --client

kubectl कॉन्फ़िगरेशन सत्यापित करें

kubectl को कुबेरनेट्स क्लस्टर को खोजने और एक्सेस करने के लिए, उसेक्यूबकॉन्फिग फाइल(kubeconfig) की आवश्यकता होती है,जो स्वचालित रूप से तब बनता है जब आपkube-up.sh का उपयोग करके क्लस्टर बनाते हैं या मिनीक्यूब क्लस्टर को सफलतापूर्वक डिप्लॉय करते हैं।डिफ़ॉल्ट रूप से, kubectl कॉन्फ़िगरेशन ~/.kube/config पर स्थित होता है।

जाँच करें कि क्लस्टर स्टेट प्राप्त करके kubectl को ठीक से कॉन्फ़िगर किया गया है:

kubectl cluster-info

यदि आपको एक URL प्रतिक्रिया दिखती हैं, तो kubectl आपके क्लस्टर तक पहुँचने के लिए सही ढंग से कॉन्फ़िगर हुआ है।

यदि आपको निम्नलिखित संदेश दिखाई देता है, तो kubectl ठीक से कॉन्फ़िगर नहीं हुआ है या कुबेरनेट्स क्लस्टर से कनेक्ट करने में सक्षम नहीं है।

The connection to the server <server-name:port> was refused - did you specify the right host or port?

उदाहरण के लिए, यदि आप अपने लैपटॉप (स्थानीय रूप से) पर कुबेरनेट्स क्लस्टर चलाना चाहते हैं, तो आपको पहले मिनीक्यूब (minikube) जैसे टूल को इंस्टॉल करना होगा और ऊपर बताए गए कमांड को फिर से चलाना होगा।

यदि kubectl cluster-info URL प्रतिक्रिया देता है, लेकिन आप अपने क्लस्टर को एक्सेस नहीं कर पा रहें हैं, तो यह जाँचने के लिए कि क्या यह ठीक से कॉन्फ़िगर किया गया है, इस कमांड का उपयोग करें:

kubectl cluster-info dump

वैकल्पिक kubectl कॉन्फ़िगरेशन और प्लगइन्स

शेल ऑटोकम्प्लेशन सक्षम करें

kubectl Bash और Zsh के लिए ऑटोकम्प्लेशन का सपोर्ट प्रदान करता है, जो आपका काफी समय बचा सकता है।

नीचे Bash और Zsh के लिए ऑटोकम्प्लेशन स्थापित करने की प्रक्रियाएँ हैं।

परिचय

Bash के लिए kubectl समापन स्क्रिप्ट kubectl completion bash कमांड के साथ उत्पन्न की जा सकती है। आपके शेल में समापन स्क्रिप्ट को सोर्स करने से kubectl ऑटोकम्पलीशन सक्षम हो जाती है।

हालाँकि, समापन की स्क्रिप्ट bash-completion पर निर्भर हैं जिसका अर्थ है कि आपको पहले इस सॉफ़्टवेयर को इंस्टॉल करना होगा (आप type _init_completion चलाकर परीक्षण कर सकते हैं कि आपने पहले से bash-completion इंस्टॉल की है या नहीं)।

Bash-completion को इंस्टॉल करें

कई पैकेज मैनेजर द्वारा bash-completion प्रदान की जाती है (यहाँ देखें)। आप इसे apt-get install bash-completion या yum install bash-completion आदि के साथ इंस्टॉल कर सकते हैं।

यह कमांड /usr/share/bash-completion/bash_completion उत्त्पन्न करता है, जो bash-completion की मुख्य स्क्रिप्ट है। आपके पैकेज मैनेजर के आधार पर, आपको इस फाइल को अपनी ~/.bashrc फाइल में मैन्युअल रूप से सोर्स करना होगा।

यह पता लगाने के लिए, अपना शेल पुनः लोड करें और type _init_completion रन करे। यदि कमांड सफल होता है, तो आप पहले से ही तैयार हैं, अन्यथा अपनी ~/.bashrc फ़ाइल में निम्नलिखित जोड़ें:

source /usr/share/bash-completion/bash_completion

अपना शेल पुनः लोड करें और type _init_completion टाइप करके सत्यापित करें कि बैश-कम्पलीशन सही ढंग से इंस्टॉल है।

kubectl ऑटोकम्पलीशन सक्षम करे

अब आपको यह सुनिश्चित करने की आवश्यकता है कि kubectl समापन स्क्रिप्ट आपके सभी शेल सत्रों (sourced) में प्राप्त हो जाए। आप ऐसा दो तरीकों से कर सकते हैं:

  • अपनी ~/.bashrc फ़ाइल में समापन स्क्रिप्ट सॉर्स करें:

    echo 'source <(kubectl completion bash)' >>~/.bashr

  • समापन स्क्रिप्ट को /etc/bash_completion.d डायरेक्टरी में जोड़ें:bash kubectl completion bash >/etc/bash_completion.d/kubectl

यदि आप के पास kubectl के लिए एक अन्य नाम (alias) है, तो आप उस अन्य नाम के साथ काम करने के लिए शेल समापन को बढ़ा सकते हैं:

echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -F __start_kubectl k' >>~/.bashrc

टिप्पणी:

bash-completion सभी समापन स्क्रिप्ट को /etc/bash_completion.d में सोर्स करता है।

दोनों दृष्टिकोण बराबर हैं। आपके शेल को पुनः लोड करने के बाद, Kubectl ऑटोकम्पलीशन कार्य करना शुरू कर देगा।

Zsh के लिए kubectl कम्पलीशन स्क्रिप्ट kubectl completion zsh कमांड के साथ उत्पन्न की जा सकती है। आपके शेल में कम्पलीशन स्क्रिप्ट को सोर्स करने से kubectl ऑटो-कम्पलीशन सक्षम हो जाती है।

अपने सभी शेल सत्रों में ऐसा करने के लिए, निम्नलिखित को अपनी ~/.zshrc फ़ाइल में जोड़ें:

source <(kubectl completion zsh)

यदि आपके पास kubectl के लिए एक उपनाम है, तो आप उस उपनाम के साथ काम करने के लिए शेल कम्पलीशन को बढ़ा सकते हैं:

echo 'alias k=kubectl' >>~/.zshrc
echo 'complete -F __start_kubectl k' >>~/.zshrc

अपने शेल को पुनः लोड करने के बाद, kubectl ऑटो-कम्पलीशन कार्य करना चाहिए।

यदि आपको कोई त्रुटि मिलती है जैसे complete:13: command not found: compdef, तो अपनी ~/.zshrc फ़ाइल की शुरुआत में निम्नलिखित जोड़ें:

autoload -Uz compinit
compinit

kubectl convert प्लगइन इंस्टॉल करें

कुबेरनेट्स कमांड-लाइन टूल kubectl के लिए एक प्लगइन, जो आपको विभिन्न API संस्करण के बीच मैनिफ़ेस्ट को बदलने करने की अनुमति देता है।यह विशेष रूप से नए कुबेरनेट्स रिलीज के साथ एक गैर-बहिष्कृत API संस्करण में मैनिफेस्ट को माइग्रेट करने में सहायक हो सकता है।अधिक जानकारी के लिए, गैर पदावनत एपिस में विस्थापित करें पर जाएं।

  1. कमांड से नवीनतम रिलीज डाउनलोड करें:

    curl -LO https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert

  2. बाइनरी को मान्य करें (वैकल्पिक)

    kubectl-convert चेकसम फ़ाइल डाउनलोड करें:

    curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert.sha256"

    चेकसम फ़ाइल से kubectl-convert बाइनरी को मान्य करें:

    echo "$(<kubectl-convert.sha256) kubectl-convert" | sha256sum --check

    यदि मान्य है, तो आउटपुट है:

    kubectl-convert: OK

    अगर चेक फेल हो जाता है, तो sha256 nonzero स्थिति के साथ बाहर निकलता है और इस आउटपुट के समान प्रिंट करता है:

    kubectl-convert: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

    टिप्पणी:

    बाइनरी और चेकसम का एक ही संस्करण डाउनलोड करें।

  3. kubectl-convert इंस्टॉल करें

    sudo install -o root -g root -m 0755 kubectl-convert /usr/local/bin/kubectl-convert

  4. सत्यापित करें कि प्लगइन सफलतापूर्वक इंस्टॉल है

    kubectl convert --help

    यदि आपको कोई त्रुटि नहीं दिखाई देती है, तो इसका मतलब है कि प्लगइन सफलतापूर्वक इंस्टॉल हो गया है।

आगे क्या है

4.1.2 - macOS पर kubectl इंस्टॉल और सेटअप करें

शुरू करने से पहले

आप kubectl संस्करण का उपयोग करे जो आपके क्लस्टर के एक माइनर संस्करण भीतर हो। उदाहरण के लिए, v1.35 क्लाइंट v1.34, v1.35 और v1.36 कण्ट्रोल प्लेन के साथ कम्युनिकेट कर सकते हैं।kubectl के नए संस्करण का उपयोग करने से समस्या से बचत हो सकती है।

macOS पर kubectl इंस्टॉल करें

macOS पर kubectl संस्थापित करने के लिए निम्नलिखित विधियाँ मौजूद हैं:

macOS पर curl के माध्यम से kubectl बाइनरी इंस्टॉल करें

  1. नवीनतम रिलीज़ डाउनलोड करें:

    
   curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
   

    
   curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl"

    टिप्पणी:

    एक विशिष्ट संस्करण डाउनलोड करने के लिए, कमांड के इस हिस्से $(curl -L -s https://dl.k8s.io/release/stable.txt) को विशिष्ट संस्करण से बदलें।

    उदाहरण के लिए, Intel macOS पर 1.35.0 संस्करण डाउनलोड करने के लिए, टाइप करें:

    curl -LO "https://dl.k8s.io/release/v1.35.0/bin/darwin/amd64/kubectl"

    और Apple Silicon macOS के लिए, टाइप करें:

    curl -LO "https://dl.k8s.io/release/v1.35.0/bin/darwin/arm64/kubectl"

  2. बाइनरी को मान्य करें (वैकल्पिक))

    kubectl चेकसम फाइल डाउनलोड करें:

    
   curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256"
   

    
   curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl.sha256"

    चेकसम फ़ाइल से kubectl बाइनरी को मान्य करें:

    echo "$(<kubectl.sha256)  kubectl" | shasum -a 256 --check

    यदि मान्य है, तो आउटपुट है:

    kubectl: OK

    अगर चेक फेल हो जाता है, तो shasum nonzero स्थिति के साथ बाहर निकलता है और इस आउटपुट के समान प्रिंट करता है:

    kubectl: FAILED
shasum: WARNING: 1 computed checksum did NOT match

    टिप्पणी:

    बाइनरी और चेकसम का एक ही संस्करण डाउनलोड करें।

  3. kubectl बाइनरी को एक्सेक्यूट करने योग्य बनायें।

    chmod +x ./kubectl

  4. kubectl बाइनरी को अपने सिस्टम PATH के फ़ाइल स्थान पर ले जाएँ।

    sudo mv ./kubectl /usr/local/bin/kubectl
sudo chown root: /usr/local/bin/kubectl

    टिप्पणी:

    सुनिश्चित करें कि /usr/local/bin आपके पाथ एनवायरनमेंट वेरिएबल में है।

  5. यह सुनिश्चित करने के लिए परीक्षण करें कि आपके द्वारा इंस्टॉल किया गया संस्करण उप-टू-डेट है:

    kubectl version --client

Homebrew के माध्यम से macOS पर इंस्टॉल करें

यदि आप macOS पर हैं और Homebrew पैकेज मैनेजर का उपयोग कर रहे हैं, आप Homebrew के साथ kubectl इंस्टॉल कर सकते हैं।

  1. इंस्टालेशन कमांड रन करें:

    brew install kubectl

    या

    brew install kubernetes-cli

  2. यह सुनिश्चित करने के लिए परीक्षण करें कि आपके द्वारा इंस्टॉल किया गया संस्करण उप-टू-डेट है:

    kubectl version --client

Macports के माध्यम से macOS पर इंस्टॉल करें

यदि आप macOS पर हैं और Macports पैकेज मैनेजर का उपयोग कर रहे हैं, आप Macports के साथ kubectl इंस्टॉल कर सकते हैं।

  1. इंस्टालेशन कमांड रन करें:

    sudo port selfupdate
sudo port install kubectl

  2. यह सुनिश्चित करने के लिए परीक्षण करें कि आपके द्वारा इंस्टॉल किया गया संस्करण उप-टू-डेट है:

    kubectl version --client

kubectl कॉन्फ़िगरेशन सत्यापित करें

kubectl को कुबेरनेट्स क्लस्टर को खोजने और एक्सेस करने के लिए, उसेक्यूबकॉन्फिग फाइल(kubeconfig) की आवश्यकता होती है,जो स्वचालित रूप से तब बनता है जब आपkube-up.sh का उपयोग करके क्लस्टर बनाते हैं या मिनीक्यूब क्लस्टर को सफलतापूर्वक डिप्लॉय करते हैं।डिफ़ॉल्ट रूप से, kubectl कॉन्फ़िगरेशन ~/.kube/config पर स्थित होता है।

जाँच करें कि क्लस्टर स्टेट प्राप्त करके kubectl को ठीक से कॉन्फ़िगर किया गया है:

kubectl cluster-info

यदि आपको एक URL प्रतिक्रिया दिखती हैं, तो kubectl आपके क्लस्टर तक पहुँचने के लिए सही ढंग से कॉन्फ़िगर हुआ है।

यदि आपको निम्नलिखित संदेश दिखाई देता है, तो kubectl ठीक से कॉन्फ़िगर नहीं हुआ है या कुबेरनेट्स क्लस्टर से कनेक्ट करने में सक्षम नहीं है।

The connection to the server <server-name:port> was refused - did you specify the right host or port?

उदाहरण के लिए, यदि आप अपने लैपटॉप (स्थानीय रूप से) पर कुबेरनेट्स क्लस्टर चलाना चाहते हैं, तो आपको पहले मिनीक्यूब (minikube) जैसे टूल को इंस्टॉल करना होगा और ऊपर बताए गए कमांड को फिर से चलाना होगा।

यदि kubectl cluster-info URL प्रतिक्रिया देता है, लेकिन आप अपने क्लस्टर को एक्सेस नहीं कर पा रहें हैं, तो यह जाँचने के लिए कि क्या यह ठीक से कॉन्फ़िगर किया गया है, इस कमांड का उपयोग करें:

kubectl cluster-info dump

वैकल्पिक Kubectl कॉन्फ़िगरेशन और प्लगइन्स

शेल ऑटोकम्प्लेशन सक्षम करें

kubectl Bash और Zsh के लिए ऑटोकम्प्लेशन का सपोर्ट प्रदान करता है, जो आपका काफी समय बचा सकता है।

नीचे Bash और Zsh के लिए ऑटोकम्प्लेशन स्थापित करने की प्रक्रियाएँ हैं।

परिचय

Bash के लिए kubectl समापन स्क्रिप्ट kubectl completion bash कमांड के साथ उत्पन्न की जा सकती है। आपके शेल में समापन स्क्रिप्ट को सोर्स करने से kubectl ऑटोकम्पलीशन सक्षम हो जाती है।```

हालाँकि, समापन की स्क्रिप्ट bash-completion पर निर्भर हैं जिसका अर्थ है कि आपको पहले इस सॉफ़्टवेयर को इंस्टॉल करना होगा।

चेतावनी:

Bash-completion के लिये दो संस्करण हैं v1 और v2। v1 bash 3.2 के लिये हैं (जो macOS के लिए डिफ़ॉल्ट है), और v2 bash 4.1+ के लिए है।kubectl कम्पलीशन स्क्रिप्ट Bash-completion v1 और Bash 3.2 के साथ ठीक से काम नहीं करती है। इसके लिए Bash-completion v2 और बैश 4.1+ की आवश्यकता है। इसलिए macOS पर kubectl कम्पलीशन को सही तरीके से इस्तेमाल करने के लिए , आपको bash 4.1+ इनस्टॉल और उपयोग करना होगा (निर्देश)। निम्नलिखित निर्देश मानते हैं कि आप बैश का उपयोग करते हैं (अर्थात 4.1  का कोई भी बैश संस्करण या इससे नया)।

अपग्रेड बैश

निम्नलिखित निर्देश मानते हैं कि आप बैश 4.1+ का उपयोग करते हैं। आप अपने बैश के संस्करण को यह चलाकर देख सकते हैं:

echo $BASH_VERSION

यदि यह बहुत पुराना है, तो आप Homebrew का उपयोग करके इसे इनस्टॉल/अपग्रेड कर सकते हैं:

brew install bash

अपने शेल को पुनः लोड करें और सत्यापित करें कि इच्छित संस्करण का उपयोग किया जा रहा है:

echo $BASH_VERSION $SHELL

Homebrew आमतौर पर इसे /usr/local/bin/bash पर इनस्टॉल करता है।

इनस्टॉल bash-completion

टिप्पणी:

जैसा कि उल्लेख किया गया है, ये निर्देश मानते हैं कि आप Bash 4.1+ का उपयोग करते हैं, जिसका अर्थ है कि आप bash-completion v2 इनस्टॉल  करेंगे (Bash 3.2 और bash-completion v1 पर kubectl  पूर्णता काम नहीं करेगी)।

आप type_init_completion से सत्यापित कर सकते हैं कि क्या आपके पास bash-completion v2 पहले से इनस्टॉल है। यदि नहीं, तो आप इसे Homebrew से इनस्टॉल कर सकते हैं

brew install bash-completion@2

जैसा कि इस कमांड के आउटपुट में बताया गया है, अपनी ~/.bash_profile फ़ाइल में निम्नलिखित जोड़ें:

export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"

[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh"

अपने शेल को पुनः लोड करें और type_init_completion से सत्यापित करें कि bash-completion v2 सही ढंग से इनस्टॉल है।

kubectl ऑटोकम्पलीशन सक्षम करें

अब आपको यह सुनिश्चित करने की आवश्यकता है कि kubectl समापन स्क्रिप्ट आपके सभी शेल सत्रों (sourced) में प्राप्त हो जाए। इसे हासिल करने के कई तरीके हैं:

  • अपने कम्पलीशन स्क्रिप्ट को ~/.bash_profile में सोर्स करें:

    echo 'source <(kubectl completion bash)' >>~/.bash_profile

  • कम्पलीशन स्क्रिप्ट को /usr/local/etc/bash_completion.d डायरेक्टरी में जोड़ें:

    kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl

  • यदि आपके पास kubectl के लिए एक नाम (alias) है, तो आप उस उपनाम के साथ काम करने के लिए शेल कम्पलीशन को बढ़ा सकते हैं:

    echo 'alias k=kubectl' >>~/.bash_profile
echo 'complete -F __start_kubectl k' >>~/.bash_profile

  • यदि आपने Homebrew के साथ kubectl इनस्टॉल किया है (जैसा कि यहां बताया गया है), तो kubectl कम्पलीशन स्क्रिप्ट पहले से ही /usr/local/etc/bash_completion.d/kubectl में होनी चाहिए। ऐसे में आपको कुछ भी करने की जरूरत नहीं है।

टिप्पणी:

bash-completion Homebrew से इनस्टॉल होने पर, सारे फाइल्स को BASH_COMPLETION_COMPAT_DIR डायरेक्टरी में सोर्स कर देता है। इसलिए आखरी दो तरीके काम करते हैं।
किसी भी स्थिति में, आपके शेल को पुनः लोड करने के बाद, Kubectl पूर्णता कार्य करना चाहिए।

Zsh के लिए kubectl कम्पलीशन स्क्रिप्ट kubectl completion zsh कमांड के साथ उत्पन्न की जा सकती है। आपके शेल में कम्पलीशन स्क्रिप्ट को सोर्स करने से kubectl ऑटो-कम्पलीशन सक्षम हो जाती है।

अपने सभी शेल सत्रों में ऐसा करने के लिए, निम्नलिखित को अपनी ~/.zshrc फ़ाइल में जोड़ें:

source <(kubectl completion zsh)

यदि आपके पास kubectl के लिए एक उपनाम है, तो आप उस उपनाम के साथ काम करने के लिए शेल कम्पलीशन को बढ़ा सकते हैं:

echo 'alias k=kubectl' >>~/.zshrc
echo 'complete -F __start_kubectl k' >>~/.zshrc

अपने शेल को पुनः लोड करने के बाद, kubectl ऑटो-कम्पलीशन कार्य करना चाहिए।

यदि आपको कोई त्रुटि मिलती है जैसे complete:13: command not found: compdef, तो अपनी ~/.zshrc फ़ाइल की शुरुआत में निम्नलिखित जोड़ें:

autoload -Uz compinit
compinit

kubectl convert प्लगइन इंस्टॉल करें

कुबेरनेट्स कमांड-लाइन टूल kubectl के लिए एक प्लगइन, जो आपको विभिन्न API संस्करण के बीच मैनिफ़ेस्ट को बदलने करने की अनुमति देता है।यह विशेष रूप से नए कुबेरनेट्स रिलीज के साथ एक गैर-बहिष्कृत API संस्करण में मैनिफेस्ट को माइग्रेट करने में सहायक हो सकता है।अधिक जानकारी के लिए, गैर पदावनत एपिस में विस्थापित करें पर जाएं।

  1. इस कमांड से नवीनतम रिलीज डाउनलोड करें:

    
   curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert"
   

    
   curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert"

  2. बाइनरी को मान्य करें (वैकल्पिक)

    kubectl-convert चेकसम फ़ाइल डाउनलोड करें:

    
   curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert.sha256"
   

    
   curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert.sha256"

    चेकसम फ़ाइल से kubectl-convert बाइनरी को मान्य करें:

    echo "$(<kubectl-convert.sha256)  kubectl-convert" | shasum -a 256 --check

    यदि मान्य है, तो आउटपुट है:

    kubectl-convert: OK

    अगर चेक फेल हो जाता है, तो sha256 nonzero स्थिति के साथ बाहर निकलता है और इस आउटपुट के समान प्रिंट करता है:

    kubectl-convert: FAILED
shasum: WARNING: 1 computed checksum did NOT match

    टिप्पणी:

    बाइनरी और चेकसम का एक ही संस्करण डाउनलोड करें।

  3. Kubectl-कन्वर्ट बाइनरी को एक्सेक्यूट करने योग्य बनाएं

    chmod +x ./kubectl-convert

  4. kubectl-convert binary बाइनरी को अपने सिस्टम PATH के फ़ाइल स्थान पर ले जाएँ।

    sudo mv ./kubectl-convert /usr/local/bin/kubectl-convert
sudo chown root: /usr/local/bin/kubectl-convert

    टिप्पणी:

    सुनिश्चित करें कि /usr/local/bin आपके पाथ एनवायरनमेंट वेरिएबल में है।

  5. सत्यापित करें कि प्लगइन सफलतापूर्वक इंस्टॉल हो गया है

    kubectl convert --help

    यदि आपको कोई त्रुटि नहीं दिखाई देती है, तो इसका मतलब है कि प्लगइन सफलतापूर्वक इंस्टॉल हो गया है।

आगे क्या है

4.1.3 - Windows पर kubectl इंस्टॉल और सेटअप करें

शुरू करने से पहले

आप kubectl संस्करण का उपयोग करे जो आपके क्लस्टर के एक माइनर संस्करण भीतर हो। उदाहरण के लिए, v1.35 क्लाइंट v1.34, v1.35 और v1.36 कण्ट्रोल प्लेन के साथ कम्युनिकेट कर सकते हैं।kubectl के नए संस्करण का उपयोग करने से समस्या से बचत हो सकती है।

Windows पर kubectl इंस्टॉल करें

Windows पर kubectl संस्थापित करने के लिए निम्नलिखित विधियाँ मौजूद हैं:

Windows पर curl के माध्यम से kubectl बाइनरी इंस्टॉल करें

  1. latest release 1.35.0 डाउनलोड करें।

    या यदि आपके पास curl है, तो इस कमांड का उपयोग करें:

    curl -LO https://dl.k8s.io/release/v1.35.0/bin/windows/amd64/kubectl.exe

    टिप्पणी:

    नवीनतम स्थिर संस्करण का पता लगाने के लिए (जैसे, स्क्रिप्टिंग के लिए), https://dl.k8s.io/release/stable.txt पर एक नज़र डालें।

  2. बाइनरी को मान्य करें (वैकल्पिक)

    kubectl चेकसम फाइल डाउनलोड करें:

    curl -LO https://dl.k8s.io/v1.35.0/bin/windows/amd64/kubectl.exe.sha256

    चेकसम फ़ाइल से kubectl बाइनरी को मान्य करें:

    • मैन्युअल रूप से कमांड प्रॉम्प्ट का उपयोग करके CertUtil के आउटपुट की तुलना डाउनलोडेड चेकसम फ़ाइल से करें:

      CertUtil -hashfile kubectl.exe SHA256
type kubectl.exe.sha256

    • True या False परिणाम प्राप्त करने के लिए -eq ऑपरेटर का उपयोग करके सत्यापन को ऑटोमेट करने के लिए powershell का उपयोग करें:

       $(Get-FileHash -Algorithm SHA256 .\kubectl.exe).Hash -eq $(Get-Content .\kubectl.exe.sha256)

  3. अपने PATH में बाइनरी जोड़ें।

  4. यह सुनिश्चित करने के लिए परीक्षण करें कि kubectl संस्करण डाउनलोड के समान है:

    kubectl version --client

टिप्पणी:

Windows के लिए Docker Desktop kubectl का अपना संस्करण PATH में जोड़ता है।यदि आपने पहले Docker Desktop स्थापित किया है, तो आपको Docker Desktop इंस्टॉलर द्वारा जोड़े गए एक PATH से पहले अपनी PATH प्रविष्टि डालने की आवश्यकता हो सकती है या Docker Desktop के kubectl को हटा दें।

Chocolatey या Scoop का उपयोग करके Windows पर इंस्टॉल करें

  1. Windows पर kubectl इंस्टॉल करने के लिए आप या तो Chocolatey पैकेज मैनेजर अथवा Scoop कमांड-लाइन इंस्टॉलर का उपयोग कर सकते हैं।

    choco install kubernetes-cli


    scoop install kubectl

  2. यह सुनिश्चित करने के लिए परीक्षण करें कि आपके द्वारा इंस्टॉल किया गया संस्करण उप-टू-डेट है:

    kubectl version --client

  3. अपनी होम डायरेक्टरी पर जाएं:

    # यदि आप cmd.exe का प्रयोग कर रहे हैं, तो: cd %USERPROFILE%
cd ~

  4. .kube डायरेक्टरी बनाएं:

    mkdir .kube

  5. आपके द्वारा अभी बनाई गई .kube डायरेक्टरी में जाएं:

    cd .kube

  6. दूरस्थ कुबेरनेट्स क्लस्टर का उपयोग करने के लिए kubectl को कॉन्फ़िगर करें:

    New-Item config -type file

टिप्पणी:

अपनी पसंद के टेक्स्ट एडिटर जैसे नोटपैड का उपयोग कर कॉन्फिग फाइल को एडिट करें।

kubectl कॉन्फ़िगरेशन सत्यापित करें

kubectl को कुबेरनेट्स क्लस्टर को खोजने और एक्सेस करने के लिए, उसेक्यूबकॉन्फिग फाइल(kubeconfig) की आवश्यकता होती है,जो स्वचालित रूप से तब बनता है जब आपkube-up.sh का उपयोग करके क्लस्टर बनाते हैं या मिनीक्यूब क्लस्टर को सफलतापूर्वक डिप्लॉय करते हैं।डिफ़ॉल्ट रूप से, kubectl कॉन्फ़िगरेशन ~/.kube/config पर स्थित होता है।

जाँच करें कि क्लस्टर स्टेट प्राप्त करके kubectl को ठीक से कॉन्फ़िगर किया गया है:

kubectl cluster-info

यदि आपको एक URL प्रतिक्रिया दिखती हैं, तो kubectl आपके क्लस्टर तक पहुँचने के लिए सही ढंग से कॉन्फ़िगर हुआ है।

यदि आपको निम्नलिखित संदेश दिखाई देता है, तो kubectl ठीक से कॉन्फ़िगर नहीं हुआ है या कुबेरनेट्स क्लस्टर से कनेक्ट करने में सक्षम नहीं है।

The connection to the server <server-name:port> was refused - did you specify the right host or port?

उदाहरण के लिए, यदि आप अपने लैपटॉप (स्थानीय रूप से) पर कुबेरनेट्स क्लस्टर चलाना चाहते हैं, तो आपको पहले मिनीक्यूब (minikube) जैसे टूल को इंस्टॉल करना होगा और ऊपर बताए गए कमांड को फिर से चलाना होगा।

यदि kubectl cluster-info URL प्रतिक्रिया देता है, लेकिन आप अपने क्लस्टर को एक्सेस नहीं कर पा रहें हैं, तो यह जाँचने के लिए कि क्या यह ठीक से कॉन्फ़िगर किया गया है, इस कमांड का उपयोग करें:

kubectl cluster-info dump

वैकल्पिक kubectl कॉन्फ़िगरेशन और प्लगइन्स

शेल ऑटोकम्प्लेशन सक्षम करें

kubectl Bash और Zsh के लिए ऑटोकम्प्लेशन का सपोर्ट प्रदान करता है, जो आपको बहुत सारी टाइपिंग बचा सकता है।

नीचे Zsh के लिए ऑटोकम्प्लेशन स्थापित करने की प्रक्रियाएँ हैं, यदि आप इसे Windows पर चला रहे हैं।

Zsh के लिए kubectl कम्पलीशन स्क्रिप्ट kubectl completion zsh कमांड के साथ उत्पन्न की जा सकती है। आपके शेल में कम्पलीशन स्क्रिप्ट को सोर्स करने से kubectl ऑटो-कम्पलीशन सक्षम हो जाती है।

अपने सभी शेल सत्रों में ऐसा करने के लिए, निम्नलिखित को अपनी ~/.zshrc फ़ाइल में जोड़ें:

source <(kubectl completion zsh)

यदि आपके पास kubectl के लिए एक उपनाम है, तो आप उस उपनाम के साथ काम करने के लिए शेल कम्पलीशन को बढ़ा सकते हैं:

echo 'alias k=kubectl' >>~/.zshrc
echo 'complete -F __start_kubectl k' >>~/.zshrc

अपने शेल को पुनः लोड करने के बाद, kubectl ऑटो-कम्पलीशन कार्य करना चाहिए।

यदि आपको कोई त्रुटि मिलती है जैसे complete:13: command not found: compdef, तो अपनी ~/.zshrc फ़ाइल की शुरुआत में निम्नलिखित जोड़ें:

autoload -Uz compinit
compinit

इंस्टॉल kubectl convert प्लगइन

कुबेरनेट्स कमांड-लाइन टूल kubectl के लिए एक प्लगइन, जो आपको विभिन्न API संस्करण के बीच मैनिफ़ेस्ट को बदलने करने की अनुमति देता है।यह विशेष रूप से नए कुबेरनेट्स रिलीज के साथ एक गैर-बहिष्कृत API संस्करण में मैनिफेस्ट को माइग्रेट करने में सहायक हो सकता है।अधिक जानकारी के लिए, गैर पदावनत एपिस में विस्थापित करें पर जाएं।

  1. इस कमांड से नवीनतम रिलीज डाउनलोड करें:

    curl -LO https://dl.k8s.io/release/v1.35.0/bin/windows/amd64/kubectl-convert.exe

  2. बाइनरी को मान्य करें (वैकल्पिक)

    kubectl-convert चेकसम फ़ाइल डाउनलोड करें:

    curl -LO https://dl.k8s.io/v1.35.0/bin/windows/amd64/kubectl-convert.exe.sha256

    चेकसम फ़ाइल से kubectl-convert बाइनरी को मान्य करें:

    • मैन्युअल रूप से कमांड प्रॉम्प्ट का उपयोग करके CertUtil के आउटपुट की तुलना डाउनलोड किये गये चेकसम फ़ाइल से करें:

      CertUtil -hashfile kubectl-convert.exe SHA256
type kubectl-convert.exe.sha256

    • True या False परिणाम प्राप्त करने और -eq ऑपरेटर का उपयोग करके सत्यापन को ऑटोमेट करने के लिए Powershell का उपयोग करें:

      $($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256)

  3. अपने PATH में बाइनरी जोड़ें।

  4. सत्यापित करें कि प्लगइन सफलतापूर्वक इंस्टॉल हो गया है।

    kubectl convert --help

    यदि आपको कोई त्रुटि नहीं दिखाई देती है, तो इसका मतलब है कि प्लगइन सफलतापूर्वक इंस्टॉल हो गया है।

आगे क्या है

4.2 - कॉन्फ़िगरेशन फाइल का उपयोग करके सीक्रेट्स का प्रबंधन

रिसोर्स कॉन्फ़िगरेशन फाइल का उपयोग करके सीक्रेट ऑब्जेक्ट बनाना।

शुरू करने से पहले

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

सीक्रेट बनाएं

आप पहले JSON या YAML फॉर्मेट में एक मैनिफेस्ट में Secret ऑब्जेक्ट को परिभाषित कर सकते हैं, और फिर उस ऑब्जेक्ट को बना सकते हैं। Secret रिसोर्स में दो मैप्स होते हैं: data और stringData। data फील्ड का उपयोग मनमाना डेटा स्टोर करने के लिए किया जाता है, जो base64 का उपयोग करके एनकोड किया जाता है। stringData फील्ड सुविधा के लिए प्रदान किया जाता है, और यह आपको समान डेटा को अनएनकोडेड स्ट्रिंग्स के रूप में प्रदान करने की अनुमति देता है। data और stringData की कुंजियों में अल्फ़ान्यूमेरिक वर्ण, -, _ या . होने चाहिए।

निम्नलिखित उदाहरण data फील्ड का उपयोग करके एक सीक्रेट में दो स्ट्रिंग्स स्टोर करता है।

  1. स्ट्रिंग्स को base64 में कनवर्ट करें:

    echo -n 'admin' | base64
echo -n '1f2d1e2e67df' | base64

    टिप्पणी:

    सीक्रेट डेटा के सीरियलाइज्ड JSON और YAML वैल्यू base64 स्ट्रिंग्स के रूप में एनकोड किए जाते हैं। इन स्ट्रिंग्स के भीतर न्यूलाइन मान्य नहीं हैं और इन्हें छोड़ा जाना चाहिए। Darwin/macOS पर base64 यूटिलिटी का उपयोग करते समय, उपयोगकर्ताओं को लंबी लाइनों को विभाजित करने के लिए -b विकल्प का उपयोग करने से बचना चाहिए। इसके विपरीत, Linux उपयोगकर्ताओं को base64 कमांड में -w 0 विकल्प जोड़ना चाहिए या यदि -w विकल्प उपलब्ध नहीं है तो base64 | tr -d '\n' पाइपलाइन का उपयोग करना चाहिए।

    आउटपुट इस तरह का होता है:

    YWRtaW4=
MWYyZDFlMmU2N2Rm

  2. मैनिफेस्ट बनाएं:

    apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

    ध्यान दें कि एक सीक्रेट ऑब्जेक्ट का नाम एक मान्य DNS सबडोमेन नाम होना चाहिए।

  3. kubectl apply का उपयोग करके सीक्रेट बनाएं:

    kubectl apply -f ./secret.yaml

    आउटपुट इस तरह का होता है:

    secret/mysecret created

यह सत्यापित करने के लिए कि सीक्रेट बनाया गया था और सीक्रेट डेटा को डिकोड करने के लिए, kubectl का उपयोग करके सीक्रेट्स का प्रबंधन देखें।

सीक्रेट बनाते समय अनएनकोडेड डेटा निर्दिष्ट करें

कुछ परिदृश्यों के लिए, आप stringData फील्ड का उपयोग करना चाह सकते हैं। यह फील्ड आपको सीक्रेट में सीधे एक नॉन-base64 एनकोडेड स्ट्रिंग डालने की अनुमति देता है, और जब सीक्रेट बनाया या अपडेट किया जाता है तो स्ट्रिंग आपके लिए एनकोड की जाएगी।

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

उदाहरण के लिए, यदि आपका एप्लिकेशन निम्नलिखित कॉन्फ़िगरेशन फाइल का उपयोग करता है:

apiUrl: "https://my.api.com/api/v1"
username: "<user>"
password: "<password>"

आप इसे निम्नलिखित परिभाषा का उपयोग करके एक सीक्रेट में स्टोर कर सकते हैं:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
stringData:
  config.yaml: |
    apiUrl: "https://my.api.com/api/v1"
    username: <user>
    password: <password>

टिप्पणी:

सीक्रेट के लिए stringData फील्ड सर्वर-साइड एप्लाई के साथ अच्छी तरह से काम नहीं करता है।

जब आप सीक्रेट डेटा प्राप्त करते हैं, तो कमांड एनकोडेड वैल्यू वापस करता है, न कि वे प्लेनटेक्स्ट वैल्यू जो आपने stringData में प्रदान किए थे।

उदाहरण के लिए, यदि आप निम्नलिखित कमांड चलाते हैं:

kubectl get secret mysecret -o yaml

आउटपुट इस तरह का होता है:

apiVersion: v1
data:
  config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
kind: Secret
metadata:
  creationTimestamp: 2018-11-15T20:40:59Z
  name: mysecret
  namespace: default
  resourceVersion: "7225"
  uid: c280ad2e-e916-11e8-98f2-025000000001
type: Opaque

data और stringData दोनों निर्दिष्ट करें

यदि आप एक फील्ड को data और stringData दोनों में निर्दिष्ट करते हैं, तो stringData से वैल्यू का उपयोग किया जाता है।

उदाहरण के लिए, यदि आप निम्नलिखित सीक्रेट को परिभाषित करते हैं:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
stringData:
  username: administrator

टिप्पणी:

सीक्रेट के लिए stringData फील्ड सर्वर-साइड एप्लाई के साथ अच्छी तरह से काम नहीं करता है।

Secret ऑब्जेक्ट इस प्रकार बनाया जाता है:

apiVersion: v1
data:
  username: YWRtaW5pc3RyYXRvcg==
kind: Secret
metadata:
  creationTimestamp: 2018-11-15T20:46:46Z
  name: mysecret
  namespace: default
  resourceVersion: "7579"
  uid: 91460ecb-e917-11e8-98f2-025000000001
type: Opaque

YWRtaW5pc3RyYXRvcg== डिकोड होकर administrator बनता है।

सीक्रेट को संपादित करें

मैनिफेस्ट का उपयोग करके बनाए गए सीक्रेट में डेटा को संपादित करने के लिए, अपने मैनिफेस्ट में data या stringData फील्ड को संशोधित करें और फाइल को अपने क्लस्टर में लागू करें। आप एक मौजूदा Secret ऑब्जेक्ट को संपादित कर सकते हैं जब तक कि वह अपरिवर्तनीय नहीं है।

उदाहरण के लिए, यदि आप पिछले उदाहरण से पासवर्ड को birdsarentreal में बदलना चाहते हैं, तो निम्नलिखित करें:

  1. नई पासवर्ड स्ट्रिंग को एनकोड करें:

    echo -n 'birdsarentreal' | base64

    आउटपुट इस तरह का होता है:

    YmlyZHNhcmVudHJlYWw=

  2. अपनी नई पासवर्ड स्ट्रिंग के साथ data फील्ड को अपडेट करें:

    apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: YmlyZHNhcmVudHJlYWw=

  3. मैनिफेस्ट को अपने क्लस्टर में लागू करें:

    kubectl apply -f ./secret.yaml

    आउटपुट इस तरह का होता है:

    secret/mysecret configured

कुबेरनेट्स मौजूदा Secret ऑब्जेक्ट को अपडेट करता है। विस्तार से, kubectl टूल नोटिस करता है कि समान नाम का एक मौजूदा Secret ऑब्जेक्ट है। kubectl मौजूदा ऑब्जेक्ट को प्राप्त करता है, उसमें परिवर्तनों की योजना बनाता है, और बदले हुए Secret ऑब्जेक्ट को आपके क्लस्टर कंट्रोल प्लेन को सबमिट करता है।

यदि आपने इसके बजाय kubectl apply --server-side निर्दिष्ट किया है, तो kubectl सर्वर साइड एप्लाई का उपयोग करता है।

साफ़ करें

आपके द्वारा बनाए गए सीक्रेट को हटाने के लिए:

kubectl delete secret mysecret

आगे क्या है

4.3 - निर्भर एनवायरनमेंट वेरिएबल्स परिभाषित करें

यह पृष्ठ दिखाता है कि कुबेरनेट्स पॉड में किसी कंटेनर के लिए निर्भर एनवायरनमेंट वेरिएबल्स कैसे परिभाषित करें।

शुरू करने से पहले

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

कंटेनर के लिए एक निर्भर एनवायरनमेंट वेरिएबल परिभाषित करें

जब आप एक पॉड बनाते हैं, तो आप उसमें चलने वाले कंटेनरों के लिए निर्भर एनवायरनमेंट वेरिएबल्स सेट कर सकते हैं। निर्भर एनवायरनमेंट वेरिएबल्स सेट करने के लिए, आप कॉन्फ़िगरेशन फ़ाइल में env की value में $(VAR_NAME) का उपयोग कर सकते हैं।

इस अभ्यास में, आप एक ऐसा पॉड बनाएंगे जो एक कंटेनर चलाता है।
पॉड के लिए कॉन्फ़िगरेशन फ़ाइल में एक निर्भर एनवायरनमेंट वेरिएबल्स परिभाषित किया गया है, जिसका सामान्य उपयोग निर्धारित किया गया है।पॉड के लिए कॉन्फ़िगरेशन मैनिफेस्ट इस प्रकार है:

pods/inject/dependent-envars.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: dependent-envars-demo
spec:
  containers:
    - name: dependent-envars-demo
      args:
        - while true; do echo -en '\n'; printf UNCHANGED_REFERENCE=$UNCHANGED_REFERENCE'\n'; printf SERVICE_ADDRESS=$SERVICE_ADDRESS'\n';printf ESCAPED_REFERENCE=$ESCAPED_REFERENCE'\n'; sleep 30; done;
      command:
        - sh
        - -c
      image: busybox:1.28
      env:
        - name: SERVICE_PORT
          value: "80"
        - name: SERVICE_IP
          value: "172.17.0.1"
        - name: UNCHANGED_REFERENCE
          value: "$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"
        - name: PROTOCOL
          value: "https"
        - name: SERVICE_ADDRESS
          value: "$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"
        - name: ESCAPED_REFERENCE
          value: "$$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)"

  1. उस मैनिफेस्ट के आधार पर एक पॉड बनाएँ:

    kubectl apply -f https://k8s.io/examples/pods/inject/dependent-envars.yaml

    pod/dependent-envars-demo created

  2. चल रहे पॉड्स की सूची देखें:

    kubectl get pods dependent-envars-demo

    NAME                      READY     STATUS    RESTARTS   AGE
dependent-envars-demo     1/1       Running   0          9s

  3. अपने पॉड में चल रहे कंटेनर के लॉग्स देखें:

    kubectl logs pod/dependent-envars-demo

    
UNCHANGED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
SERVICE_ADDRESS=https://172.17.0.1:80
ESCAPED_REFERENCE=$(PROTOCOL)://172.17.0.1:80

जैसा कि ऊपर दिखाया गया है, आपने SERVICE_ADDRESS के लिए एक सही डिपेंडेंसी रेफरेंस,UNCHANGED_REFERENCE के लिए एक गलत डिपेंडेंसी रेफरेंस, और ESCAPED_REFERENCE के लिए एक स्किप किया गया रेफरेंस परिभाषित किया है।

जब कोई एनवायरनमेंट वेरिएबल पहले से परिभाषित होता है और उसका रेफरेंस दिया जाता है,तो वह रेफरेंस सही तरीके से हल हो सकता है, जैसा कि SERVICE_ADDRESS के मामले में हुआ।

ध्यान दें कि env सूची में क्रम महत्वपूर्ण होता है।अगर कोई वेरिएबल सूची में नीचे परिभाषित है, तो उसे परिभाषित नहीं माना जाता।इसी कारण से UNCHANGED_REFERENCE $(PROTOCOL) को हल करने में विफल रहता है।

जब कोई एनवायरनमेंट वेरिएबल परिभाषित नहीं होता या उसमें कुछ वेरिएबल्स ही शामिल होते हैं,तो वह वेरिएबल एक सामान्य स्ट्रिंग की तरह माना जाता है, जैसे कि UNCHANGED_REFERENCE। ध्यान दें कि सामान्यतः गलत तरीके से पार्स किए गए एनवायरनमेंट वेरिएबल्स कंटेनर को शुरू होने से नहीं रोकते।

$(VAR_NAME) सिंटैक्स को डबल $, जैसे $$(VAR_NAME) से एस्केप किया जा सकता है।एस्केप किए गए रेफरेंस कभी भी विस्तारित नहीं होते, चाहे संबंधित वेरिएबल परिभाषित हो या नहीं।यह ESCAPED_REFERENCE उदाहरण में देखा जा सकता है।

आगे क्या है

4.4 - Windows Pods और Containers के लिए RunAsUserName कॉन्फ़िगर करें

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

यह पेज दिखाता है कि Windows nodes पर चलने वाले Pods और containers के लिएrunAsUserName सेटिंग का उपयोग कैसे करें। यह लगभग Linux-विशिष्ट runAsUser सेटिंग के समकक्ष है, जिससे आप container में applications को default username से अलग username पर चला सकते हैं।

शुरू करने से पहले

आपके पास Kubernetes cluster होना चाहिए और kubectl command-line tool आपके cluster से communicate करने के लिए configured होना चाहिए। cluster में Windows worker nodes होने चाहिए,जहाँ Windows workloads चलाने वाले containers वाले pods schedule किए जा सकें।

Pod के लिए Username सेट करें

Pod के container processes किस username से execute हों, यह बताने के लिए Pod specification मेंsecurityContext field (PodSecurityContext)शामिल करें, और उसके अंदर windowsOptions (WindowsSecurityContextOptions)field में runAsUserName field दें।

Pod के लिए जो Windows security context options आप specify करते हैं, वे Pod के सभी Containers और init Containers पर लागू होते हैं।

यहाँ Windows Pod की configuration file है जिसमें runAsUserName field सेट है:

windows/run-as-username-pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: run-as-username-pod-demo
spec:
  securityContext:
    windowsOptions:
      runAsUserName: "ContainerUser"
  containers:
  - name: run-as-username-demo
    image: mcr.microsoft.com/windows/servercore:ltsc2019
    command: ["ping", "-t", "localhost"]
  nodeSelector:
    kubernetes.io/os: windows

Pod बनाएं:

kubectl apply -f https://k8s.io/examples/windows/run-as-username-pod.yaml

जांचें कि Pod का Container चल रहा है:

kubectl get pod run-as-username-pod-demo

चल रहे Container में shell खोलें:

kubectl exec -it run-as-username-pod-demo -- powershell

जांचें कि shell सही username के रूप में चल रही है:

echo $env:USERNAME

आउटपुट यह होना चाहिए:

ContainerUser

Container के लिए Username सेट करें

Container के processes किस username से execute हों, यह बताने के लिए Container manifest मेंsecurityContext field (SecurityContext)शामिल करें, और उसके अंदर windowsOptions (WindowsSecurityContextOptions)field में runAsUserName field दें।

Container के लिए जो Windows security context options आप specify करते हैं, वे केवल उसी Container पर लागू होते हैं, और Pod level पर की गई settings को override करते हैं।

यहाँ Pod की configuration file है जिसमें एक Container है, और runAsUserName field Pod level तथा Container level दोनों पर सेट है:

windows/run-as-username-container.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: run-as-username-container-demo
spec:
  securityContext:
    windowsOptions:
      runAsUserName: "ContainerUser"
  containers:
  - name: run-as-username-demo
    image: mcr.microsoft.com/windows/servercore:ltsc2019
    command: ["ping", "-t", "localhost"]
    securityContext:
        windowsOptions:
            runAsUserName: "ContainerAdministrator"
  nodeSelector:
    kubernetes.io/os: windows

Pod बनाएं:

kubectl apply -f https://k8s.io/examples/windows/run-as-username-container.yaml

जांचें कि Pod का Container चल रहा है:

kubectl get pod run-as-username-container-demo

चल रहे Container में shell खोलें:

kubectl exec -it run-as-username-container-demo -- powershell

जांचें कि shell सही username के रूप में चल रही है (यानी वही जो Container level पर सेट है):

echo $env:USERNAME

आउटपुट यह होना चाहिए:

ContainerAdministrator

Windows Username सीमाएँ

इस feature का उपयोग करने के लिए runAsUserName field में दिया गया मान एक वैध username होना चाहिए।यह format DOMAIN\USER में होना चाहिए, जहाँ DOMAIN\ वैकल्पिक है। Windows usernames case insensitive होते हैं।इसके अलावा DOMAIN और USER के संबंध में कुछ प्रतिबंध हैं:

  • runAsUserName field खाली नहीं हो सकती और इसमें control characters (ASCII values: 0x00-0x1F, 0x7F) नहीं होने चाहिए।
  • DOMAIN या तो NetBios नाम होना चाहिए या DNS नाम, और दोनों पर अलग-अलग सीमाएँ लागू होती हैं:
    • NetBios names: अधिकतम 15 characters, . (dot) से शुरू नहीं होना चाहिए, और इन characters को शामिल नहीं कर सकता: \ / : * ? " < > |
    • DNS names: अधिकतम 255 characters, केवल alphanumeric characters, dots और dashes शामिल हों, और . (dot) या - (dash) से शुरू/समाप्त न हो।
  • USER अधिकतम 20 characters का होना चाहिए, केवल dots या spaces से बना नहीं होना चाहिए, और इनमें से कोई character शामिल नहीं होना चाहिए: " / \ [ ] : ; | = , + * ? < > @।

runAsUserName field के स्वीकार्य मानों के उदाहरण:ContainerAdministrator, ContainerUser, NT AUTHORITY\NETWORK SERVICE, NT AUTHORITY\LOCAL SERVICE।

इन सीमाओं के बारे में अधिक जानकारी के लिए here और here देखें।

आगे क्या है

4.5 - नेटवर्क पॉलिसी प्रोवाइडर इंस्टॉल करें

4.5.1 - नेटवर्कपॉलिसी के लिए Antrea का उपयोग करें

यह पेज कुबेरनेट्स पर Antrea CNI प्लगइन को कैसे इंस्टॉल और उपयोग करें, यह दिखाता है।प्रोजेक्ट Antrea की पृष्ठभूमि के लिए, Antrea का परिचय पढ़ें।

शुरू करने से पहले

आपके पास एक कुबेरनेट्स क्लस्टर होना चाहिए। एक क्लस्टर को बूटस्ट्रैप करने के लिएkubeadm आरंभ करने की गाइड का पालन करें।

kubeadm के साथ Antrea को डिप्लॉय करना

kubeadm के लिए Antrea को डिप्लॉय करने के लिए आरंभ करने की गाइड का पालन करें।

आगे क्या है

एक बार जब आपका क्लस्टर चल रहा हो, तो आप कुबेरनेट्स नेटवर्कपॉलिसी को आज़माने के लिए नेटवर्क पॉलिसी घोषित करें का पालन कर सकते हैं।

4.5.2 - नेटवर्कपॉलिसी के लिए Calico का उपयोग करें

यह पेज कुबेरनेट्स पर Calico क्लस्टर बनाने के कुछ त्वरित तरीके दिखाता है।

शुरू करने से पहले

तय करें कि आप cloud या local क्लस्टर डिप्लॉय करना चाहते हैं।

Google कुबेरनेट्स इंजन (GKE) के साथ Calico क्लस्टर बनाना

पूर्वापेक्षा: gcloud।

  1. Calico के साथ GKE क्लस्टर लॉन्च करने के लिए, --enable-network-policy फ्लैग शामिल करें।

    सिंटैक्स

    gcloud container clusters create [CLUSTER_NAME] --enable-network-policy

    उदाहरण

    gcloud container clusters create my-calico-cluster --enable-network-policy

  2. डिप्लॉयमेंट को सत्यापित करने के लिए, निम्नलिखित कमांड का उपयोग करें।

    kubectl get pods --namespace=kube-system

    Calico पॉड्स calico से शुरू होते हैं। जांचें कि प्रत्येक की स्थिति Running है।

kubeadm के साथ लोकल Calico क्लस्टर बनाना

kubeadm का उपयोग करके पंद्रह मिनट में एक लोकल सिंगल-होस्ट Calico क्लस्टर प्राप्त करने के लिए,Calico क्विकस्टार्ट देखें।

आगे क्या है

एक बार जब आपका क्लस्टर चल रहा हो, तो आप कुबेरनेट्स नेटवर्कपॉलिसी को आज़माने के लिए नेटवर्क पॉलिसी घोषित करें का पालन कर सकते हैं।

4.6 - Storage के लिए Volume उपयोग करने हेतु Pod कॉन्फ़िगर करें

यह पेज दिखाता है कि storage के लिए Volume उपयोग करने हेतु Pod को कैसे कॉन्फ़िगर करें।

किसी Container का file system केवल उतनी देर तक रहता है जितनी देर Container रहता है।इसलिए जब कोई Container terminate होकर फिर restart होता है, तो filesystem में किए गए बदलाव खो जाते हैं।Container से स्वतंत्र और अधिक consistent storage के लिए आपVolume का उपयोग कर सकते हैं।यह stateful applications (जैसे key-value stores, उदाहरण के लिए Redis, और databases) के लिए विशेष रूप से महत्वपूर्ण है।

शुरू करने से पहले

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

संस्करण की जांच करने के लिए, लिखें kubectl version.

Pod के लिए volume कॉन्फ़िगर करें

इस अभ्यास में आप ऐसा Pod बनाते हैं जिसमें एक Container चलता है। इस Pod मेंemptyDir प्रकार का Volume होता है जो Pod के जीवनकाल तक बना रहता है, भले ही Container terminate होकर restart हो जाए।यह Pod की configuration file है:

pods/storage/redis.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: redis
    volumeMounts:
    - name: redis-storage
      mountPath: /data/redis
  volumes:
  - name: redis-storage
    emptyDir: {}

  1. Pod बनाएं:

    kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml

  2. जांचें कि Pod का Container चल रहा है, और फिर Pod में होने वाले बदलाव देखें:

    kubectl get pod redis --watch

    आउटपुट इस तरह दिखेगा:

    NAME      READY     STATUS    RESTARTS   AGE
redis     1/1       Running   0          13s

  3. दूसरे terminal में, चल रहे Container का shell खोलें:

    kubectl exec -it redis -- /bin/bash

  4. अपनी shell में /data/redis पर जाएँ, और फिर एक फ़ाइल बनाएं:

    root@redis:/data# cd /data/redis/
root@redis:/data/redis# echo Hello > test-file

  5. अपनी shell में चल रही processes की सूची देखें:

    root@redis:/data/redis# apt-get update
root@redis:/data/redis# apt-get install procps
root@redis:/data/redis# ps aux

    आउटपुट इस तरह होगा:

    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
redis        1  0.1  0.1  33308  3828 ?        Ssl  00:46   0:00 redis-server *:6379
root        12  0.0  0.0  20228  3020 ?        Ss   00:47   0:00 /bin/bash
root        15  0.0  0.0  17500  2072 ?        R+   00:48   0:00 ps aux

  6. अपनी shell में Redis process को kill करें:

    root@redis:/data/redis# kill <pid>

    जहाँ <pid> Redis process ID (PID) है।

  7. अपने मूल terminal में Redis Pod में होने वाले बदलाव देखें। अंततः आपको कुछ ऐसा दिखाई देगा:

    NAME      READY     STATUS     RESTARTS   AGE
redis     1/1       Running    0          13s
redis     0/1       Completed  0         6m
redis     1/1       Running    1         6m

इस बिंदु पर Container terminate होकर restart हो चुका है। ऐसा इसलिए है क्योंकि Redis Pod कीrestartPolicy Always है।

  1. restarted Container के अंदर shell खोलें:

    kubectl exec -it redis -- /bin/bash

  2. अपनी shell में /data/redis पर जाएँ, और सत्यापित करें कि test-file अभी भी मौजूद है।

    root@redis:/data/redis# cd /data/redis/
root@redis:/data/redis# ls
test-file

  3. इस अभ्यास के लिए बनाया गया Pod हटाएं:

    kubectl delete pod redis

आगे क्या है

  • Volume देखें।

  • Pod देखें।

  • emptyDir द्वारा दिए गए local disk storage के अलावा, Kubernetes कई प्रकार के network-attached storage solutions को सपोर्ट करता है, जिनमें GCE पर PD और EC2 पर EBS शामिल हैं।ये critical data के लिए अधिक उपयुक्त हैं और nodes पर devices को mount/unmount करने जैसे विवरण संभालते हैं। अधिक जानकारी के लिएVolumes देखें।

4.7 - Storage के लिए Projected Volume उपयोग करने हेतु Pod कॉन्फ़िगर करें

यह पेज दिखाता है कि एक ही directory में कई मौजूदा volume sources को mount करने के लिएprojected Volume का उपयोग कैसे करें।वर्तमान में secret, configMap, downwardAPI और serviceAccountToken volumes को project किया जा सकता है।

टिप्पणी:

serviceAccountToken कोई volume type नहीं है।

शुरू करने से पहले

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

संस्करण की जांच करने के लिए, लिखें kubectl version.

Pod के लिए projected volume कॉन्फ़िगर करें

इस अभ्यास में आप local files से username और password वाले Secrets बनाते हैं।फिर आप एक ऐसा Pod बनाते हैं जिसमें एक container चलता है, और projected Volume का उपयोग करके Secrets को उसी shared directory में mount किया जाता है।

यह Pod की configuration file है:

pods/storage/projected.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: test-projected-volume
spec:
  containers:
  - name: test-projected-volume
    image: busybox:1.28
    args:
    - sleep
    - "86400"
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: user
      - secret:
          name: pass

  1. Secrets बनाएं:

    # Create files containing the username and password:
echo -n "admin" > ./username.txt
echo -n "1f2d1e2e67df" > ./password.txt

# Package these files into secrets:
kubectl create secret generic user --from-file=./username.txt
kubectl create secret generic pass --from-file=./password.txt

  2. Pod बनाएं:

    kubectl apply -f https://k8s.io/examples/pods/storage/projected.yaml

  3. जांचें कि Pod का container चल रहा है, और फिर Pod में होने वाले बदलाव देखें:

    kubectl get --watch pod test-projected-volume

    आउटपुट इस तरह दिखेगा:

    NAME                    READY     STATUS    RESTARTS   AGE
test-projected-volume   1/1       Running   0          14s

  4. दूसरे terminal में, चल रहे container का shell खोलें:

    kubectl exec -it test-projected-volume -- /bin/sh

  5. अपनी shell में, जांचें कि projected-volume directory में आपके projected sources मौजूद हैं:

    ls /projected-volume/

साफ़-सफ़ाई

Pod और Secrets हटाएँ:

kubectl delete pod test-projected-volume
kubectl delete secret user pass

आगे क्या है

4.8 - Pods के लिए Service Accounts कॉन्फ़िगर करें

Kubernetes उन clients के लिए, जो आपके cluster के भीतर चलते हैं या जिनका आपके cluster के control plane से किसी प्रकार का संबंध होता है, authentication के दो अलग तरीके प्रदान करता है ताकि वे API server से प्रमाणित हो सकें।

एक service account Pod में चलने वाली processes के लिए identity प्रदान करता है,और यह ServiceAccount object से map होता है। जब आप API server से authenticate करते हैं,तो आप स्वयं को एक विशेष user के रूप में पहचानते हैं। Kubernetes user की अवधारणा को पहचानता है,लेकिन स्वयं Kubernetes में User API नहीं है।

यह task guide ServiceAccounts के बारे में है, जो Kubernetes API में मौजूद हैं।यह guide आपको Pods के लिए ServiceAccounts कॉन्फ़िगर करने के कुछ तरीके दिखाती है।

शुरू करने से पहले

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

API server तक पहुँचने के लिए default service account का उपयोग करें

जब Pods API server से संपर्क करते हैं, तो वे किसी विशेष ServiceAccount(उदाहरण के लिए default) के रूप में authenticate करते हैं।हर namespace में हमेशा कम से कम एक ServiceAccount होता है।

हर Kubernetes namespace में कम से कम एक ServiceAccount होता है:उस namespace का default ServiceAccount, जिसका नाम default होता है।अगर आप Pod बनाते समय ServiceAccount specify नहीं करते,तो Kubernetes उस namespace का default ServiceAccount अपने-आप असाइन कर देता है।

आप अपने बनाए Pod का विवरण प्राप्त कर सकते हैं। उदाहरण के लिए:

kubectl get pods/<podname> -o yaml

आउटपुट में आपको spec.serviceAccountName field दिखाई देगी।अगर Pod बनाते समय आप यह मान सेट नहीं करते, तो Kubernetes इसे अपने-आप सेट करता है।

Pod के अंदर चल रहा application, automatically mounted service account credentials का उपयोग करके Kubernetes API तक पहुँच सकता है।अधिक जानने के लिए accessing the Cluster देखें।

जब Pod, ServiceAccount के रूप में authenticate करता है, तो उसका access level उपयोग में मौजूद authorization plugin and policy पर निर्भर करता है।

Pod delete होने पर API credentials अपने-आप revoke हो जाते हैं, भले ही finalizers लगे हों। विशेष रूप से, Pod पर .metadata.deletionTimestamp सेट होने के 60 seconds बाद API credentials revoke हो जाते हैं (deletion timestamp आमतौर पर वह समय होता है जब delete request स्वीकार की गई, plus Pod का termination grace period)।

API credential automounting से बाहर निकलें

अगर आप नहीं चाहते कि kubelet ServiceAccount की API credentials अपने-आप mount करे, तो आप default behavior से बाहर निकल सकते हैं।आप service account पर automountServiceAccountToken: false सेट करके/var/run/secrets/kubernetes.io/serviceaccount/token पर API credentials की automounting बंद कर सकते हैं:

उदाहरण के लिए:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-robot
automountServiceAccountToken: false
...

आप किसी विशेष Pod के लिए भी API credentials की automounting बंद कर सकते हैं:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: build-robot
  automountServiceAccountToken: false
  ...

यदि ServiceAccount और Pod की .spec दोनों मेंautomountServiceAccountToken का मान दिया गया है, तो Pod spec को प्राथमिकता मिलती है।

एक से अधिक ServiceAccount का उपयोग करें

हर namespace में कम से कम एक ServiceAccount होता है: default ServiceAccount resource, जिसका नाम default है। आपवर्तमान namespace में सभी ServiceAccount resources की सूची इस तरह देख सकते हैं:

kubectl get serviceaccounts

आउटपुट इस प्रकार होगा:

NAME      SECRETS    AGE
default   1          1d

आप अतिरिक्त ServiceAccount objects इस तरह बना सकते हैं:

kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-robot
EOF

ServiceAccount object का नाम एक वैधDNS subdomain name होना चाहिए।

अगर आप service account object का पूरा dump ऐसे लेते हैं:

kubectl get serviceaccounts/build-robot -o yaml

तो आउटपुट इस तरह होगा:

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: 2019-06-16T00:12:34Z
  name: build-robot
  namespace: default
  resourceVersion: "272500"
  uid: 721ab723-13bc-11e5-aec2-42010af0021e

आप authorization plugins का उपयोग करकेservice accounts पर permissions सेट कर सकते हैं।

non-default service account का उपयोग करने के लिए Pod के spec.serviceAccountName field में उस ServiceAccount का नाम सेट करें जिसे आप उपयोग करना चाहते हैं।

आप serviceAccountName field केवल Pod बनाते समय या नए Pod के template में ही सेट कर सकते हैं।पहले से मौजूद Pod की .spec.serviceAccountName field अपडेट नहीं की जा सकती।

टिप्पणी:

.spec.serviceAccount field, .spec.serviceAccountName का deprecated alias है।अगर आप workload resource से fields हटाना चाहते हैं, तो pod template पर दोनों fields को स्पष्ट रूप से empty सेट करें।

साफ़-सफ़ाई

अगर आपने ऊपर के उदाहरण से build-robot ServiceAccount बनाया है,तो इसे हटाने के लिए यह चलाएँ:

kubectl delete serviceaccount/build-robot

ServiceAccount के लिए API token manually बनाएं

मान लीजिए आपके पास पहले बताए अनुसार "build-robot" नाम का service account मौजूद है।

आप kubectl से उस ServiceAccount के लिए time-limited API token प्राप्त कर सकते हैं:

kubectl create token build-robot

इस command का आउटपुट एक token होता है, जिससे आप उस ServiceAccount के रूप में authenticate कर सकते हैं। आप kubectl create token में--duration command line argument देकर token की विशेष duration मांग सकते हैं(हालांकि वास्तविक issued token duration छोटी भी हो सकती है या कभी-कभी लंबी भी)।

फ़ीचर स्थिति: Kubernetes v1.33 [stable](enabled by default)

kubectl v1.31 या बाद के version में आप ऐसा service account token बना सकते हैं जो सीधे किसी Node से bound हो:

kubectl create token build-robot --bound-object-kind Node --bound-object-name node-001 --bound-object-uid 123...456

token तब तक वैध रहेगा जब तक वह expire न हो जाए, या उससे संबंधित Node या service account delete न हो जाए।

टिप्पणी:

Kubernetes v1.22 से पहले के versions Kubernetes API access करने के लिए long term credentials स्वतः बनाते थे। यह पुराना तरीका token Secrets बनाने पर आधारित था जिन्हें फिर running Pods में mount किया जा सकता था।अधिक नए versions में, जिनमें Kubernetes v1.35 भी शामिल है, API credentials सीधेTokenRequest API के जरिए प्राप्त की जाती हैं,और इन्हें Pods मेंprojected volume (प्रोजेक्टेड वॉल्यूम) के जरिए mount किया जाता है।इस तरीके से प्राप्त tokens की सीमित lifetime होती है, और जिस Pod में वे mount हैं उसके delete होने पर वे स्वतः invalid हो जाते हैं।

आप फिर भी manually service account token Secret बना सकते हैं; उदाहरण के लिए अगर आपको ऐसा token चाहिए जो कभी expire न हो। हालांकि API access के लिए token लेने का recommended तरीका TokenRequest subresource ही है।

ServiceAccount के लिए manually long-lived API token बनाएं

अगर आप ServiceAccount के लिए API token लेना चाहते हैं, तो आपको एक नई Secret बनानी होगी जिसमें special annotation kubernetes.io/service-account.name हो।

kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: build-robot-secret
  annotations:
    kubernetes.io/service-account.name: build-robot
type: kubernetes.io/service-account-token
EOF

अगर आप Secret को इस तरह देखें:

kubectl get secret/build-robot-secret -o yaml

तो आप देखेंगे कि अब इस Secret में "build-robot" ServiceAccount के लिए API token मौजूद है।

आपके द्वारा सेट annotation की वजह से control plane उस ServiceAccount के लिए अपने-आप token बनाता है और उसे संबंधित Secret में store करता है। control plane delete किए गए ServiceAccounts के tokens भी साफ करता है।

kubectl describe secrets/build-robot-secret

आउटपुट इस तरह होगा:

Name:           build-robot-secret
Namespace:      default
Labels:         <none>
Annotations:    kubernetes.io/service-account.name: build-robot
                kubernetes.io/service-account.uid: da68f9c6-9d26-11e7-b84e-002dc52800da

Type:   kubernetes.io/service-account-token

Data
====
ca.crt:         1338 bytes
namespace:      7 bytes
token:          ...

टिप्पणी:

यहाँ token की सामग्री छोड़ी गई है।

ध्यान रखें कि kubernetes.io/service-account-token Secret की सामग्री ऐसी जगह display न करें जहाँ कोई अन्य व्यक्ति आपकी terminal/computer screen देख सके।

जब आप associated Secret वाले ServiceAccount को delete करते हैं, तो Kubernetes control plane उस Secret से long-lived token अपने-आप साफ कर देता है।

टिप्पणी:

अगर आप ServiceAccount को इस तरह देखते हैं:

kubectl get serviceaccount build-robot -o yaml

तो ServiceAccount API object के.secrets field में आपको build-robot-secret Secret नहीं दिखेगी, क्योंकि वह field केवल auto-generated Secrets से भरी जाती है।

Service account में ImagePullSecrets जोड़ें

पहले, imagePullSecret बनाएं।फिर जांचें कि वह बन चुकी है। उदाहरण के लिए:

  • imagePullSecret बनाएं, जैसा किSpecifying ImagePullSecrets on a Pod में बताया गया है।

    kubectl create secret docker-registry myregistrykey --docker-server=<registry name> \
        --docker-username=DUMMY_USERNAME --docker-password=DUMMY_DOCKER_PASSWORD \
        --docker-email=DUMMY_DOCKER_EMAIL

  • जांचें कि यह बन चुकी है।

    kubectl get secrets myregistrykey

    आउटपुट इस तरह होगा:

    NAME             TYPE                              DATA    AGE
myregistrykey    kubernetes.io/.dockerconfigjson   1       1d

Service account में image pull secret जोड़ें

अब namespace के default service account को modify करें ताकि वह इस Secret को imagePullSecret के रूप में उपयोग करे।

kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'

आप object को manually edit करके भी यही परिणाम पा सकते हैं:

kubectl edit serviceaccount/default

sa.yaml file का आउटपुट कुछ ऐसा होगा:

आपके चुने हुए text editor में कुछ इस तरह की configuration खुलेगी:

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: 2021-07-07T22:02:39Z
  name: default
  namespace: default
  resourceVersion: "243024"
  uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6

अपने editor का उपयोग करके resourceVersion key वाली line हटाएँ, imagePullSecrets: के लिए lines जोड़ें और save करें। uid value को उसी तरह रहने दें जैसा मिला था।

इन बदलावों के बाद edited ServiceAccount कुछ ऐसा दिखेगा:

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: 2021-07-07T22:02:39Z
  name: default
  namespace: default
  uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
imagePullSecrets:
  - name: myregistrykey

सत्यापित करें कि नए Pods के लिए imagePullSecrets सेट हैं

अब जब current namespace में default ServiceAccount का उपयोग करते हुए नया Pod बनाया जाएगा,तो नए Pod की spec.imagePullSecrets field अपने-आप सेट होगी:

kubectl run nginx --image=<registry name>/nginx --restart=Never
kubectl get pod nginx -o=jsonpath='{.spec.imagePullSecrets[0].name}{"\n"}'

आउटपुट:

myregistrykey

ServiceAccount token वॉल्यूम प्रोजेक्शन

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

टिप्पणी:

token request projection को enable और उपयोग करने के लिए, आपको kube-apiserver में निम्न command line arguments specify करने होंगे:

--service-account-issuer
service account token issuer का Identifier परिभाषित करता है। आप--service-account-issuer argument कई बार दे सकते हैं; यह issuer को बिना बाधा बदलेने के लिए उपयोगी हो सकता है।जब यह flag कई बार दिया जाता है, तो पहला token generate करने के लिए उपयोग होता है और सभी values accepted issuers तय करने के लिए उपयोग होती हैं। --service-account-issuer को कई बार specify करने के लिए Kubernetes v1.22 या बाद का version आवश्यक है।
--service-account-key-file
PEM-encoded X.509 private/public keys (RSA या ECDSA) वाली फ़ाइल का path बताता है,जो ServiceAccount tokens verify करने के लिए उपयोग होती हैं। इस फ़ाइल में कई keys हो सकती हैं और यह flag अलग-अलग files के साथ कई बार दिया जा सकता है।यदि कई बार दिया जाए, तो किसी भी निर्दिष्ट key से signed tokens को Kubernetes API server वैध मानता है।
--service-account-signing-key-file
उस फ़ाइल का path बताता है जिसमें service account token issuer की वर्तमान private key होती है।issuer इसी private key से ID tokens sign करता है।
--api-audiences (छोड़ा जा सकता है)
ServiceAccount tokens के audiences परिभाषित करता है। service account token authenticator verify करता है कि API के विरुद्ध उपयोग हो रहे tokens इनमें से कम से कम एक audience से bound हों।यदि api-audiences कई बार दिया जाए, तो किसी भी निर्दिष्ट audience के tokens Kubernetes API server द्वारा वैध माने जाते हैं।यदि आप --service-account-issuer सेट करते हैं लेकिन --api-audiences नहीं सेट करते,तो control plane default रूप से एक single-element audience list उपयोग करता है जिसमें केवल issuer URL होता है।

kubelet ServiceAccount token को Pod में project भी कर सकता है। आप token की वांछित properties (जैसे audience और validity duration) specify कर सकते हैं।ये properties default ServiceAccount token पर configurable नहीं होतीं।Pod या ServiceAccount में से किसी एक के delete होने पर token API के लिए invalid हो जाएगा।

Pod की spec में आप यह behaviorprojected volume (प्रोजेक्टेड वॉल्यूम) typeServiceAccountToken का उपयोग करके कॉन्फ़िगर कर सकते हैं।

इस projected volume का token एक JSON Web Token (JWT) होता है।इस token का JSON payload एक well-defined schema का पालन करता है। Pod-bound token का उदाहरण payload:

{
  "aud": [  # matches the requested audiences, or the API server's default audiences when none are explicitly requested
    "https://kubernetes.default.svc"
  ],
  "exp": 1731613413,
  "iat": 1700077413,
  "iss": "https://kubernetes.default.svc",  # matches the first value passed to the --service-account-issuer flag
  "jti": "ea28ed49-2e11-4280-9ec5-bc3d1d84661a", 
  "kubernetes.io": {
    "namespace": "kube-system",
    "node": {
      "name": "127.0.0.1",
      "uid": "58456cb0-dd00-45ed-b797-5578fdceaced"
    },
    "pod": {
      "name": "coredns-69cbfb9798-jv9gn",
      "uid": "778a530c-b3f4-47c0-9cd5-ab018fb64f33"
    },
    "serviceaccount": {
      "name": "coredns",
      "uid": "a087d5a0-e1dd-43ec-93ac-f13d89cd13af"
    },
    "warnafter": 1700081020
  },
  "nbf": 1700077413,
  "sub": "system:serviceaccount:kube-system:coredns"
}

Service account token projection का उपयोग करते हुए Pod लॉन्च करें

Pod को vault audience और दो घंटे की validity duration वाला token देने के लिए आप ऐसा Pod manifest define कर सकते हैं:

pods/pod-projected-svc-token.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /var/run/secrets/tokens
      name: vault-token
  serviceAccountName: build-robot
  volumes:
  - name: vault-token
    projected:
      sources:
      - serviceAccountToken:
          path: vault-token
          expirationSeconds: 7200
          audience: vault

Pod बनाएं:

kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml

kubelet यह करेगा: Pod की ओर से token request और store करेगा;token को Pod में configurable file path पर उपलब्ध कराएगा;और expiration के करीब आते ही token refresh करेगा।यदि token अपनी कुल time-to-live (TTL) का 80% से पुराना हो जाए,या token 24 घंटे से पुराना हो, तो kubelet proactively rotation request करता है।

token rotate होने पर application को token reload करना जिम्मेदारी है।अक्सर application के लिए token को schedule पर reload करना पर्याप्त होता है(उदाहरण: हर 5 मिनट), बिना वास्तविक expiry time track किए।

Service account issuer डिस्कवरी

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

यदि आपने अपने cluster में ServiceAccounts के लिएtoken projection enable किया है,तो आप discovery feature भी उपयोग कर सकते हैं। Kubernetes clients कोidentity provider की तरह federate करने का तरीका देता है, ताकि एक या अधिक external systems relying party की तरह काम कर सकें।

टिप्पणी:

issuer URL कोOIDC Discovery Spec का पालन करना चाहिए।व्यवहार में इसका अर्थ है कि URL https scheme का उपयोग करे और{service-account-issuer}/.well-known/openid-configuration पर OpenID provider configuration serve करे।

यदि URL इसका पालन नहीं करता, तो ServiceAccount issuer discovery endpoints register या accessible नहीं होंगे।

enable होने पर Kubernetes API server HTTP के जरिए OpenID Provider Configuration document publish करता है। यह document/.well-known/openid-configuration पर उपलब्ध होता है।OpenID Provider Configuration को कभी-कभी discovery document भी कहा जाता है।Kubernetes API server इससे संबंधित JSON Web Key Set (JWKS) भी HTTP के जरिए/openid/v1/jwks पर publish करता है।

टिप्पणी:

/.well-known/openid-configuration और /openid/v1/jwks पर मिलने वाले responses OIDC compatible होने के लिए डिज़ाइन किए गए हैं, लेकिन strictly OIDC compliant नहीं हैं।इन documents में केवल वे parameters होते हैं जो Kubernetes service account tokens को validate करने के लिए आवश्यक हैं।

जो clusters RBAC का उपयोग करते हैं, उनमेंsystem:service-account-issuer-discovery नाम का एक default ClusterRole शामिल होता है।एक default ClusterRoleBinding यह role system:serviceaccounts group को assign करता है,जिससे सभी ServiceAccounts निहित रूप से जुड़े होते हैं।इससे cluster पर चल रहे pods अपने mounted service account token के जरिए service account discovery document access कर सकते हैं।इसके अतिरिक्त administrators अपनी सुरक्षा आवश्यकताओं और जिन external systems से वे federate करना चाहते हैं,उनके आधार पर इस role को system:authenticated या system:unauthenticated से भी bind कर सकते हैं।

JWKS response में public keys होती हैं जिन्हें relying party Kubernetes service account tokens validate करने के लिए उपयोग कर सकती है। Relying parties पहले OpenID Provider Configuration query करती हैं,और response में jwks_uri field का उपयोग करके JWKS location प्राप्त करती हैं।

कई स्थितियों में Kubernetes API servers public internet पर उपलब्ध नहीं होते,लेकिन API server से cached responses serve करने वाले public endpoints users या service providers द्वारा उपलब्ध कराए जा सकते हैं।ऐसे मामलों में OpenID Provider Configuration में jwks_uri को override किया जा सकता है ताकि वह API server address के बजाय public endpoint पर point करे। इसके लिए API server पर --service-account-jwks-uri flag पास किया जाता है।issuer URL की तरह JWKS URI में भी https scheme आवश्यक है।

आगे क्या है

यह भी देखें:

4.9 - TLS

अपने क्लस्टर के भीतर ट्रैफ़िक को ट्रांसपोर्ट लेयर सिक्योरिटी (टीएलएस) का उपयोग करके सुरक्षित करना समझें।

4.9.1 - क्यूबलेट के लिए प्रमाणपत्र आवर्तन कॉन्फ़िगर करें

यह पृष्ठ दिखाता है कि क्यूबलेट के लिए प्रमाणपत्र आवर्तन कैसे सक्षम और कॉन्फ़िगर कर सकते है।

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

शुरू करने से पहले

  • कम से कम कुबेरनेट्स संस्करण 1.8.0 या उसके बाद की आवश्यकता है।

अवलोकन

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

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

क्लाइंट प्रमाणपत्र रोटेशन सक्षम करना

kubelet प्रक्रिया एक प्राचल --rotate-certificates स्वीकार करती है जो नियंत्रित करती है कि क्या कुबलेट स्वचालित रूप से वर्तमान में उपयोग किए जा रहे प्रमाणपत्र की समाप्ति के करीब आने पर एक नया प्रमाणपत्र अनुरोध करेगा।

kube-controller-manager प्रक्रिया एक प्राचल स्वीकार करती है --cluster-signing-duration (--experimental-cluster-signing-duration 1.19 से पहले)जो नियंत्रित करता है कि प्रमाणपत्र कितने समय के लिए जारी किए जाएंगे।

प्रमाणपत्र रोटेशन कॉन्फ़िगरेशन को समझना

जब एक कुबलेट शुरू होता है, यदि इसे बूटस्ट्रैप करने के लिए कॉन्फ़िगर किया गया है (उपयोग करते हुए --bootstrap-kubeconfig फ्लैग), तो यह कुबरनेट्स API से कनेक्ट करने और एक प्रमाणपत्र हस्ताक्षर अनुरोध जारी करने के लिए अपने प्रारंभिक प्रमाणपत्र का उपयोग करेगा। आप प्रमाणपत्र हस्ताक्षर अनुरोधों की स्थिति देख सकते हैं:

kubectl get csr

शुरुआत में, किसी नोड पर कुबलेट से एक प्रमाणपत्र हस्ताक्षर अनुरोध की स्थिति Pending होगी। यदि प्रमाणपत्र हस्ताक्षर अनुरोध विशिष्ट मानदंडों को पूरा करता है, तो इसे नियंत्रक प्रबंधक द्वारा स्वचालित रूप से अनुमोदित किया जाएगा, और फिर इसकी स्थिति Approved होगी। इसके बाद, नियंत्रक प्रबंधक एक प्रमाणपत्र पर हस्ताक्षर करेगा, जो --cluster-signing-duration पैरामीटर द्वारा निर्दिष्ट अवधि के लिए जारी किया जाएगा, और हस्ताक्षरित प्रमाणपत्र को प्रमाणपत्र हस्ताक्षर अनुरोध से जोड़ा जाएगा।

कुबलेट कुबरनेट्स API से हस्ताक्षरित प्रमाणपत्र प्राप्त करेगा और इसे डिस्क पर लिखेगा, --cert-dir द्वारा निर्दिष्ट स्थान में। फिर कुबलेट कुबरनेट्स API से कनेक्ट करने के लिए नए प्रमाणपत्र का उपयोग करेगा।

जैसे ही हस्ताक्षरित प्रमाणपत्र की समाप्ति निकट आती है, कुबलेट स्वचालित रूप से कुबरनेट्स API का उपयोग करके एक नया प्रमाणपत्र हस्ताक्षर अनुरोध जारी करेगा। यह प्रमाणपत्र पर शेष समय के 30% और 10% के बीच किसी भी बिंदु पर हो सकता है। फिर से, नियंत्रक प्रबंधक स्वचालित रूप से प्रमाणपत्र अनुरोध को अनुमोदित करेगा और प्रमाणपत्र हस्ताक्षर अनुरोध से एक हस्ताक्षरित प्रमाणपत्र जोड़ेगा। कुबलेट कुबरनेट्स API से नया हस्ताक्षरित प्रमाणपत्र प्राप्त करेगा और इसे डिस्क पर लिखेगा। फिर यह कुबरनेट्स API के साथ कनेक्शन को नए प्रमाणपत्र का उपयोग करके पुन: कनेक्ट करने के लिए अपडेट करेगा।

4.10 - Liveness, Readiness और Startup Probes कॉन्फ़िगर करें

यह पेज दिखाता है कि containers के लिए liveness, readiness और startup probes कैसे कॉन्फ़िगर करें।

probes के बारे में अधिक जानकारी के लिए देखें:Liveness, Readiness और Startup Probes

kubelet यह जानने के लिए liveness probes का उपयोग करता है कि container को कब restart करना है।उदाहरण के लिए, liveness probes deadlock पकड़ सकते हैं, जहाँ application चल तो रही होती है लेकिन आगे प्रगति नहीं कर पा रही होती। ऐसे state में container restart करना,bugs होने के बावजूद application की availability बेहतर कर सकता है।

liveness probes का एक सामान्य pattern यह है कि readiness probes वाली same low-cost HTTP endpoint का उपयोग किया जाए, लेकिन higher failureThreshold के साथ।इससे Pod को hard kill करने से पहले कुछ समय तक not-ready के रूप में observe किया जाता है।

kubelet readiness probes का उपयोग यह जानने के लिए करता है कि container traffic स्वीकार करने के लिए कब तैयार है। इस signal का एक उपयोग यह नियंत्रित करना है कि किन Pods को Services के backends के रूप में उपयोग किया जाए।Pod तब ready माना जाता है जब उसका Ready condition true हो।जब Pod ready नहीं होता, तो उसे Service load balancers से हटा दिया जाता है।Pod की Ready condition false होती है जब उसके Node की Ready condition true न हो,या Pod के किसी readinessGates की condition false हो, या उसके containers में से कम से कम एक ready न हो।

kubelet startup probes का उपयोग यह जानने के लिए करता है कि container application शुरू हुई या नहीं।यदि ऐसा probe कॉन्फ़िगर है, तो liveness और readiness probes तब तक शुरू नहीं होतीं जब तक startup probe सफल न हो जाए। इससे यह सुनिश्चित होता है कि वे probes application startup में हस्तक्षेप न करें।इससे धीमे शुरू होने वाले containers पर liveness checks अपनाई जा सकती हैं और container को पूरी तरह शुरू होने से पहले kubelet द्वारा kill होने से बचाया जा सकता है।

सावधान:

Liveness probes application failures से recovery का शक्तिशाली तरीका हो सकती हैं, लेकिन इन्हें सावधानी से उपयोग करना चाहिए। Liveness probes को बहुत ध्यान से कॉन्फ़िगर करना चाहिए ताकि वे वास्तव में unrecoverable application failure (जैसे deadlock) को ही दर्शाएँ।

टिप्पणी:

Liveness probes का गलत implementation cascading failures का कारण बन सकता है। इसका परिणाम high load में containers के बार-बार restart होने, application की scalability घटने से client requests fail होने,और कुछ pods fail होने के कारण बाकी pods पर workload बढ़ने के रूप में हो सकता है।अपने app के लिए readiness और liveness probes का अंतर और उनके सही उपयोग को समझें।

शुरू करने से पहले

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

liveness command परिभाषित करें

लंबे समय तक चलने वाले कई applications अंततः broken states में पहुँच जाते हैं और restart किए बिना recover नहीं कर पाते।Kubernetes ऐसी स्थितियों का पता लगाने और सुधारने के लिए liveness probes देता है।

इस अभ्यास में आप ऐसा Pod बनाते हैं जो registry.k8s.io/busybox:1.27.2 image पर आधारित container चलाता है।यह Pod की configuration file है:

pods/probe/exec-liveness.yaml 
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/busybox:1.27.2
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

configuration file में आप देख सकते हैं कि Pod में एक ही Container है।periodSeconds field बताती है कि kubelet हर 5 seconds में liveness probe चलाए।initialDelaySeconds field बताती है कि पहली probe चलाने से पहले kubelet 5 seconds प्रतीक्षा करे।probe चलाने के लिए kubelet target container में cat /tmp/healthy command execute करता है।अगर command सफल होती है, तो 0 return होता है और kubelet container को जीवित और healthy मानता है।अगर command non-zero return करती है, तो kubelet container को kill करके restart कर देता है।

जब container शुरू होता है, तो वह यह command चलाता है:

/bin/sh -c "touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600"

container के जीवन के पहले 30 seconds तक /tmp/healthy फ़ाइल मौजूद रहती है।इसलिए पहले 30 seconds के दौरान cat /tmp/healthy success code लौटाता है।30 seconds के बाद cat /tmp/healthy failure code लौटाता है।

Pod बनाएं:

kubectl apply -f https://k8s.io/examples/pods/probe/exec-liveness.yaml

30 seconds के भीतर Pod events देखें:

kubectl describe pod liveness-exec

आउटपुट दर्शाता है कि अभी तक कोई liveness probe fail नहीं हुई:

Type    Reason     Age   From               Message
----    ------     ----  ----               -------
Normal  Scheduled  11s   default-scheduler  Successfully assigned default/liveness-exec to node01
Normal  Pulling    9s    kubelet, node01    Pulling image "registry.k8s.io/busybox:1.27.2"
Normal  Pulled     7s    kubelet, node01    Successfully pulled image "registry.k8s.io/busybox:1.27.2"
Normal  Created    7s    kubelet, node01    Created container liveness
Normal  Started    7s    kubelet, node01    Started container liveness

35 seconds के बाद Pod events फिर देखें:

kubectl describe pod liveness-exec

आउटपुट के नीचे ऐसे messages होंगे जो दिखाते हैं कि liveness probes fail हुईं और failed containers को kill करके दोबारा बनाया गया।

Type     Reason     Age                From               Message
----     ------     ----               ----               -------
Normal   Scheduled  57s                default-scheduler  Successfully assigned default/liveness-exec to node01
Normal   Pulling    55s                kubelet, node01    Pulling image "registry.k8s.io/busybox:1.27.2"
Normal   Pulled     53s                kubelet, node01    Successfully pulled image "registry.k8s.io/busybox:1.27.2"
Normal   Created    53s                kubelet, node01    Created container liveness
Normal   Started    53s                kubelet, node01    Started container liveness
Warning  Unhealthy  10s (x3 over 20s)  kubelet, node01    Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
Normal   Killing    10s                kubelet, node01    Container liveness failed liveness probe, will be restarted

और 30 seconds प्रतीक्षा करें, फिर सत्यापित करें कि container restart हुआ है:

kubectl get pod liveness-exec

आउटपुट दिखाता है कि RESTARTS बढ़ गया है। ध्यान दें कि RESTARTS counter जैसे ही failed container फिर running state में आता है, बढ़ जाता है:

NAME            READY     STATUS    RESTARTS   AGE
liveness-exec   1/1       Running   1          1m

liveness HTTP request परिभाषित करें

liveness probe का दूसरा प्रकार HTTP GET request का उपयोग करता है।यहाँ उस Pod की configuration file है जो registry.k8s.io/e2e-test-images/agnhost image पर आधारित container चलाता है।

pods/probe/http-liveness.yaml 
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/e2e-test-images/agnhost:2.40
    args:
    - liveness
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

configuration file में आप देख सकते हैं कि Pod में एक ही container है।periodSeconds field बताती है कि kubelet हर 3 seconds में liveness probe चलाए।initialDelaySeconds field बताती है कि पहली probe से पहले kubelet 3 seconds प्रतीक्षा करे।probe चलाने के लिए kubelet container में चल रहे server को HTTP GET request भेजता है,जो port 8080 पर listen कर रहा है। अगर server के /healthz path का handler success code लौटाता है,तो kubelet container को alive और healthy मानता है। अगर handler failure code लौटाए,तो kubelet container को kill करके restart कर देता है।

200 या उससे बड़ा और 400 से छोटा कोई भी code success दर्शाता है।अन्य कोई भी code failure दर्शाता है।

आप server का source code यहाँ देख सकते हैं:server.go।

container के जीवित रहने के पहले 10 seconds तक /healthz handler status 200 लौटाता है। उसके बाद handler status 500 लौटाता है।

http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
    duration := time.Now().Sub(started)
    if duration.Seconds() > 10 {
        w.WriteHeader(500)
        w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds())))
    } else {
        w.WriteHeader(200)
        w.Write([]byte("ok"))
    }
})

container start होने के 3 seconds बाद kubelet health checks शुरू करता है।इसलिए शुरुआती कुछ checks सफल होंगी। लेकिन 10 seconds के बाद checks fail होंगी और kubelet container को kill करके restart कर देगा।

HTTP liveness check आज़माने के लिए Pod बनाएं:

kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml

10 seconds बाद Pod events देखें और सत्यापित करें कि liveness probes fail हुईं और container restart हुआ:

kubectl describe pod liveness-http

v1.13 के बाद के releases में local HTTP proxy environment variable settings HTTP liveness probe को प्रभावित नहीं करतीं।

TCP liveness probe परिभाषित करें

liveness probe का तीसरा प्रकार TCP socket का उपयोग करता है।इस configuration के साथ kubelet निर्दिष्ट port पर आपके container से socket connection खोलने की कोशिश करेगा।यदि connection बन जाता है तो container healthy माना जाता है, अन्यथा इसे failure माना जाता है।

pods/probe/tcp-liveness-readiness.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: registry.k8s.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 10

जैसा आप देख सकते हैं, TCP check की configuration HTTP check जैसी ही है।यह उदाहरण readiness और liveness दोनों probes का उपयोग करता है।kubelet container शुरू होने के 15 seconds बाद पहली liveness probe चलाएगा।यह port 8080 पर goproxy container से connect करने की कोशिश करेगा।अगर liveness probe fail होती है, तो container restart होगा।kubelet हर 10 seconds में यह check चलाता रहेगा।

liveness probe के अलावा इस configuration में readiness probe भी शामिल है।kubelet container शुरू होने के 15 seconds बाद पहली readiness probe चलाएगा।liveness probe की तरह यह भी port 8080 पर goproxy container से connect करने की कोशिश करेगा।यदि probe सफल होती है, तो Pod ready mark होगा और services से traffic प्राप्त करेगा।यदि readiness probe fail होती है, तो Pod unready mark होगा और किसी भी service से traffic नहीं पाएगा।

TCP liveness check आज़माने के लिए Pod बनाएं:

kubectl apply -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml

15 seconds बाद Pod events देखें और liveness probes की स्थिति सत्यापित करें:

kubectl describe pod goproxy

gRPC liveness probe परिभाषित करें

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

यदि आपकी applicationgRPC Health Checking Protocol implement करती है, तो यह उदाहरण दिखाता है कि application liveness checks के लिए Kubernetes को इसका उपयोग करने हेतु कैसे कॉन्फ़िगर करें।इसी तरह आप readiness और startup probes भी कॉन्फ़िगर कर सकते हैं।

यहाँ एक example manifest है:

pods/probe/grpc-liveness.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: etcd-with-grpc
spec:
  containers:
  - name: etcd
    image: registry.k8s.io/etcd:3.5.1-0
    command: [ "/usr/local/bin/etcd", "--data-dir",  "/var/lib/etcd", "--listen-client-urls", "http://0.0.0.0:2379", "--advertise-client-urls", "http://127.0.0.1:2379", "--log-level", "debug"]
    ports:
    - containerPort: 2379
    livenessProbe:
      grpc:
        port: 2379
      initialDelaySeconds: 10

gRPC probe उपयोग करने के लिए port कॉन्फ़िगर होना आवश्यक है।अगर आप अलग प्रकार की probes और अलग features की probes में भेद करना चाहते हैं,तो service field उपयोग कर सकते हैं।आप service को liveness सेट कर सकते हैं और gRPC Health Checking endpoint को यह request मिलने पर service को readiness सेट करने से अलग response देने के लिए कॉन्फ़िगर कर सकते हैं।इससे आप दो अलग ports पर listen करने के बजाय एक ही endpoint का उपयोग विभिन्न प्रकार के container health checks के लिए कर सकते हैं।यदि आप अपना custom service name भी देना चाहते हैं और probe type भी बताना चाहते हैं,तो Kubernetes project सुझाव देता है कि आप दोनों को जोड़कर नाम रखें।उदाहरण: myservice-liveness (- separator के रूप में)।

टिप्पणी:

HTTP या TCP probes के विपरीत, आप health check port को नाम से specify नहीं कर सकते,और custom hostname भी कॉन्फ़िगर नहीं कर सकते।

configuration problems (उदाहरण: गलत port/service, health checking protocol implement न होना)को probe failure माना जाता है, ठीक HTTP और TCP probes की तरह।

gRPC liveness check आज़माने के लिए नीचे दी गई command से Pod बनाएं।नीचे के उदाहरण में etcd pod को gRPC liveness probe उपयोग करने के लिए कॉन्फ़िगर किया गया है।

kubectl apply -f https://k8s.io/examples/pods/probe/grpc-liveness.yaml

15 seconds बाद Pod events देखें और सत्यापित करें कि liveness check fail नहीं हुई:

kubectl describe pod etcd-with-grpc

gRPC probe का उपयोग करते समय कुछ तकनीकी बातें ध्यान रखने योग्य हैं:

  • probes pod IP address या उसके hostname पर चलती हैं।सुनिश्चित करें कि आपका gRPC endpoint Pod के IP address पर listen करे।
  • probes किसी authentication parameter (जैसे -tls) को support नहीं करतीं।
  • built-in probes के लिए error codes नहीं होते। सभी errors को probe failure माना जाता है।
  • यदि ExecProbeTimeout feature gate false पर सेट है, तो grpc-health-probetimeoutSeconds setting (जिसका default 1s है) का पालन नहीं करता, जबकि built-in probe timeout पर fail हो जाती है।

named port का उपयोग करें

आप HTTP और TCP probes के लिए named port उपयोग कर सकते हैं। gRPC probes named ports को support नहीं करतीं।

उदाहरण:

ports:
- name: liveness-port
  containerPort: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port

startup probes से धीमे शुरू होने वाले containers को सुरक्षित रखें

कभी-कभी आपको ऐसी applications से निपटना पड़ता है जिन्हें पहली initialization पर अतिरिक्त startup time चाहिए। ऐसे मामलों में liveness probe parameters सेट करना मुश्किल हो सकता है,क्योंकि deadlock पर तेज प्रतिक्रिया भी चाहिए और startup समय पर probe से समस्या भी नहीं होनी चाहिए।इसका समाधान है startup probe सेट करना जिसमें वही command, HTTP या TCP check हो, औरfailureThreshold * periodSeconds इतना लंबा हो कि worst-case startup time कवर हो जाए।

तो पिछला उदाहरण इस प्रकार बन जाएगा:

ports:
- name: liveness-port
  containerPort: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 1
  periodSeconds: 10

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10

startup probe की वजह से application को startup पूरा करने के लिए अधिकतम 5 minutes(30 * 10 = 300s) मिलेंगे।startup probe एक बार सफल होते ही liveness probe takeover करती है ताकि container deadlocks पर तेज प्रतिक्रिया मिल सके।अगर startup probe कभी सफल नहीं होती, तो container 300s के बाद kill हो जाएगा और Pod की restartPolicy लागू होगी।

readiness probes परिभाषित करें

कभी-कभी applications अस्थायी रूप से traffic serve नहीं कर पातीं।उदाहरण के लिए startup के दौरान application को बड़े data या configuration files load करने पड़ सकते हैं,या startup के बाद external services पर निर्भर होना पड़ सकता है।ऐसी स्थितियों में आप application को kill नहीं करना चाहते,लेकिन उसे requests भी नहीं भेजना चाहते। Kubernetes इसके लिए readiness probes प्रदान करता है।जिस pod में containers report करते हैं कि वे ready नहीं हैं, उसे Kubernetes Services के जरिए traffic नहीं मिलता।

टिप्पणी:

Readiness probes container के पूरे lifecycle में चलती हैं।

सावधान:

readiness और liveness probes एक-दूसरे पर निर्भर नहीं होतीं।अगर आप readiness probe चलाने से पहले प्रतीक्षा करना चाहते हैं, तोinitialDelaySeconds या startupProbe का उपयोग करें।

Readiness probes, liveness probes की तरह ही कॉन्फ़िगर होती हैं।केवल अंतर यह है कि livenessProbe के बजाय readinessProbe field उपयोग होती है।

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

HTTP और TCP readiness probes की configuration भी liveness probes जैसी ही रहती है।

Readiness और liveness probes एक ही container के लिए parallel में उपयोग की जा सकती हैं।दोनों का उपयोग यह सुनिश्चित कर सकता है कि traffic ऐसे container तक न पहुँचे जो उसके लिए ready नहीं है,और failure होने पर containers restart हों।

Probes कॉन्फ़िगर करें

प्रोब्स (Probes) में कई fields होती हैं जिनसे आप startup, liveness और readiness checks के behavior को अधिक सटीक रूप से नियंत्रित कर सकते हैं:

  • initialDelaySeconds: container start होने के बाद startup, liveness या readiness probes शुरू करने से पहले कितने seconds प्रतीक्षा करनी है।यदि startup probe परिभाषित है, तो liveness और readiness की delays तब तक शुरू नहीं होतीं जब तक startup probe सफल न हो जाए।Kubernetes के कुछ पुराने versions में, यदि periodSeconds को initialDelaySeconds से बड़ा सेट किया गया हो,तो initialDelaySeconds को नज़रअंदाज़ किया जा सकता था। लेकिन वर्तमान versions में initialDelaySeconds हमेशा मान्य होती है और probe इस शुरुआती delay के बाद ही शुरू होती है। Default 0 seconds, minimum 0।
  • periodSeconds: probe कितनी बार (seconds में) चलानी है। Default 10 seconds।Minimum value 1 है।जब container Ready नहीं होता, तो ReadinessProbe कभी-कभी configured periodSeconds interval से अलग समय पर भी चल सकती है,ताकि Pod जल्दी ready हो सके।
  • timeoutSeconds: probe timeout होने से पहले कितने seconds प्रतीक्षा करनी है।Default 1 second, minimum 1।
  • successThreshold: fail होने के बाद probe को successful मानने के लिए लगातार सफल probes की न्यूनतम संख्या।Default 1। liveness और startup Probes के लिए यह 1 ही होना चाहिए।Minimum value 1।
  • failureThreshold: probe लगातार failureThreshold बार fail हो जाए तो Kubernetes overall check को failed मानता है: container ready/healthy/live नहीं है।Default 3। Minimum value 1।startup या liveness probe के मामले में, यदि कम से कम failureThreshold probes fail हों,तो Kubernetes container को unhealthy मानता है और उसी specific container का restart trigger करता है।kubelet उस container के terminationGracePeriodSeconds setting का सम्मान करता है।readiness probe fail होने पर kubelet failed container को चलाता रहता है और probes भी जारी रखता है;check fail होने के कारण kubelet Pod की Ready condition को false सेट कर देता है।
  • terminationGracePeriodSeconds: failed container को shutdown trigger करने और फिर container runtime को उसे force stop करने के बीच kubelet कितना grace period दे, यह कॉन्फ़िगर करता है।Default रूप से यह Pod-level terminationGracePeriodSeconds को inherit करता है(यदि न दिया हो तो 30 seconds), और minimum value 1 है।अधिक जानकारी के लिए probe-level terminationGracePeriodSeconds देखें।

सावधान:

readiness probes का गलत implementation container में processes की संख्या को लगातार बढ़ा सकता है,और अगर इसे नियंत्रित न किया जाए तो resource starvation हो सकती है।

HTTP प्रोब्स

HTTP प्रोब्स में httpGet पर कुछ अतिरिक्त fields सेट की जा सकती हैं:

  • host: connect करने के लिए host name; default pod IP होता है।आमतौर पर इसके बजाय httpHeaders में "Host" सेट करना बेहतर है।
  • scheme: host से connect करने के लिए scheme (HTTP या HTTPS)। Default "HTTP" है।
  • path: HTTP server पर access करने का path। Default "/" है।
  • httpHeaders: request में सेट करने के लिए custom headers। HTTP repeated headers को अनुमति देता है।
  • port: container पर access करने वाले port का नाम या संख्या। संख्या 1 से 65535 के बीच होनी चाहिए।

HTTP probe के लिए kubelet निर्दिष्ट port और path पर HTTP request भेजकर check करता है।kubelet probe को Pod के IP address पर भेजता है, जब तक httpGet में optional host field से address override न हो।अगर scheme field HTTPS हो, तो kubelet certificate verification skip करते हुए HTTPS request भेजता है।अधिकांश स्थितियों में आप host field सेट नहीं करना चाहेंगे।एक स्थिति जहाँ आप इसे सेट करेंगे: मान लें container 127.0.0.1 पर listen करता है और Pod की hostNetwork field true है। तब httpGet के अंतर्गत host को 127.0.0.1 सेट करना चाहिए।अगर आपका pod virtual hosts पर निर्भर है (जो अधिक सामान्य मामला है),तो host का उपयोग न करें; बल्कि httpHeaders में Host header सेट करें।

HTTP probe के लिए kubelet अनिवार्य Host header के अलावा दो request headers भेजता है:

  • User-Agent: default value kube-probe/1.35 है,जहाँ 1.35 kubelet का version है।
  • Accept: default value */* है।

आप probe के लिए httpHeaders define करके default headers override कर सकते हैं।उदाहरण:

livenessProbe:
  httpGet:
    httpHeaders:
      - name: Accept
        value: application/json

startupProbe:
  httpGet:
    httpHeaders:
      - name: User-Agent
        value: MyUserAgent

इन दोनों headers को empty value देकर आप इन्हें हटा भी सकते हैं।

livenessProbe:
  httpGet:
    httpHeaders:
      - name: Accept
        value: ""

startupProbe:
  httpGet:
    httpHeaders:
      - name: User-Agent
        value: ""

टिप्पणी:

जब kubelet HTTP का उपयोग करके Pod probe करता है, तो वह redirects केवल तब follow करता है जब redirect उसी host पर हो।अगर probing के दौरान kubelet को 11 या उससे अधिक redirects मिलते हैं, तो probe को successful माना जाता है और संबंधित Event बनाया जाता है:

Events:
  Type     Reason        Age                     From               Message
  ----     ------        ----                    ----               -------
  Normal   Scheduled     29m                     default-scheduler  Successfully assigned default/httpbin-7b8bc9cb85-bjzwn to daocloud
  Normal   Pulling       29m                     kubelet            Pulling image "docker.io/kennethreitz/httpbin"
  Normal   Pulled        24m                     kubelet            Successfully pulled image "docker.io/kennethreitz/httpbin" in 5m12.402735213s
  Normal   Created       24m                     kubelet            Created container httpbin
  Normal   Started       24m                     kubelet            Started container httpbin
 Warning  ProbeWarning  4m11s (x1197 over 24m)  kubelet            Readiness probe warning: Probe terminated redirects

यदि kubelet को ऐसा redirect मिलता है जिसमें hostname request से अलग है, तो probe outcome को successful माना जाता है और kubelet redirect failure रिपोर्ट करने के लिए event बनाता है।

सावधान:

httpGet probe process करते समय kubelet response body का केवल पहले 10KiB तक पढ़ता है।probe की success केवल response status code से तय होती है, जो response headers में मिलता है।

यदि आप ऐसे endpoint को probe करते हैं जो 10KiB से बड़ा response body लौटाता है,तो kubelet status code के आधार पर probe को successful mark कर सकता है,लेकिन 10KiB limit पर पहुंचने के बाद connection बंद कर देगा।इस अचानक closure से application logs में connection reset by peer या broken pipe errors दिख सकती हैं,जिन्हें वास्तविक network issues से अलग पहचानना कठिन हो सकता है।

विश्वसनीय httpGet probes के लिए strongly recommended है कि dedicated health check endpoints उपयोग करें जो minimal response body लौटाएँ। यदि बड़े payload वाले existing endpoint का उपयोग करना ही पड़े,तो उसके बजाय HEAD request करने के लिए exec probe उपयोग करने पर विचार करें।

TCP प्रोब्स

TCP probe के लिए kubelet probe connection node से बनाता है, Pod के अंदर से नहीं।इसका मतलब है कि host parameter में service name का उपयोग नहीं किया जा सकता,क्योंकि kubelet उसे resolve नहीं कर पाता।

प्रोब-स्तरीय terminationGracePeriodSeconds

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

1.25 और उसके बाद, users probe specification के हिस्से के रूप में probe-level terminationGracePeriodSeconds सेट कर सकते हैं।जब pod-level और probe-level दोनों terminationGracePeriodSeconds सेट हों,तो kubelet probe-level value का उपयोग करेगा।

terminationGracePeriodSeconds सेट करते समय निम्न बातों का ध्यान रखें:

  • kubelet हमेशा probe-level terminationGracePeriodSeconds field का सम्मान करता है यदि वह Pod पर मौजूद है।

  • यदि आपके पास existing Pods हैं जिनमें terminationGracePeriodSeconds field सेट है और आप per-probe termination grace periods का उपयोग नहीं करना चाहते,तो आपको वे existing Pods delete करने होंगे।

उदाहरण:

spec:
  terminationGracePeriodSeconds: 3600  # pod-level
  containers:
  - name: test
    image: ...

    ports:
    - name: liveness-port
      containerPort: 8080

    livenessProbe:
      httpGet:
        path: /healthz
        port: liveness-port
      failureThreshold: 1
      periodSeconds: 60
      # Override pod-level terminationGracePeriodSeconds #
      terminationGracePeriodSeconds: 60

readiness probes के लिए probe-level terminationGracePeriodSeconds सेट नहीं किया जा सकता।API server इसे reject कर देगा।

आगे क्या है

  • इसके बारे में और जानें:Container Probes।

आप API references भी पढ़ सकते हैं:

4.11 - Pod Initialization कॉन्फ़िगर करें

यह पेज दिखाता है कि किसी एप्लिकेशन Container के चलने से पहले Pod को initialize करने के लिए Init Container का उपयोग कैसे करें।

शुरू करने से पहले

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

संस्करण की जांच करने के लिए, लिखें kubectl version.

ऐसा Pod बनाएं जिसमें Init Container हो

इस अभ्यास में आप ऐसा Pod बनाते हैं जिसमें एक application Container और एक Init Container होता है। application container शुरू होने से पहले init container पूरा चलकर समाप्त हो जाता है।

यह Pod की configuration file है:

pods/init-containers.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: init-demo
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    volumeMounts:
    - name: workdir
      mountPath: /usr/share/nginx/html
  # These containers are run during pod initialization
  initContainers:
  - name: install
    image: busybox:1.28
    command:
    - wget
    - "-O"
    - "/work-dir/index.html"
    - http://info.cern.ch
    volumeMounts:
    - name: workdir
      mountPath: "/work-dir"
  dnsPolicy: Default
  volumes:
  - name: workdir
    emptyDir: {}

configuration file में आप देख सकते हैं कि Pod में एक Volume है जिसे init container और application container share करते हैं।

init container shared Volume को /work-dir पर mount करता है, और application container shared Volume को /usr/share/nginx/html पर mount करता है। init container नीचे दी गई कमांड चलाता है और फिर समाप्त हो जाता है:

wget -O /work-dir/index.html http://info.cern.ch

ध्यान दें कि init container, nginx server की root directory में index.html फ़ाइल लिखता है।

Pod बनाएं:

kubectl apply -f https://k8s.io/examples/pods/init-containers.yaml

जांचें कि nginx container चल रहा है:

kubectl get pod init-demo

आउटपुट दिखाता है कि nginx container चल रहा है:

NAME        READY     STATUS    RESTARTS   AGE
init-demo   1/1       Running   0          1m

init-demo Pod में चल रहे nginx container के अंदर shell खोलें:

kubectl exec -it init-demo -- /bin/bash

अपनी shell में, nginx server पर GET request भेजें:

root@nginx:~# apt-get update
root@nginx:~# apt-get install curl
root@nginx:~# curl localhost

आउटपुट दिखाता है कि nginx वही web page serve कर रहा है जिसे init container ने लिखा था:

<html><head></head><body><header>
<title>http://info.cern.ch</title>
</header>

<h1>http://info.cern.ch - home of the first website</h1>
  ...
  <li><a href="http://info.cern.ch/hypertext/WWW/TheProject.html">Browse the first website</a></li>
  ...

आगे क्या है

4.12 - ConfigMap का उपयोग करने के लिए Pod कॉन्फ़िगर करें

कई एप्लिकेशन कॉन्फ़िगरेशन पर निर्भर करते हैं, जिसका उपयोग एप्लिकेशन के initialization के दौरान या runtime में किया जाता है।ज़्यादातर बार, कॉन्फ़िगरेशन पैरामीटर को दिए गए मानों को समायोजित करने की आवश्यकता होती है।ConfigMap, Kubernetes का एक मैकेनिज़्म है जो आपको कॉन्फ़िगरेशन डेटा को एप्लिकेशन pods में inject करने देता है।

ConfigMap का कॉन्सेप्ट आपको कॉन्फ़िगरेशन artifacts को image content से अलग (decouple) करने देता है,ताकि containerized applications पोर्टेबल बनी रहें। उदाहरण के लिए, आप एक ही container image को डाउनलोड और रन करके local development, system test, या live end-user workload चलाने के लिए कंटेनर शुरू कर सकते हैं।

यह पेज उपयोग के कई उदाहरण देता है, जिनसे यह दिखाया गया है कि ConfigMap कैसे बनाएँ और ConfigMap में स्टोर किए गए डेटा का उपयोग करके Pods को कैसे कॉन्फ़िगर करें।

शुरू करने से पहले

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

आपके सिस्टम में wget टूल इंस्टॉल होना चाहिए। अगर आपके पास कोई दूसरा टूल जैसे curl है और wget नहीं है, तो आपको example data डाउनलोड करने वाला step उसी के अनुसार बदलना होगा।

ConfigMap बनाएं

ConfigMap बनाने के लिए आप या तो kubectl create configmap का उपयोग कर सकते हैं याkustomization.yaml में ConfigMap generator का।

kubectl create configmap का उपयोग करके ConfigMap बनाएं

kubectl create configmap कमांड का उपयोग करके आपdirectories, files,या literal values से ConfigMap बना सकते हैं:

kubectl create configmap <map-name> <data-source>

जहाँ <map-name> वह नाम है जो आप ConfigMap को देना चाहते हैं और <data-source> वह directory, file, या literal value है जिससे डेटा लिया जाएगा।ConfigMap ऑब्जेक्ट का नाम एक वैधDNS subdomain name होना चाहिए।

जब आप किसी फ़ाइल के आधार पर ConfigMap बनाते हैं, तो <data-source> में key डिफ़ॉल्ट रूप से उस फ़ाइल का basename होती है, और value डिफ़ॉल्ट रूप से फ़ाइल का content होता है।

आप kubectl describe याkubectl get का उपयोग करके ConfigMap की जानकारी प्राप्त कर सकते हैं।

डायरेक्टरी से ConfigMap बनाएं

आप kubectl create configmap का उपयोग करके एक ही डायरेक्टरी में मौजूद कई फ़ाइलों से ConfigMap बना सकते हैं। जब आप डायरेक्टरी के आधार पर ConfigMap बनाते हैं, तो kubectl उन फ़ाइलों की पहचान करता है जिनका filename वैध key होता है, और हर ऐसी फ़ाइल को नए ConfigMap में पैकेज करता है। सामान्य फ़ाइलों (regular files) के अलावा बाकी डायरेक्टरी entries नज़रअंदाज़ कर दी जाती हैं (जैसे: subdirectories, symlinks, devices, pipes, आदि)।

टिप्पणी:

ConfigMap बनाने के लिए उपयोग होने वाला हर filename केवल स्वीकार्य अक्षरों से बना होना चाहिए:letters (A से Z और a से z), digits (0 से 9), '-', '_', या '.'।अगर आप kubectl create configmap को ऐसी डायरेक्टरी पर चलाते हैं जहाँ किसी फ़ाइल के नाम में अस्वीकार्य कैरेक्टर हो, तो kubectl कमांड fail हो सकती है।

जब kubectl कमांड को invalid filename मिलता है, तो यह हमेशा error प्रिंट नहीं करता।

लोकल डायरेक्टरी बनाएं:

mkdir -p configure-pod-container/configmap/

अब sample configuration डाउनलोड करें और ConfigMap बनाएं:

# Download the sample files into `configure-pod-container/configmap/` directory
wget https://kubernetes.io/examples/configmap/game.properties -O configure-pod-container/configmap/game.properties
wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-container/configmap/ui.properties

# Create the ConfigMap
kubectl create configmap game-config --from-file=configure-pod-container/configmap/

ऊपर दी गई कमांड हर फ़ाइल को पैकेज करती है, इस केस में game.properties और ui.properties को configure-pod-container/configmap/ डायरेक्टरी से game-config ConfigMap में जोड़ती है।आप नीचे दी गई कमांड से ConfigMap का विवरण देख सकते हैं:

kubectl describe configmaps game-config

आउटपुट कुछ इस तरह होगा:

Name:         game-config
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
ui.properties:
----
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice

configure-pod-container/configmap/ डायरेक्टरी में मौजूद game.properties और ui.properties फ़ाइलें ConfigMap के data सेक्शन में प्रदर्शित होती हैं।

kubectl get configmaps game-config -o yaml

आउटपुट कुछ इस तरह होगा:

apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: 2022-02-18T18:52:05Z
  name: game-config
  namespace: default
  resourceVersion: "516"
  uid: b4952dc3-d670-11e5-8cd0-68f728db1985
data:
  game.properties: |
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30    
  ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
    how.nice.to.look=fairlyNice

फ़ाइलों से ConfigMap बनाएं

आप kubectl create configmap का उपयोग करके एक फ़ाइल या कई फ़ाइलों से ConfigMap बना सकते हैं।

उदाहरण के लिए,

kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties

यह निम्न ConfigMap बनाएगा:

kubectl describe configmaps game-config-2

जहाँ आउटपुट कुछ इस तरह होगा:

Name:         game-config-2
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30

कई data sources से ConfigMap बनाने के लिए आप --from-file argument को कई बार दे सकते हैं।

kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties --from-file=configure-pod-container/configmap/ui.properties

आप नीचे दी गई कमांड से game-config-2 ConfigMap का विवरण देख सकते हैं:

kubectl describe configmaps game-config-2

आउटपुट कुछ इस तरह होगा:

Name:         game-config-2
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
ui.properties:
----
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice

env-file से ConfigMap बनाने के लिए --from-env-file विकल्प का उपयोग करें, उदाहरण के लिए:

# Env-files contain a list of environment variables.
# These syntax rules apply:
#   Each line in an env file has to be in VAR=VAL format.
#   Lines beginning with # (i.e. comments) are ignored.
#   Blank lines are ignored.
#   There is no special handling of quotation marks (i.e. they will be part of the ConfigMap value)).

# Download the sample files into `configure-pod-container/configmap/` directory
wget https://kubernetes.io/examples/configmap/game-env-file.properties -O configure-pod-container/configmap/game-env-file.properties
wget https://kubernetes.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties

# The env-file `game-env-file.properties` looks like below
cat configure-pod-container/configmap/game-env-file.properties
enemies=aliens
lives=3
allowed="true"

# This comment and the empty line above it are ignored

kubectl create configmap game-config-env-file \
       --from-env-file=configure-pod-container/configmap/game-env-file.properties

यह एक ConfigMap बनाएगा। ConfigMap देखें:

kubectl get configmap game-config-env-file -o yaml

आउटपुट कुछ इस तरह होगा:

apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: 2019-12-27T18:36:28Z
  name: game-config-env-file
  namespace: default
  resourceVersion: "809965"
  uid: d9d1ca5b-eb34-11e7-887b-42010a8002b8
data:
  allowed: '"true"'
  enemies: aliens
  lives: "3"

Kubernetes v1.23 से, kubectl में --from-env-file argument को कई बार specify करके कई data sources से ConfigMap बनाना समर्थित है।

kubectl create configmap config-multi-env-files \
        --from-env-file=configure-pod-container/configmap/game-env-file.properties \
        --from-env-file=configure-pod-container/configmap/ui-env-file.properties

यह निम्न ConfigMap बनाएगा:

kubectl get configmap config-multi-env-files -o yaml

जहाँ आउटपुट कुछ इस तरह होगा:

apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: 2019-12-27T18:38:34Z
  name: config-multi-env-files
  namespace: default
  resourceVersion: "810136"
  uid: 252c4572-eb35-11e7-887b-42010a8002b8
data:
  allowed: '"true"'
  color: purple
  enemies: aliens
  how: fairlyNice
  lives: "3"
  textmode: "true"

फ़ाइल से ConfigMap बनाते समय उपयोग होने वाली key परिभाषित करें

जब आप --from-file argument का उपयोग करते हैं, तब ConfigMap के data सेक्शन में फ़ाइल नाम के बजाय कोई दूसरी key भी परिभाषित कर सकते हैं:

kubectl create configmap game-config-3 --from-file=<my-key-name>=<path-to-file>

जहाँ <my-key-name> वह key है जिसे आप ConfigMap में उपयोग करना चाहते हैं और <path-to-file> वह data source फ़ाइल का स्थान है जिसे वह key represent करेगी।

उदाहरण के लिए:

kubectl create configmap game-config-3 --from-file=game-special-key=configure-pod-container/configmap/game.properties

यह निम्न ConfigMap बनाएगा:

kubectl get configmaps game-config-3 -o yaml

जहाँ आउटपुट कुछ इस तरह होगा:

apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: 2022-02-18T18:54:22Z
  name: game-config-3
  namespace: default
  resourceVersion: "530"
  uid: 05f8da22-d671-11e5-8cd0-68f728db1985
data:
  game-special-key: |
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30

literal values से ConfigMap बनाएं

आप kubectl create configmap के साथ --from-literal argument का उपयोग करके command line से literal value परिभाषित कर सकते हैं:

kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm

आप कई key-value pairs दे सकते हैं। command line पर दिया गया हर pair ConfigMap केdata सेक्शन में अलग entry के रूप में दिखता है।

kubectl get configmaps special-config -o yaml

आउटपुट कुछ इस तरह होगा:

apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: 2022-02-18T19:14:38Z
  name: special-config
  namespace: default
  resourceVersion: "651"
  uid: dadce046-d673-11e5-8cd0-68f728db1985
data:
  special.how: very
  special.type: charm

generator से ConfigMap बनाएं

आप generators से भी ConfigMap बना सकते हैं और फिर उसे apply करके cluster के API server में object बना सकते हैं।आपको generators को किसी डायरेक्टरी के भीतर kustomization.yaml फ़ाइल में define करना चाहिए।

फ़ाइलों से ConfigMap generate करें

उदाहरण के लिए, फ़ाइल configure-pod-container/configmap/game.properties से ConfigMap generate करने के लिए:

# Create a kustomization.yaml file with ConfigMapGenerator
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: game-config-4
  options:
    labels:
      game-config: config-4
  files:
  - configure-pod-container/configmap/game.properties
EOF

ConfigMap object बनाने के लिए kustomization डायरेक्टरी apply करें:

kubectl apply -k .

configmap/game-config-4-m9dm2f92bt created

आप यह इस तरह जांच सकते हैं कि ConfigMap बना है:

kubectl get configmap

NAME                       DATA   AGE
game-config-4-m9dm2f92bt   1      37s

और यह भी:

kubectl describe configmaps/game-config-4-m9dm2f92bt

Name:         game-config-4-m9dm2f92bt
Namespace:    default
Labels:       game-config=config-4
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"v1","data":{"game.properties":"enemies=aliens\nlives=3\nenemies.cheat=true\nenemies.cheat.level=noGoodRotten\nsecret.code.p...

Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
Events:  <none>

ध्यान दें कि generated ConfigMap नाम के अंत में content का hash जोड़कर एक suffix लगाया जाता है।इससे यह सुनिश्चित होता है कि content बदलने पर हर बार नया ConfigMap generate हो।

फ़ाइल से ConfigMap generate करते समय उपयोग होने वाली key परिभाषित करें

आप ConfigMap generator में फ़ाइल नाम के बजाय दूसरी key परिभाषित कर सकते हैं।उदाहरण के लिए, configure-pod-container/configmap/game.properties से game-special-key key के साथ ConfigMap generate करने के लिए:

# Create a kustomization.yaml file with ConfigMapGenerator
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: game-config-5
  options:
    labels:
      game-config: config-5
  files:
  - game-special-key=configure-pod-container/configmap/game.properties
EOF

ConfigMap object बनाने के लिए kustomization डायरेक्टरी apply करें।

kubectl apply -k .

configmap/game-config-5-m67dt67794 created

literals से ConfigMap generate करें

यह उदाहरण दिखाता है कि Kustomize और kubectl का उपयोग करके दो literal key/value pairsspecial.type=charm और special.how=very से ConfigMap कैसे बनाया जाए।इसके लिए आप ConfigMap generator specify कर सकते हैं। kustomization.yaml बनाएं (या replace करें),ताकि उसका content नीचे जैसा हो:

---
# kustomization.yaml contents for creating a ConfigMap from literals
configMapGenerator:
- name: special-config-2
  literals:
  - special.how=very
  - special.type=charm

ConfigMap object बनाने के लिए kustomization डायरेक्टरी apply करें:

kubectl apply -k .

configmap/special-config-2-c92b5mmcf2 created

अंतरिम सफ़ाई

आगे बढ़ने से पहले, बनाए गए कुछ ConfigMaps को साफ़ करें:

kubectl delete configmap special-config
kubectl delete configmap env-config
kubectl delete configmap -l 'game-config in (config-4,config-5)'

अब आपने ConfigMap परिभाषित करना सीख लिया है, तो आप अगले सेक्शन में जाकर सीख सकते हैं कि Pods के साथ इन ऑब्जेक्ट्स का उपयोग कैसे करें।

ConfigMap डेटा का उपयोग करके कंटेनर environment variables परिभाषित करें

एक single ConfigMap के डेटा से कंटेनर environment variable परिभाषित करें

  1. ConfigMap में key-value pair के रूप में एक environment variable परिभाषित करें:

    kubectl create configmap special-config --from-literal=special.how=very

  2. ConfigMap में परिभाषित special.how मान को Pod specification में SPECIAL_LEVEL_KEY environment variable को असाइन करें।

    pods/pod-single-configmap-env-variable.yaml 
    apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox:1.27.2
      command: [ "/bin/sh", "-c", "env" ]
      env:
        # Define the environment variable
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              # The ConfigMap containing the value you want to assign to SPECIAL_LEVEL_KEY
              name: special-config
              # Specify the key associated with the value
              key: special.how
  restartPolicy: Never

    Pod बनाएं:

    kubectl create -f https://kubernetes.io/examples/pods/pod-single-configmap-env-variable.yaml

    अब Pod के आउटपुट में environment variable SPECIAL_LEVEL_KEY=very शामिल होगा।

कई ConfigMaps के डेटा से कंटेनर environment variables परिभाषित करें

पिछले उदाहरण की तरह पहले ConfigMaps बनाएं।यहाँ वह manifest है जिसका आप उपयोग करेंगे:

configmap/configmaps.yaml 
apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: env-config
  namespace: default
data:
  log_level: INFO

  • ConfigMap बनाएं:

    kubectl create -f https://kubernetes.io/examples/configmap/configmaps.yaml

  • Pod specification में environment variables परिभाषित करें।

    pods/pod-multiple-configmap-env-variable.yaml 
    apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox:1.27.2
      command: [ "/bin/sh", "-c", "env" ]
      env:
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.how
        - name: LOG_LEVEL
          valueFrom:
            configMapKeyRef:
              name: env-config
              key: log_level
  restartPolicy: Never

    Pod बनाएं:

    kubectl create -f https://kubernetes.io/examples/pods/pod-multiple-configmap-env-variable.yaml

    अब Pod के आउटपुट में environment variables SPECIAL_LEVEL_KEY=very और LOG_LEVEL=INFO शामिल होंगे।

    आगे बढ़ने के बाद, वह Pod और ConfigMap हटा दें:

    kubectl delete pod dapi-test-pod --now
kubectl delete configmap special-config
kubectl delete configmap env-config

ConfigMap में मौजूद सभी key-value pairs को कंटेनर environment variables के रूप में कॉन्फ़िगर करें

  • कई key-value pairs वाला एक ConfigMap बनाएं।

    configmap/configmap-multikeys.yaml 
    apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  SPECIAL_LEVEL: very
  SPECIAL_TYPE: charm

    ConfigMap बनाएं:

    kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml

  • envFrom का उपयोग करके ConfigMap के सभी डेटा को कंटेनर environment variables के रूप में परिभाषित करें।ConfigMap की key, Pod में environment variable नाम बन जाती है।

    pods/pod-configmap-envFrom.yaml 
    apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox:1.27.2
      command: [ "/bin/sh", "-c", "env" ]
      envFrom:
      - configMapRef:
          name: special-config
  restartPolicy: Never

    Pod बनाएं:

    kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-envFrom.yaml

    अब Pod के आउटपुट में environment variables SPECIAL_LEVEL=very औरSPECIAL_TYPE=charm शामिल होंगे।

    आगे बढ़ने के बाद, वह Pod हटा दें:

    kubectl delete pod dapi-test-pod --now

Pod commands में ConfigMap-परिभाषित environment variables का उपयोग करें

आप कंटेनर के command और args में ConfigMap-परिभाषित environment variables का उपयोग Kubernetes substitution syntax $(VAR_NAME) के साथ कर सकते हैं।

उदाहरण के लिए, नीचे दिया गया Pod manifest:

pods/pod-configmap-env-var-valueFrom.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox:1.27.2
      command: [ "/bin/echo", "$(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]
      env:
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: SPECIAL_LEVEL
        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: SPECIAL_TYPE
  restartPolicy: Never

उस Pod को चलाकर बनाएं:

kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-env-var-valueFrom.yaml

वह Pod test-container कंटेनर से नीचे दिया गया आउटपुट देता है:

kubectl logs dapi-test-pod

very charm

आगे बढ़ने के बाद, वह Pod हटा दें:

kubectl delete pod dapi-test-pod --now

ConfigMap डेटा को Volume में जोड़ें

फ़ाइलों से ConfigMap बनाएं में बताए अनुसार, जब आप--from-file का उपयोग करके ConfigMap बनाते हैं, तो filename, ConfigMap के data सेक्शन में store होने वाली key बन जाता है। फ़ाइल का content उस key की value बनता है।

इस सेक्शन के उदाहरण special-config नाम के ConfigMap को refer करते हैं:

configmap/configmap-multikeys.yaml 
apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  SPECIAL_LEVEL: very
  SPECIAL_TYPE: charm

ConfigMap बनाएं:

kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml

ConfigMap में stored डेटा से Volume populate करें

Pod specification के volumes सेक्शन में ConfigMap का नाम जोड़ें।इससे ConfigMap डेटा volumeMounts.mountPath द्वारा बताए गए डायरेक्टरी में जुड़ता है (इस उदाहरण में /etc/config)। command सेक्शन डायरेक्टरी की उन फ़ाइलों को सूचीबद्ध करता है जिनके नाम ConfigMap की keys से मेल खाते हैं।

pods/pod-configmap-volume.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox:1.27.2
      command: [ "/bin/sh", "-c", "ls /etc/config/" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        # Provide the name of the ConfigMap containing the files you want
        # to add to the container
        name: special-config
  restartPolicy: Never

Pod बनाएं:

kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume.yaml

जब Pod चलता है, तो ls /etc/config/ कमांड नीचे जैसा आउटपुट देता है:

SPECIAL_LEVEL
SPECIAL_TYPE

Text data को UTF-8 character encoding के साथ फ़ाइलों के रूप में expose किया जाता है।अगर आप कोई दूसरी character encoding उपयोग करना चाहते हैं, तो binaryData उपयोग करें(अधिक जानकारी के लिए ConfigMap object देखें)।

टिप्पणी:

अगर उस container image की /etc/config डायरेक्टरी में कोई फ़ाइलें मौजूद हैं, तो volume mount image की उन फ़ाइलों को inaccessible बना देगा।

आगे बढ़ने के बाद, वह Pod हटा दें:

kubectl delete pod dapi-test-pod --now

Volume में ConfigMap डेटा को किसी specific path पर जोड़ें

specific ConfigMap items के लिए इच्छित फ़ाइल पथ बताने हेतु path फ़ील्ड उपयोग करें।इस केस में SPECIAL_LEVEL item, config-volume volume में /etc/config/keys पर mount होगा।

pods/pod-configmap-volume-specific-key.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox:1.27.2
      command: [ "/bin/sh","-c","cat /etc/config/keys" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: special-config
        items:
        - key: SPECIAL_LEVEL
          path: keys
  restartPolicy: Never

Pod बनाएं:

kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume-specific-key.yaml

जब Pod चलता है, तो cat /etc/config/keys कमांड नीचे जैसा आउटपुट देता है:

very

सावधान:

पहले की तरह, /etc/config/ डायरेक्टरी में मौजूद सभी पहले की फ़ाइलें हट जाएँगी।

वह Pod हटा दें:

kubectl delete pod dapi-test-pod --now

keys को specific paths और file permissions पर project करें

आप keys को specific paths पर project कर सकते हैं। syntax के लिए Secrets गाइड के संबंधित सेक्शन को देखें।
आप keys के लिए POSIX permissions सेट कर सकते हैं। syntax के लिए Secrets गाइड के संबंधित सेक्शन को देखें।

वैकल्पिक संदर्भ

ConfigMap reference को optional के रूप में चिह्नित किया जा सकता है। अगर ConfigMap मौजूद नहीं है,तो mounted volume खाली होगा। अगर ConfigMap मौजूद है लेकिन referenced key मौजूद नहीं है, तो mount point के नीचे वह path मौजूद नहीं होगा। अधिक जानकारी के लिए Optional ConfigMaps देखें।

Mounted ConfigMaps अपने-आप अपडेट होते हैं

जब mounted ConfigMap अपडेट होता है, तो projected content भी eventually अपडेट हो जाता है।यह उस केस में भी लागू होता है जहाँ optional रूप से referenced ConfigMap, pod शुरू होने के बाद अस्तित्व में आता है।

Kubelet हर periodic sync पर जांचता है कि mounted ConfigMap fresh है या नहीं। हालांकि,current value लाने के लिए यह अपना local TTL-based cache इस्तेमाल करता है। परिणामस्वरूप,ConfigMap अपडेट होने के समय से लेकर pod में नई keys project होने तक कुल देरी अधिकतम kubelet sync period (डिफ़ॉल्ट 1 मिनट) + kubelet में ConfigMaps cache का TTL (डिफ़ॉल्ट 1 मिनट)जितनी हो सकती है। आप pod की किसी annotation को अपडेट करके तुरंत refresh ट्रिगर कर सकते हैं।

टिप्पणी:

subPath volume के रूप में ConfigMap का उपयोग करने वाला कंटेनर,ConfigMap updates प्राप्त नहीं करेगा।

ConfigMaps और Pods को समझना

ConfigMap API resource, configuration data को key-value pairs के रूप में store करता है। इस डेटा को pods में उपयोग किया जा सकता है या controllers जैसे system components के configurations देने के लिए।ConfigMap, Secrets जैसा है, लेकिन यह ऐसे strings के साथ काम करने का तरीका देता है जिनमें संवेदनशील जानकारी नहीं होती। उपयोगकर्ता और system components, दोनों ConfigMap में configuration data store कर सकते हैं।

टिप्पणी:

ConfigMaps को properties files को replace नहीं, बल्कि refer करना चाहिए। ConfigMap को Linux की/etc डायरेक्टरी और उसके content जैसी किसी चीज़ का प्रतिनिधित्व करने वाला समझें। उदाहरण के लिए,अगर आप ConfigMap से Kubernetes Volume बनाते हैं, तो ConfigMap का हर data item volume में एक अलग फ़ाइल के रूप में दर्शाया जाता है।

ConfigMap के data फ़ील्ड में configuration data होता है। नीचे दिए उदाहरण की तरह, यह साधारण भी हो सकता है(जैसे --from-literal से परिभाषित individual properties) या जटिल भी(जैसे --from-file से परिभाषित configuration files या JSON blobs)।

apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T19:14:38Z
  name: example-config
  namespace: default
data:
  # example of a simple property defined using --from-literal
  example.property.1: hello
  example.property.2: world
  # example of a complex property defined using --from-file
  example.property.file: |-
    property.1=value-1
    property.2=value-2
    property.3=value-3

जब kubectl ऐसे inputs से ConfigMap बनाता है जो ASCII या UTF-8 नहीं होते, तो टूल उन्हें ConfigMap के binaryData फ़ील्ड में रखता है, data में नहीं। text और binary दोनों data sources को एक ConfigMap में मिलाया जा सकता है।

अगर आप ConfigMap में binaryData keys (और उनकी values) देखना चाहते हैं, तो आपkubectl get configmap -o jsonpath='{.binaryData}' <name> चला सकते हैं।

Pods, data या binaryData में से किसी का उपयोग करने वाले ConfigMap से डेटा लोड कर सकते हैं।

वैकल्पिक ConfigMaps

आप Pod specification में ConfigMap reference को optional के रूप में चिह्नित कर सकते हैं।अगर ConfigMap मौजूद नहीं है, तो Pod में वह configuration जिसके लिए ConfigMap डेटा देता है (उदाहरण: environment variable, mounted volume) खाली रहेगा।अगर ConfigMap मौजूद है, लेकिन referenced key मौजूद नहीं है, तो डेटा भी खाली रहेगा।

उदाहरण के लिए, नीचे दिया Pod specification ConfigMap से environment variable को optional चिह्नित करता है:

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: ["/bin/sh", "-c", "env"]
      env:
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: a-config
              key: akey
              optional: true # mark the variable as optional
  restartPolicy: Never

अगर आप यह pod चलाते हैं और a-config नाम का ConfigMap मौजूद नहीं है, तो आउटपुट खाली होगा।अगर आप यह pod चलाते हैं और a-config नाम का ConfigMap मौजूद है लेकिन उसमें akey नाम की key नहीं है,तो आउटपुट फिर भी खाली होगा। अगर आप a-config ConfigMap में akey के लिए value सेट करते हैं,तो यह pod वह value प्रिंट करके terminate हो जाता है।

आप ConfigMap द्वारा प्रदान किए गए volumes और files को भी optional चिह्नित कर सकते हैं। Kubernetes,भले ही referenced ConfigMap या key मौजूद न हो, volume के mount paths हमेशा बनाता है। उदाहरण के लिए,नीचे दिया Pod specification ConfigMap को refer करने वाले volume को optional चिह्नित करता है:

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: ["/bin/sh", "-c", "ls /etc/config"]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: no-config
        optional: true # mark the source ConfigMap as optional
  restartPolicy: Never

प्रतिबंध

  • Pod specification में reference करने से पहले आपको ConfigMap object बनाना होगा।वैकल्पिक रूप से, Pod spec में ConfigMap reference को optional चिह्नित करें (देखेंOptional ConfigMaps)। अगर आप ऐसे ConfigMap को reference करते हैं जो मौजूद नहीं है और reference को optional नहीं चिह्नित करते, तो Pod शुरू नहीं होगा। इसी तरह ConfigMap में मौजूद न रहने वाली keys के references भी Pod को शुरू होने से रोकेंगे, जब तक कि आप key references को optional चिह्नित न करें।

  • अगर आप ConfigMaps से environment variables परिभाषित करने के लिए envFrom उपयोग करते हैं, तो invalid मानी जाने वाली keys skip कर दी जाती हैं। pod शुरू हो जाएगा, लेकिन invalid names event log(InvalidVariableNames) में रिकॉर्ड किए जाएंगे। log message हर skipped key की सूची देता है।उदाहरण के लिए:

    kubectl get events

    आउटपुट कुछ इस तरह होगा:

    LASTSEEN FIRSTSEEN COUNT NAME          KIND  SUBOBJECT  TYPE      REASON                            SOURCE                MESSAGE
0s       0s        1     dapi-test-pod Pod              Warning   InvalidEnvironmentVariableNames   {kubelet, 127.0.0.1}  Keys [1badkey, 2alsobad] from the EnvFrom configMap default/myconfig were skipped since they are considered invalid environment variable names.

  • ConfigMaps किसी विशेष Namespace में रहते हैं।Pods केवल उसी namespace के ConfigMaps को refer कर सकते हैं जिसमें वह Pod मौजूद है।

  • आप ConfigMaps का उपयोग static pods के लिए नहीं कर सकते, क्योंकि kubelet इसका समर्थन नहीं करता।

सफाई करना

आपके बनाए हुए ConfigMaps और Pods हटाएं:

kubectl delete configmaps/game-config configmaps/game-config-2 configmaps/game-config-3 \
               configmaps/game-config-env-file
kubectl delete pod dapi-test-pod --now

# You might already have removed the next set
kubectl delete configmaps/special-config configmaps/env-config
kubectl delete configmap -l 'game-config in (config-4,config-5)'

ConfigMap generate करने के लिए उपयोग की गई kustomization.yaml फ़ाइल हटाएं:

rm kustomization.yaml

अगर आपने configure-pod-container नाम की डायरेक्टरी बनाई थी और अब उसकी ज़रूरत नहीं है, तो उसे भी हटाएँ या उसे trash / deleted files location में ले जाएँ।

rm -r configure-pod-container

आगे क्या है

4.13 - Built-in Admission Controller कॉन्फ़िगर करके Pod Security Standards लागू करें

Kubernetes, Pod Security Standards को लागू करने के लिए एक built-in admission controller प्रदान करता है।आप इस admission controller को cluster-wide defaults औरexemptions सेट करने के लिए कॉन्फ़िगर कर सकते हैं।

शुरू करने से पहले

Kubernetes v1.22 में alpha release के बाद,Pod Security Admission Kubernetes v1.23 में beta रूप में default रूप से उपलब्ध हुआ।version 1.25 से आगे, Pod Security Admission सामान्य रूप से उपलब्ध (generally available) है।

संस्करण की जांच करने के लिए, लिखें kubectl version.

अगर आप Kubernetes 1.35 नहीं चला रहे हैं, तो आप इस पेज का वह documentation version चुन सकते हैं जो आपके चल रहे Kubernetes version से मेल खाता है।

Admission Controller कॉन्फ़िगर करें

टिप्पणी:

pod-security.admission.config.k8s.io/v1 configuration के लिए v1.25+ आवश्यक है।v1.23 और v1.24 के लिए v1beta1 उपयोग करें।v1.22 के लिए v1alpha1 उपयोग करें।
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
  configuration:
    apiVersion: pod-security.admission.config.k8s.io/v1 # see compatibility note
    kind: PodSecurityConfiguration
    # Defaults applied when a mode label is not set.
    #
    # Level label values must be one of:
    # - "privileged" (default)
    # - "baseline"
    # - "restricted"
    #
    # Version label values must be one of:
    # - "latest" (default) 
    # - specific version like "v1.35"
    defaults:
      enforce: "privileged"
      enforce-version: "latest"
      audit: "privileged"
      audit-version: "latest"
      warn: "privileged"
      warn-version: "latest"
    exemptions:
      # Array of authenticated usernames to exempt.
      usernames: []
      # Array of runtime class names to exempt.
      runtimeClasses: []
      # Array of namespaces to exempt.
      namespaces: []

टिप्पणी:

ऊपर दिया गया manifest, kube-apiserver के लिए --admission-control-config-file के माध्यम से specify करना होगा।

4.14 - Namespace Labels के साथ Pod Security Standards लागू करें

Namespaces को label करके Pod Security Standards लागू किए जा सकते हैं।तीन policiesprivileged (प्रिविलेज्ड), baseline (बेसलाइन) और restricted सुरक्षा स्पेक्ट्रम को व्यापक रूप से कवर करती हैं और इन्हें Pod Security admission controller द्वारा लागू किया जाता है।

शुरू करने से पहले

Pod Security Admission Kubernetes v1.23 में beta रूप में default रूप से उपलब्ध था।version 1.25 से आगे, Pod Security Admission सामान्य रूप से उपलब्ध (generally available) है।

संस्करण की जांच करने के लिए, लिखें kubectl version.

Namespace labels के साथ baseline Pod Security Standard अनिवार्य करना

यह manifest my-baseline-namespace नाम का Namespace परिभाषित करता है, जो:

  • ऐसे किसी भी pods को block करता है जो baseline policy requirements पूरी नहीं करते।
  • बनाए गए उन pods के लिए user-facing warning जनरेट करता है और audit annotation जोड़ता है जोrestricted policy requirements पूरी नहीं करते।
  • baseline और restricted policies के versions को v1.35 पर pin करता है।
apiVersion: v1
kind: Namespace
metadata:
  name: my-baseline-namespace
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: v1.35

    # We are setting these to our _desired_ `enforce` level.
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: v1.35
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: v1.35

kubectl label के साथ मौजूदा namespaces में labels जोड़ें

टिप्पणी:

जब enforce policy (या version) label जोड़ा या बदला जाता है, admission plugin namespace के हर pod को नई policy के विरुद्ध test करता है। उल्लंघन user को warnings के रूप में लौटाए जाते हैं।

namespaces के लिए security profile changes का प्रारंभिक मूल्यांकन करते समय --dry-run flag लगाना उपयोगी होता है।Pod Security Standard checks dry run mode में भी चलेंगी, जिससे आपको यह जानकारी मिलेगी कि नई policy मौजूदा pods को कैसे treat करेगी, बिना वास्तव में policy अपडेट किए।

kubectl label --dry-run=server --overwrite ns --all \
    pod-security.kubernetes.io/enforce=baseline

सभी namespaces पर लागू करना

अगर आप Pod Security Standards के साथ शुरुआत कर रहे हैं, तो एक उपयुक्त पहला कदम यह होगा कि सभी namespaces में baseline जैसे अधिक सख्त स्तर के लिए audit annotations कॉन्फ़िगर करें:

kubectl label --overwrite ns --all \
  pod-security.kubernetes.io/audit=baseline \
  pod-security.kubernetes.io/warn=baseline

ध्यान दें कि यह enforce level सेट नहीं कर रहा है, ताकि जिन namespaces का स्पष्ट रूप से मूल्यांकन नहीं हुआ है उन्हें अलग पहचाना जा सके। आप explicit enforce level के बिना namespaces को इस कमांड से सूचीबद्ध कर सकते हैं:

kubectl get namespaces --selector='!pod-security.kubernetes.io/enforce'

एक single namespace पर लागू करना

आप किसी specific namespace को भी अपडेट कर सकते हैं। यह कमांड my-existing-namespace मेंenforce=restricted policy जोड़ती है, और restricted policy version को v1.35 पर pin करती है।

kubectl label --overwrite ns my-existing-namespace \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=v1.35

5 - ट्यूटोरियल

प्रलेखन के इस खंड में ट्यूटोरियल हैं।ट्यूटोरियल दिखाता है कि किसी एकल कार्य से बड़े लक्ष्य को कैसे पूरा किया जाए।आमतौर पर एक ट्यूटोरियल में कई खंड होते हैं,जिनमें से प्रत्येक में चरणों के क्रम होते हैं।प्रत्येक ट्यूटोरियल से परिचित होने से पहले, हम आपको मानकीकृत शब्दावली पृष्ट को बुकमार्क करने की सलाह देते हैं।

मूलभूत

विन्यास

स्टेटलेस एप्लीकेशन

स्टेटफुल एप्लीकेशन

क्लस्टर

सर्विस

आगे क्या है

यदि आप एक ट्यूटोरियल लिखना चाहते हैं, तो ट्यूटोरियल पेज प्रकार के बारे में जानकारी के लिएसामग्री पृष्ठ प्रकार देखें।

5.1 - हेलो मिनीक्यूब

यह ट्यूटोरियल आपको मिनिक्यूब का उपयोग करते हुए कुबेरनेट्स पर एक सैम्पल ऐप चलाने का तरीका दिखाता है। ट्यूटोरियल एक कंटेनर छवि प्रदान करता है जो सभी अनुरोधों को प्रतिध्वनित करने के लिए NGINX का उपयोग करता है।

उद्देश्य

  • मिनीक्यूब में एक नमूना एप्लीकेशन डेप्लॉय करें।
  • ऐप को चलाएं।
  • एप्लिकेशन लॉग देखें।

शुरू करने से पहले

यह ट्यूटोरियल मानता है कि आपने पहले ही मिनीक्यूब सेट कर लिया है।इंस्टॉलेशन निर्देशों के लिए मिनीक्यूब स्टार्ट में Step 1 देखें।

टिप्पणी:

केवल Step 1, इंस्टालेशन में दिए गए निर्देशों का पालन करें। बाकी निर्देश इस पेज पर कवर किया गया है।

आपको kubectl भी इंस्टॉल करना होगा। स्थापाना निर्देश के लिए Kubectl स्थापित करें देखें।

एक मिनीक्यूब क्लस्टर बनाएं

minikube start

कुबेरनेट्स डैशबोर्ड खोलें:

कुबेरनेट्स डैशबोर्ड खोलें। आप इसे दो अलग-अलग तरीकों से कर सकते हैं:

एक नया टर्मिनल खोलें, और चलाएँ:

# एक नया टर्मिनल प्रारंभ करें, और इस कमांड को चालू छोड़ दें।
minikube dashboard

अब, उस टर्मिनल पर वापस जाएँ जहाँ आपने minikube start चलाया था।

टिप्पणी:

dashboard कमांड डैशबोर्ड ऐड-ऑन को इस्तेमाल के लिए तैयार करता है और प्रॉक्सी को डिफ़ॉल्ट वेब ब्राउज़र में खोलता है।आप डैशबोर्ड पर कुबेरनेट्स संसाधन जैसे डेप्लॉयमेंट और सर्विस बना सकते हैं।

आमतौर पर, डैशबोर्ड केवल आंतरिक कुबेरनेट्स वर्चुअल नेटवर्क के भीतर से ही पहुँचा जा सकता है।डैशबोर्ड को कुबेरनेट्स वर्चुअल नेटवर्क के बाहर से एक्सेस करने योग्य बनाने के लिए dashboard कमांड एक अस्थायी प्रॉक्सी बनाता है।

प्रॉक्सी को रोकने और प्रक्रिया से बाहर निकलने के लिए Ctrl+C का प्रयोग करें।कमांड से बाहर निकलने के बाद, डैशबोर्ड कुबेरनेट्स क्लस्टर में चलता रहता है। आप डैशबोर्ड तक पहुंचने और प्रॉक्सी बनाने के लिए फिर से dashboard कमांड चला सकते हैं।

यदि आप वेब ब्राउज़र नहीं खोलना चाहते हैं, तो URL प्राप्त करने के लिए url फ़्लैग के साथ dashboard कमांड चलाएँ:

minikube dashboard --url

अब, उस टर्मिनल पर वापस जाएँ जहाँ आपने मिनीक्यूब स्टार्ट चलाया था।

डेप्लॉयमेंट बनाएँ

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

  1. पॉड को प्रबंधित करने वाला डेप्लॉयमेंट बनाने के लिए kubectl create कमांड का उपयोग करें। पॉड प्रदान की गई डॉकर इमेज के आधार पर एक कंटेनर चलाता है।

    kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.53 -- /agnhost netexec --http-port=8080

  2. डेप्लॉयमेंट देखें:

    kubectl get deployments

    आउटपुट कुछ इस समान होगा:

    NAME         READY   UP-TO-DATE   AVAILABLE   AGE
hello-node   1/1     1            1           1m

  3. पॉड देखें:

    kubectl get pods

    आउटपुट कुछ इस समान होगा:

    NAME                          READY     STATUS    RESTARTS   AGE
hello-node-5f76cf6ccf-br9b5   1/1       Running   0          1m

  4. क्लस्टर इवेंट देखें:

    kubectl get events

  5. kubectl कॉन्फ़िगरेशन देखें:

    kubectl config view

टिप्पणी:

kubectl कमांड के बारे में अधिक जानकारी के लिए kubectl अवलोकन देखें।

सर्विस बनाएं

आमतौर पर, पॉड कुबेरनेट्स क्लस्टर के भीतर अपने आंतरिक IP पते से ही पहुँचा जा सकता है।hello-node कंटेनर को कुबेरनेट्स वर्चुअल नेटवर्क के बाहर से सुलभ बनाने के लिए,पॉड को कुबेरनेट्स सर्विस के रूप में बेनकाब करना होगा।

  1. kubectl expose कमांड का उपयोग करके पॉड को सार्वजनिक इंटरनेट पर एक्सपोज़ करें:

    kubectl expose deployment hello-node --type=LoadBalancer --port=8080

    --type=LoadBalancer फ्लैग इंगित करता है कि आप क्लस्टर के बाहर अपने सर्विस को प्रदर्शित करना चाहते हैं।

    इमेज के अंदर एप्लिकेशन कोड registry.k8s.io/echoserver केवल TCP पोर्ट 8080 पर सुनता है। यदि आपने किसी भिन्न पोर्ट को एक्सपोज़ करने के लिए kubectl एक्सपोज़ का उपयोग किया है, तो क्लाइंट उस अन्य पोर्ट से जुड़ नहीं सकते।

  2. आपके द्वारा बनाई गई सर्विस देखें:

    kubectl get service

    आउटपुट कुछ इस समान होगा:

    NAME         TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
hello-node   LoadBalancer   10.108.144.78   <pending>     8080:30369/TCP   21s
kubernetes   ClusterIP      10.96.0.1       <none>        443/TCP          23m

    लोड बैलेंसर्स का समर्थन करने वाले क्लाउड प्रदाताओं पर, सर्विस तक पहुंचने के लिए एक बाहरी IP पते का प्रावधान किया जाएगा। मिनीक्यूब पर,LoadBalancer टाइप minikube service कमांड से सर्विस को पहुंच योग्य बनाता है।

  3. इस कमांड को चलायें:

    minikube service hello-node

    यह कमांड एक ब्राउज़र विंडो खोलता है जो ऐप की प्रतिक्रिया दिखाती है।

ऐडऑन सक्षम करें

मिनीक्यूब टूल में बिल्ट-इन ऐडऑन (add on) का एक समूह शामिल है जिसे स्थानीय कुबेरनेट्स वातावरण में सक्षम, अक्षम और खोला जा सकता है।

  1. वर्तमान में उपलब्ध ऐडऑन की सूची:

    minikube addons list

    आउटपुट कुछ इस समान होगा:

    addon-manager: enabled
dashboard: enabled
default-storageclass: enabled
efk: disabled
freshpod: disabled
gvisor: disabled
helm-tiller: disabled
ingress: disabled
ingress-dns: disabled
logviewer: disabled
metrics-server: disabled
nvidia-driver-installer: disabled
nvidia-gpu-device-plugin: disabled
registry: disabled
registry-creds: disabled
storage-provisioner: enabled
storage-provisioner-gluster: disabled

  2. एक ऐडऑन सक्षम करें, उदाहरण के लिए, metrics-server:

    minikube addons enable metrics-server

    आउटपुट कुछ इस समान होगा:

    The 'metrics-server' addon is enabled

  3. आपके द्वारा बनाई गई पॉड और सर्विस देखें:

    kubectl get pod,service -n kube-system

    आउटपुट कुछ इस समान होगा:

    NAME                                        READY     STATUS    RESTARTS   AGE
pod/coredns-5644d7b6d9-mh9ll                1/1       Running   0          34m
pod/coredns-5644d7b6d9-pqd2t                1/1       Running   0          34m
pod/metrics-server-67fb648c5                1/1       Running   0          26s
pod/etcd-minikube                           1/1       Running   0          34m
pod/influxdb-grafana-b29w8                  2/2       Running   0          26s
pod/kube-addon-manager-minikube             1/1       Running   0          34m
pod/kube-apiserver-minikube                 1/1       Running   0          34m
pod/kube-controller-manager-minikube        1/1       Running   0          34m
pod/kube-proxy-rnlps                        1/1       Running   0          34m
pod/kube-scheduler-minikube                 1/1       Running   0          34m
pod/storage-provisioner                     1/1       Running   0          34m

NAME                           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
service/metrics-server         ClusterIP   10.96.241.45    <none>        80/TCP              26s
service/kube-dns               ClusterIP   10.96.0.10      <none>        53/UDP,53/TCP       34m
service/monitoring-grafana     NodePort    10.99.24.54     <none>        80:30002/TCP        26s
service/monitoring-influxdb    ClusterIP   10.111.169.94   <none>        8083/TCP,8086/TCP   26s

  4. metrics-serverअक्षम करें:

    minikube addons disable metrics-server

    आउटपुट कुछ इस समान होगा:

    metrics-server was successfully disabled

साफ - सफाई

अब आप अपने क्लस्टर में बनाए गए संसाधनों को साफ कर सकते हैं:

kubectl delete service hello-node
kubectl delete deployment hello-node

वैकल्पिक रूप से, मिनिक्यूब वर्चुअल मशीन (VM) को बंद करें:

minikube stop

वैकल्पिक रूप से, मिनिक्यूब VM को डिलीट करें:

minikube delete

आगे क्या है

5.2 - बुनियादी कुबेरनेट्स सीखें

बुनियादी कुबेरनेट्स

यह ट्यूटोरियल कुबेरनेट्स क्लस्टर ऑर्केस्ट्रेशन सिस्टम की मूल बातों का पूर्वाभ्यास प्रदान करता है। प्रत्येक मॉड्यूल में कुबेरनेट्स की प्रमुख विशेषताओं और अवधारणाओं पर कुछ जानकारी और एक इंटरैक्टिव ऑनलाइन ट्यूटोरियल शामिल होते हैं। ये इंटरेक्टिव ट्यूटोरियल आपको अपने लिए एक साधारण क्लस्टर और इसके कंटेनरीकृत एप्लीकेशन का प्रबंधन करने देते हैं।

इंटरैक्टिव ट्यूटोरियल का उपयोग करके, आप सीख सकते हैं:

  • एक क्लस्टर पर कंटेनरीकृत एप्लीकेशन डिप्लॉय करें।
  • डिप्लॉयमेंट को स्केल करें।
  • नए सॉफ़्टवेयर संस्करण के साथ कंटेनरीकृत एप्लिकेशन को अपडेट करें।
  • कंटेनरीकृत एप्लिकेशन को डीबग करें।

कुबेरनेट्स आपके लिए क्या कर सकता है?

आधुनिक वेब सेवाओं के साथ उपयोगकर्ता उम्मीद करते हैं कि एप्लिकेशन 24/7 उपलब्ध होंगे, और डेवलपर्स उन एप्लिकेशन के नए संस्करणों को दिन में कई बार डिप्लॉय करने की उम्मीद करते हैं। कंटेनरीकरण पैकेज सॉफ़्टवेयर को इन लक्ष्यों को पूरा करने में मदद करता है, जिससे एप्लिकेशन बिना डाउनटाइम के रिलीज़ और अपडेट किए जा सकते हैं। कुबेरनेट्स आपको यह सुनिश्चित करने में मदद करता है कि वे कंटेनरीकृत एप्लिकेशन जहां और जब आप चाहते हैं, चलते हैं, और उन्हें उन संसाधनों और उपकरणों को खोजने में मदद करते हैं जिनकी उन्हें काम करने के लिए आवश्यकता होती है। कुबेरनेट्स एक उत्पादन के लिए तैयार, ओपन सोर्स प्लेटफॉर्म है जिसे कंटेनर ऑर्केस्ट्रेशन में गूगल के संचित अनुभव के साथ डिज़ाइन किया गया है और समुदाय के उत्तम विचारों से संयुक्त है।


बुनियादी कुबेरनेट्स मॉड्यूल

1. कुबेरनेट्स क्लस्टर बनाएं
2. ऐप डिप्लॉय करें
3. अपना ऐप एक्सप्लोर करें
4. अपने ऐप को सार्वजनिक रूप से एक्सपोज़ करें
5. अपना ऐप स्केल करें
6. अपना ऐप अपडेट करें

5.2.1 - एक क्लस्टर बनाएं

कुबेरनेट्स क्लस्टर के बारे में जानें और मिनिक्यूब का उपयोग करके एक सरल क्लस्टर बनाएं।

5.2.1.1 - Minikube का उपयोग कर क्लस्टर बनाना

उद्देश्य

  • जानें कुबेरनेट्स क्लस्टर क्या है।
  • जानें मिनिक्यूब क्या है।
  • अपने कंप्यूटर पर Kubernetes क्लस्टर प्रारंभ करें।

कुबेरनेट्स क्लस्टर

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

कुबेरनेट्स क्लस्टर में दो प्रकार के संसाधन होते हैं:

  • कंट्रोल प्लेन क्लस्टर का समन्वय करता है
  • नोड्स वे कर्मचारी हैं जो एप्लिकेशन चलाते हैं

सारांश:

  • कुबेरनेट्स क्लस्टर
  • मिनिक्यूब

कुबेरनेट्स एक प्रोडक्शन-ग्रेड, ओपन-सोर्स प्लेटफॉर्म है जो कंप्यूटर क्लस्टर के भीतर और उसके भीतर एप्लिकेशन कंटेनरों के प्लेसमेंट (शेड्यूलिंग) और निष्पादन को व्यवस्थित करता है।


क्लस्टर आरेख


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

नोड एक VM या एक भौतिक कंप्यूटर है जो कुबेरनेट्स क्लस्टर में एक वर्कर मशीन के रूप में कार्य करता है। प्रत्येक नोड में एक kubelet होता है, जो नोड के प्रबंधन और कुबेरनेट्स नियंत्रण के साथ संचार करने के लिए एक एजेंट है। नोड में कंटेनर संचालन को संभालने के लिए उपकरण भी होने चाहिए, जैसे कि containerd या Docker। उत्पादन ट्रैफ़िक को संभालने वाले कुबेरनेट्स क्लस्टर में कम से कम तीन नोड होने चाहिए।

कंट्रोल प्लेन क्लस्टर और नोड्स को मैनेज करते हैं जिनका उपयोग रनिंग एप्लिकेशन को होस्ट करने के लिए किया जाता है।

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

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

अब जब आप कुबेरनेट्स के बारे में अधिक जान गए हैं, तो इसे अपने कंप्यूटर पर आज़माने के लिए हेलो मिनिक्यूब पर जाएं।


एक बार जब आप ऐसा कर लें, तो kubectl का उपयोग करके डिप्लॉयमेंट कैसे बनाएं पर जाएँ|

5.2.2 - डिप्लॉय ऐप

5.2.2.1 - डिप्लॉयमेंट बनाने के लिए kubectl का उपयोग करना

उद्देश्यों

  • एप्लिकेशन डिप्लॉयमेंट के बारे में जानें।
  • कुबेरनेट्स पर kubectl के साथ अपना पहला ऐप डिप्लॉय करें।

कुबेरनेट्स डिप्लॉयमेंट

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

एक बार एप्लिकेशन इंस्टेंस बन जाने के बाद, कुबेरनेट्स डिप्लॉयमेंट कंट्रोलर लगातार उन इंस्टेंस की निगरानी करता है। यदि किसी इंस्टेंस को होस्ट करने वाला नोड बंद हो जाता है या हटा दिया जाता है, तो डिप्लॉयमेंट कंट्रोलर क्लस्टर में इंस्टेंस को किसी अन्य नोड के इंस्टेंस से बदल देता है। यह मशीन की विफलता या रख - रखाव को दूर करने के लिए एक स्व-उपचार तंत्र प्रदान करता है।

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

सारांश:

  • डिप्लॉयमेंट
  • kubectl

आपके एप्लिकेशन के इंस्टेंस बनाने और अपडेट करने के लिए एक डिप्लॉयमेंट जिम्मेदार है


कुबेरनेट्स पर अपना पहला ऐप डिप्लॉय करें


आप कुबेरनेट्स कमांड लाइन इंटरफेस, kubectl का उपयोग करके डिप्लॉयमेंट बना और प्रबंधित कर सकते हैं। kubectl क्लस्टर के साथ बातचीत करने के लिए कुबेरनेट्स एपीआई का उपयोग करता है। इस मॉड्यूल में, आप कुबेरनेट्स क्लस्टर पर आपके एप्लिकेशन चलाने वाले डिप्लॉयमेंट बनाने के लिए आवश्यक सबसे सामान्य kubectl कमांड सीखेंगे।

जब आप कोई डिप्लॉयमेंट बनाते हैं, तो आपको अपने एप्लिकेशन के लिए कंटेनर इमेज और चलाने के लिए इच्छित प्रतिकृतियों की संख्या निर्दिष्ट करने की आवश्यकता होगी। आप अपने कामकाज को अपडेट करके बाद में उस जानकारी को बदल सकते हैं; बूटकैंप के मॉड्यूल 5 और 6 चर्चा करते हैं कि आप अपने डिप्लॉयमेंट को कैसे स्केल और अपडेट कर सकते हैं।

कुबेरनेट्स पर डिप्लॉयड होने के लिए एप्लीकेशन को समर्थित कंटेनर प्रारूपों में से एक में पैक करने की आवश्यकता है

अपने पहले डिप्लॉयमेंट के लिए, आप एक डॉकर कंटेनर में पैक किए गए हैलो-नोड एप्लिकेशन का उपयोग करेंगे जो सभी अनुरोधों को प्रतिध्वनित करने के लिए NGINX का उपयोग करता है। (यदि आपने पहले से हैलो-नोड एप्लिकेशन बनाने और कंटेनर का उपयोग करके इसे तैनात करने का प्रयास नहीं किया है, तो आप पहले हेलो Minikube ट्यूटोरियल के निर्देशों का पालन करके ऐसा कर सकते हैं)।

आपको kubectl भी इंस्टॉल करना होगा। यदि आपको इसे इंस्टॉल करने की आवश्यकता है, तो इंस्टॉल टूल्स पर जाएं।

अब जब आप जान गए हैं कि डिप्लॉयमेंट क्या हैं, तो आइए अपना पहला ऐप परिनियोजित करें!


kubectl की मूल बातें

कुबेक्टल कमांड का सामान्य प्रारूप है: kubectl action resource

यह निर्दिष्ट संसाधन (जैसे नोड या डिप्लॉयमेंट ) पर निर्दिष्ट क्रिया (जैसे बनाना, वर्णन करना या हटाना) करता है। आप संभावित मापदंडों के बारे में अतिरिक्त जानकारी प्राप्त करने के लिए उपकमांड के बाद --help का उपयोग कर सकते हैं (उदाहरण के लिए: kubectl get nodes --help)।

kubectl version कमांड चलाकर जांचें कि kubectl आपके क्लस्टर से बात करने के लिए कॉन्फ़िगर किया गया है।

जांचें कि kubectl स्थापित है और आप क्लाइंट और सर्वर दोनों संस्करण देख सकते हैं।

क्लस्टर में नोड्स देखने के लिए, kubectl get nodes कमांड चलाएँ।

आप उपलब्ध नोड्स देखते हैं। बाद में, Kubernetes नोड उपलब्ध संसाधनों के आधार पर हमारे एप्लिकेशन को कहां तैनात करना है इसका चयन करेगा।

एक ऐप तैनात करें

आइए अपना पहला ऐप कुबेरनेट्स पर kubectl create deployment कमांड के साथ तैनात करें। हमें डिप्लॉयमेंट नाम और ऐप छवि स्थान प्रदान करने की आवश्यकता है (डॉकर हब के बाहर होस्ट की गई छवियों के लिए पूर्ण रिपॉजिटरी यूआरएल शामिल करें)।

kubectl create deployment Kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1

बहुत बढ़िया! आपने अभी-अभी एक डिप्लॉयमेंट बनाकर अपना पहला एप्लिकेशन डेप्लॉये किया है। इसने आपके लिए कुछ चीज़ें निष्पादित कीं:

  • एक उपयुक्त नोड की खोज की गई जहां एप्लिकेशन का एक उदाहरण चलाया जा सके (हमारे पास केवल 1 उपलब्ध नोड है)
  • एप्लिकेशन को उस नोड पर चलने के लिए शेड्यूल किया
  • आवश्यकता पड़ने पर नए नोड पर इंस्टेंस को पुनर्निर्धारित करने के लिए क्लस्टर को कॉन्फ़िगर किया गया

अपने डिप्लॉयमेंट को सूचीबद्ध करने के लिए kubectl get deployment कमांड का उपयोग करें:

kubectl get deployments

हम देखते हैं कि आपके ऐप का एक इंस्टेंस 1 डिप्लॉयमेंट चला रहा है। इंस्टेंस आपके नोड पर एक कंटेनर के अंदर चल रहा है।

ऐप देखें

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

हम बाद में मॉड्यूल 4 में कुबेरनेट्स क्लस्टर के बाहर आपके एप्लिकेशन को प्रदर्शित करने के अन्य विकल्पों पर चर्चा करेंगे।

kubectl proxy कमांड एक प्रॉक्सी बना सकता है जो संचार को क्लस्टर-वाइड, निजी नेटवर्क में अग्रेषित करेगा। प्रॉक्सी को कंट्रोल-सी दबाकर समाप्त किया जा सकता है और यह चलने के दौरान कोई आउटपुट नहीं दिखाएगा।

प्रॉक्सी चलाने के लिए आपको दूसरी टर्मिनल विंडो खोलनी होगी।

kubectl proxy

अब हमारे होस्ट (टर्मिनल) और कुबेरनेट्स क्लस्टर के बीच एक कनेक्शन है। प्रॉक्सी इन टर्मिनलों से एपीआई तक सीधी पहुंच सक्षम बनाता है।

आप प्रॉक्सी एंडपॉइंट के माध्यम से होस्ट किए गए सभी एपीआई देख सकते हैं। उदाहरण के लिए, हम curl कमांड का उपयोग करके सीधे API के माध्यम से संस्करण को क्वेरी कर सकते हैं:

curl http://localhost:8001/version

एपीआई सर्वर स्वचालित रूप से पॉड नाम के आधार पर प्रत्येक पॉड के लिए एक एंडपॉइंट बनाएगा, जिसे प्रॉक्सी के माध्यम से भी एक्सेस किया जा सकता है।

सबसे पहले हमें पॉड नाम प्राप्त करने की आवश्यकता है, और हम पर्यावरण चर POD_NAME में संग्रहित करेंगे:

export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{ {end}}')
echo पॉड का नाम: $POD_NAME

आप निम्न चलाकर प्रॉक्सी एपीआई के माध्यम से पॉड तक पहुंच सकते हैं:

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME/

नए डिप्लॉयमेंट को प्रॉक्सी का उपयोग किए बिना पहुंच योग्य बनाने के लिए, एक सेवा की आवश्यकता होती है जिसे मॉड्यूल 4 में समझाया जाएगा .

एक बार जब आप तैयार हो जाएं, तो पॉड्स और नोड्स देखना पर आगे बढ़ें।

5.2.3 - ऐप का अन्वेषण करें

5.2.3.1 - पॉड्स और नोड्स की जांच करना

उद्देश्य

  • कुबेरनेट्स पॉड्स के बारे में जानें।
  • कुबेरनेट्स नोड्स के बारे में जानें।
  • डिप्लॉयड एप्लीकेशन का समस्या निवारण करें।

कुबेरनेट्स पॉड्स

जब आपने मॉड्यूल 2 में एक एप्लीकेशन बनाया, तो कुबेरनेट्स ने आपके एप्लिकेशन इंस्टेंस को होस्ट करने के लिए एक पॉड बनाया। पॉड एक कुबेरनेट्स एब्स्ट्रैक्शन है जो एक या अधिक एप्लिकेशन कंटेनरों (जैसे डॉकर) के समूह और उन कंटेनरों के लिए कुछ साझा संसाधनों का प्रतिनिधित्व करता है। उन संसाधनों में शामिल हैं:

  • साझा स्टोरेज, वॉल्यूम के रूप में
  • नेटवर्किंग, एक अद्वितीय क्लस्टर IP पते के रूप में
  • प्रत्येक कंटेनर को चलाने के तरीके के बारे में जानकारी, जैसे कंटेनर इमेज संस्करण या उपयोग करने के लिए विशिष्ट पोर्ट

एक पॉड एक एप्लिकेशन-विशिष्ट "लॉजिकल होस्ट" मॉडल करता है और इसमें विभिन्न एप्लिकेशन कंटेनर हो सकते हैं जो अपेक्षाकृत कसकर युग्मित होते हैं। उदाहरण के लिए, एक पॉड में आपके Node.js ऐप के साथ-साथ एक अलग कंटेनर दोनों शामिल हो सकते हैं जो Node.js वेबसर्वर द्वारा प्रकाशित किए जाने वाले डेटा को फीड करता है। पॉड में कंटेनर एक IP एड्रेस और पोर्ट स्पेस साझा करते हैं जो हमेशा सह-स्थित और सह-अनुसूचित होते हैं, और एक ही नोड पर एक साझा संदर्भ में चलते हैं।

कुबेरनेट्स प्लेटफॉर्म पर पॉड्स सबसे छोटे इकाई हैं। जब हम कुबेरनेट्स पर एक डिप्लॉयमेंट बनाते हैं, तो वह डिप्लॉयमेंट अपने अंदर कंटेनरों के साथ पॉड बनाता है (नाकि सीधे कंटेनर)। प्रत्येक पॉड उस नोड से जुड़ा होता है जहां वह निर्धारित होता है, और समाप्ति (रीस्टार्ट नीति के अनुसार) या विलोपन तक वहीं रहता है। नोड की विफलता के मामले में, क्लस्टर में अन्य उपलब्ध नोड्स पर समान पॉड्स शेड्यूल किए जाते हैं।

सारांश:

  • पॉड्स
  • नोड्स
  • kubectl के मुख्य कमांड

एक पॉड एक या एक से अधिक एप्लिकेशन कंटेनरों (जैसे डॉकर) का एक समूह है और इसमें साझा स्टोरेज (वॉल्यूम), IP पता और उन्हें चलाने के तरीके के बारे में जानकारी शामिल होती है ।


पॉड्स अवलोकन


नोड्स

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

प्रत्येक कुबेरनेट्स नोड पर कम से कम ये चलते हैं:

  • क्यूबलेट, कुबेरनेट्स कण्ट्रोल प्लेन और नोड के बीच संचार के लिए जिम्मेदार एक प्रक्रिया; यह पॉड्स और मशीन पर चलने वाले कंटेनरों का प्रबंधन करता है।
  • एक कंटेनर रनटाइम (जैसे डॉकर), एक रजिस्ट्री से कंटेनर इमेज को पुल करने, कंटेनर को अनपैक करने और एप्लिकेशन चलाने के लिए।

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


नोड अवलोकन


kubectl के साथ समस्या निवारण

मॉड्यूल 2 में, आपने कमांड लाइन इंटरफ़ेस का उपयोग किया है। डेप्लॉयड एप्लीकेशन और उनके एनवायरनमेंट के बारे में जानकारी प्राप्त करने के लिए आप मॉड्यूल 3 में इसका उपयोग करना जारी रखेंगे। सबसे आम ऑपरेशन निम्नलिखित kubectl कमांड के साथ किया जा सकता है:

  • kubectl get - संसाधनों की सूची बनाएं
  • kubectl describe - संसाधन के बारे में विस्तृत जानकारी दिखाएं
  • kubectl logs - पॉड में कंटेनर के लॉग प्रिंट करें
  • kubectl exec - पॉड में कंटेनर पर कमांड चलाए

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

अब जब हम अपने क्लस्टर कॉम्पोनेन्ट और कमांड लाइन के बारे में जानते हैं, तो आइए हमारे एप्लिकेशन को देखें।

कुबेरनेट्स में एक नोड एक कार्यकर्ता मशीन है और क्लस्टर के आधार पर एक वीएम या वर्चुअल मशीन हो सकती है। एक नोड पर कई पॉड चल सकते हैं।

एप्लिकेशन कॉन्फ़िगरेशन की जाँच करें

आइए सत्यापित करें कि पिछले परिदृश्य में हमने जो एप्लिकेशन तैनात किया था वह चल रहा है। हम kubectl get कमांड का उपयोग करेंगे और मौजूदा पॉड्स की तलाश करेंगे:

kubectl get pods

यदि कोई पॉड्स नहीं चल रहा है, तो कृपया कुछ सेकंड प्रतीक्षा करें और पॉड्स को फिर से सूचीबद्ध करें। एक बार जब आप एक पॉड को चलता हुआ देख लें तो आप जारी रख सकते हैं।

इसके बाद, यह देखने के लिए कि उस पॉड के अंदर कौन से कंटेनर हैं और उन कंटेनरों को बनाने के लिए कौन सी छवियों का उपयोग किया जाता है, हम kubectl describe pods कमांड चलाते हैं:

kubectl describe pods है

हम यहां पॉड के कंटेनर के बारे में विवरण देखते हैं: आईपी पता, उपयोग किए गए पोर्ट और पॉड के जीवनचक्र से संबंधित घटनाओं की एक सूची।

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

ध्यान दें : वर्णन उपकमांड का उपयोग नोड्स, पॉड्स और तैनाती सहित अधिकांश कुबेरनेट्स प्राइमेटिव्स के बारे में विस्तृत जानकारी प्राप्त करने के लिए किया जा सकता है। वर्णन आउटपुट को मानव पठनीय बनाने के लिए डिज़ाइन किया गया है, न कि इसके विरुद्ध स्क्रिप्ट किए जाने के लिए।

ऐप को टर्मिनल में दिखाएं

याद रखें कि पॉड्स एक अलग, निजी नेटवर्क में चल रहे हैं - इसलिए हमें प्रॉक्सी एक्सेस की आवश्यकता है उनके लिए ताकि हम डिबग कर सकें और उनके साथ बातचीत कर सकें। ऐसा करने के लिए, हम दूसरे टर्मिनल में प्रॉक्सी चलाने के लिए kubectl proxy कमांड का उपयोग करेंगे। एक नई टर्मिनल विंडो खोलें, और उस नए टर्मिनल में, चलाएँ:

kubectl proxy

अब फिर से, हम पॉड नाम प्राप्त करेंगे और उस पॉड को सीधे प्रॉक्सी के माध्यम से क्वेरी करेंगे। पॉड नाम प्राप्त करने और उसे POD_NAME पर्यावरण चर में संग्रहीत करने के लिए:

export POD_NAME='$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{'\n'}} {{end}}')"
echo "Name of Pod: $POD_NAME"

हमारे एप्लिकेशन का आउटपुट देखने के लिए, curl अनुरोध चलाएँ:

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME:8080/proxy/

url पॉड के एपीआई का मार्ग है।

कंटेनर लॉग देखें

कुछ भी जो एप्लिकेशन सामान्य रूप से मानक आउटपुट पर भेजता है वह पॉड के भीतर कंटेनर के लिए लॉग बन जाता है। हम kubectl logs कमांड का उपयोग करके इन लॉग्स को पुनः प्राप्त कर सकते हैं:

kubectl logs "$POD_NAME"

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

कंटेनर पर कमांड निष्पादित करना

पॉड चालू होने और चलने के बाद हम सीधे कंटेनर पर कमांड निष्पादित कर सकते हैं। इसके लिए, हम exec उपकमांड का उपयोग करते हैं और एक पैरामीटर के रूप में पॉड के नाम का उपयोग करते हैं। आइए पर्यावरण चरों को सूचीबद्ध करें:

kubectl exec "$POD_NAME" -- env

फिर से, यह उल्लेख करने योग्य है कि कंटेनर का नाम स्वयं छोड़ा जा सकता है क्योंकि हमारे पास पॉड में केवल एक ही कंटेनर है।

आगे आइए पॉड के कंटेनर में एक बैश सत्र शुरू करें:

kubectl exec -ti $POD_NAME -- bash

अब हमारे पास कंटेनर पर एक खुला कंसोल है जहां हम अपना NodeJS एप्लिकेशन चलाते हैं। ऐप का सोर्स कोड server.js फ़ाइल में है:

cat server.js

आप curl कमांड चलाकर जांच सकते हैं कि एप्लिकेशन चालू है:

curl http://localhost:8080

ध्यान दें : यहां हमने localhost का उपयोग किया है क्योंकि हमने NodeJS पॉड के अंदर कमांड निष्पादित किया है। यदि आप localhost:8080 से कनेक्ट नहीं हो सकते हैं, तो यह सुनिश्चित करने के लिए जांचें कि आपने kubectl exec कमांड चलाया है और पॉड के भीतर से कमांड लॉन्च कर रहे हैं

अपना कंटेनर कनेक्शन बंद करने के लिए, exit टाइप करें।

एक बार जब आप तैयार हो जाएं, तो आगे बढ़ें अपने ऐप को उजागर करने के लिए एक सेवा का उपयोग करना|

5.2.4 - अपने ऐप को सार्वजनिक रूप से एक्सपोस करें

5.2.4.1 - अपने ऐप को एक्सपोज़ करने के लिए किसी सर्विस का उपयोग करना

उद्देश्य

  • कुबेरनेट्स में सर्विस के बारे में जानें
  • समझें कि लेबल और लेबल चयनकर्ता ऑब्जेक्ट किसी सर्विस से कैसे संबंधित हैं
  • सर्विस का उपयोग करके कुबेरनेट्स क्लस्टर के बाहर किसी एप्लिकेशन को एक्सपोज़ करें

कुबेरनेट्स सर्विसों का अवलोकन

कुबेरनेट्स पॉड्स नश्वर हैं। पॉड में वास्तव में एक जीवनचक्र होता है। जब एक कार्यकर्ता नोड बंद हो जाता है, तो नोड पर चलने वाले पॉड भी खो जाते हैं। एक रेप्लिकासेट तब आपके एप्लिकेशन को चालू रखने के लिए नए पॉड्स के निर्माण करके क्लस्टर को वांछित स्थिति में वापस चला सकता है। एक अन्य उदाहरण के रूप में, 3 रेप्लिका के साथ एक इमेज प्रोसेसिंग बैकएंड पर विचार करें। वे रेप्लिका विनिमेय हैं; फ्रंट-एंड सिस्टम को बैकएंड रेप्लिका की परवाह नहीं करनी चाहिए या भले ही पॉड खो जाए और फिर से बनाया जाए। कुबेरनेट्स क्लस्टर में प्रत्येक पॉड का एक अद्वितीय IP पता होता है, यहां तक कि एक ही नोड पर पॉड्स के भी, इसलिए पॉड्स के बीच परिवर्तनों को स्वचालित रूप से समेटने का एक तरीका होना चाहिए ताकि आपके एप्लिकेशन कार्य करना जारी रखें।

कुबेरनेट्स में सर्विस एक अमूर्त है जो पॉड्स के तार्किक सेट और उन्हें एक्सेस करने के लिए एक निति परिभाषित करता है। सर्विस निर्भर पॉड्स के बीच एक युग्मन को सक्षम करती है। सभी कुबेरनेट्स ऑब्जेक्ट्स की तरह YAML (अधिमानित) या JSON का उपयोग करके एक सर्विस को परिभाषित किया जाता है। सर्विस द्वारा लक्षित पॉड्स का सेट आमतौर पर एक लेबल सेलेक्टर द्वारा निर्धारित किया जाता है (नीचे देखें कि आप selector शामिल किए बिना सर्विस क्यों उपयोग करना चाहेंगे।)

यद्यपि प्रत्येक पॉड का एक विशिष्ट आईपी पता होता है, लेकिन उन आईपी को सर्विस के बिना क्लस्टर के बाहर उजागर नहीं किया जाता है। सर्विस आपके एप्लिकेशन को ट्रैफ़िक प्राप्त करने देती हैं। ServiceSpec: में type निर्दिष्ट करके सर्विसों को अलग-अलग तरीकों से उजागर किया जा सकता है:

  • क्लस्टर IP (डिफ़ॉल्ट) - क्लस्टर में किसी आंतरिक IP पर सर्विस को एक्सपोज़ करें। यह प्रकार सर्विस को केवल क्लस्टर के भीतर से ही पहुंच योग्य बनाता है।
  • नोडपोर्ट - NAT का उपयोग करके क्लस्टर में प्रत्येक चयनित नोड के एक ही पोर्ट पर सेवा को प्रदर्शित करता है। <NodeIP>:<NodePort> का उपयोग करके किसी सेवा को क्लस्टर के बाहर से एक्सेस योग्य बनाता है। क्लस्टरआईपी का सुपरसेट।
  • लोड बैलेंसर - मौजूदा क्लाउड (यदि समर्थित हो) में एक बाहरी लोड बैलेंसर बनाता है और सर्विस को एक निश्चित, बाहरी आईपी असाइन करता है। नोडपोर्ट का सुपरसेट।
  • एक्सटर्नल-नाम - सेवा को externalName फ़ील्ड (जैसे foo.bar.example.com) की सामग्री से मैप करता है, एक लौटाकर CNAME अपने मान के साथ रिकॉर्ड करें। किसी भी प्रकार का कोई प्रॉक्सी सेट अप नहीं किया गया है। इस प्रकार के लिए v1.7 या उच्चतर kube-dns, या कोरडीएनएस संस्करण 0.0.8 या उच्चतर की आवश्यकता होती है।

विभिन्न प्रकार की सर्विसओं के बारे में अधिक जानकारी स्रोत आईपी का उपयोग करना ट्यूटोरियल में मिल सकती है। एप्लिकेशन को सर्विसओं से जोड़ना भी देखें।

इसके अतिरिक्त, ध्यान दें कि सर्विसओं के साथ कुछ उपयोग के मामले हैं जिनमें विनिर्देश में selector को परिभाषित नहीं करना शामिल है। selector के बिना बनाई गई सर्विस भी अनुरूप एंडपॉइन्ट ऑब्जेक्ट नहीं बनाएगी। यह उपयोगकर्ताओं को विशिष्ट एंडपॉइन्ट के लिए किसी सर्विस को मैन्युअल रूप से मैप करने की अनुमति देता है। एक और संभावना है कि कोई सलेक्टर क्यों नहीं हो सकता है, कि आप सख्ती से type: ExternalName का उपयोग कर रहे हैं।

सारांश

  • पॉड्स को बाहरी ट्रैफ़िक में एक्सपोज़ करना
  • एकाधिक पॉड्स में संतुलन ट्रैफ़िक लोड करें
  • लेबल का उपयोग

कुबेरनेट्स सर्विस एक अमूर्त परत है जो पॉड्स के तार्किक सेट को परिभाषित करती है और उन पॉड्स के लिए बाहरी ट्रैफ़िक एक्सपोज़र, लोड बैलेंसिंग और सर्विस डिस्कवरी को सक्षम बनाती है।


सेवाएं और लेबल

सेवा पॉड्स के एक सेट पर ट्रैफ़िक को रूट करती है। सेवाएँ अमूर्त हैं जो आपके एप्लिकेशन को प्रभावित किए बिना पॉड्स को कुबेरनेट्स में मरने और दोहराने की अनुमति देती हैं। निर्भर पॉड्स के बीच डिस्कवरी और रूटिंग (जैसे कि किसी एप्लिकेशन में फ्रंटएंड और बैकएंड कंपोनेंट्स) को कुबेरनेट्स सर्विसेज द्वारा नियंत्रित किया जाता है।

सर्विस लेबल और चयनकर्ताओं का उपयोग करके पॉड्स के एक सेट से मेल खाती हैं, एक समूहबद्ध आदिम जो Kubernetes में ऑब्जेक्ट पर तार्किक संचालन की अनुमति देता है . लेबल वस्तुओं से जुड़े कुंजी/मूल्य जोड़े होते हैं और इन्हें किसी भी तरह से उपयोग किया जा सकता है:

  • डिप्लॉयमेंट,परीक्षण और प्रोडक्शन के लिए वस्तुओं को नामित करें
  • संस्करण टैग जोड़ें
  • टैग का उपयोग करके ऑब्जेक्ट्स को वर्गीकृत करें


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

एक नई सेवा बनाएं

आइए सत्यापित करें कि हमारा एप्लिकेशन चल रहा है। हम kubectl get कमांड का उपयोग करेंगे और मौजूदा पॉड्स की तलाश करेंगे:

kubectl get pods

यदि कोई पॉड्स नहीं चल रहा है तो इसका मतलब है कि पिछले ट्यूटोरियल के ऑब्जेक्ट साफ़ कर दिए गए हैं। इस मामले में, वापस जाएं और परिनियोजन बनाने के लिए kubectl का उपयोग करके परिनियोजन को फिर से बनाएं। कृपया कुछ सेकंड प्रतीक्षा करें और पॉड्स को फिर से सूचीबद्ध करें। एक बार जब आप एक पॉड को चलता हुआ देख लें तो आप जारी रख सकते हैं।

इसके बाद, आइए अपने क्लस्टर से वर्तमान सेवाओं को सूचीबद्ध करें:

kubectl get services

हमारे पास kubernetes नामक एक सेवा है जो मिनीक्यूब के क्लस्टर शुरू करने पर डिफ़ॉल्ट रूप से बनाई जाती है। एक नई सेवा बनाने और उसे बाहरी ट्रैफ़िक में उजागर करने के लिए हम पैरामीटर के रूप में नोडपोर्ट के साथ एक्सपोज़ कमांड का उपयोग करेंगे।

kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --पोर्ट 8080

आइए फिर से get services उपकमांड चलाएँ:

kubectl get services

अब हमारे पास कुबेरनेट्स-बूटकैंप नामक एक चालू सेवा है। यहां हम देखते हैं कि सेवा को एक अद्वितीय क्लस्टर-आईपी, एक आंतरिक पोर्ट और एक बाहरी-आईपी (नोड का आईपी) प्राप्त हुआ।

यह पता लगाने के लिए कि कौन सा पोर्ट बाहरी रूप से खोला गया था (प्रकार: NodePort सेवा के लिए) हम describe service उपकमांड चलाएंगे:

kubectl describe services/kubernetes-bootcamp

NODE_PORT नामक एक पर्यावरण चर बनाएं जिसमें निर्दिष्ट नोड पोर्ट का मान हो:

export NODE_PORT='$(kubectl getservices/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')'
echo "NODE_PORT=$NODE_PORT"

अब हम curl, नोड के आईपी पते और बाहरी रूप से उजागर पोर्ट का उपयोग करके परीक्षण कर सकते हैं कि ऐप क्लस्टर के बाहर प्रदर्शित है:

कर्ल http://'$(minikube ip):$NODE_PORT'

टिप्पणी:

यदि आप कंटेनर ड्राइवर के रूप में डॉकर डेस्कटॉप के साथ मिनीक्यूब चला रहे हैं, तो एक मिनीक्यूब सुरंग की आवश्यकता है। ऐसा इसलिए है क्योंकि डॉकर डेस्कटॉप के अंदर के कंटेनर आपके होस्ट कंप्यूटर से अलग होते हैं।

एक अलग टर्मिनल विंडो में, निष्पादित करें:
minikube services kubernetes-bootcamp --url

आउटपुट इस तरह दिखता है: 

http://127.0.0.1:51082
! क्योंकि आप डार्विन पर डॉकर ड्राइवर का उपयोग कर रहे हैं, इसे चलाने के लिए टर्मिनल का खुला होना आवश्यक है।

फिर ऐप तक पहुंचने के लिए दिए गए यूआरएल का उपयोग करें:
कर्ल 127.0.0.1:51082

और हमें सर्वर से प्रतिक्रिया मिलती है। सेवा उजागर हो गई है.

लेबल का उपयोग करना

परिनियोजन ने स्वचालित रूप से हमारे पॉड के लिए एक लेबल बनाया। <कोड>परिनियोजन का वर्णन करें उपकमांड के साथ आप उस लेबल का नाम (कुंजी) देख सकते हैं:

kubectl describe deployments

आइए पॉड्स की हमारी सूची के बारे में पूछताछ करने के लिए इस लेबल का उपयोग करें। हम एक पैरामीटर के रूप में kubectl get pods कमांड का उपयोग -l के साथ करेंगे, जिसके बाद लेबल मान होंगे:

kubectl get pods -l app=kubernetes-bootcamp

मौजूदा सेवाओं को सूचीबद्ध करने के लिए आप ऐसा ही कर सकते हैं:

kubectl get services -l app=kubernetes-bootcamp

पॉड का नाम प्राप्त करें और इसे POD_NAME पर्यावरण चर में संग्रहीत करें:

export POD_NAME='$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{'\n'}} {{end}}')"
echo "Name of Pod: $POD_NAME"

नया लेबल लागू करने के लिए हम label उपकमांड का उपयोग करते हैं, जिसके बाद ऑब्जेक्ट प्रकार, ऑब्जेक्ट का नाम और नया लेबल आता है:

kubectl label pods "$POD_NAME" version=v1

यह हमारे पॉड पर एक नया लेबल लागू करेगा (हमने एप्लिकेशन संस्करण को पॉड पर पिन किया है), और हम इसे डिस्क्रिप्शन पॉड कमांड के साथ जांच सकते हैं:

kubectl describe pods "$POD_NAME"

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

kubectl get pods -l version=v1

और हम पॉड देखते हैं।

किसी सेवा को हटाना

सेवाओं को हटाने के लिए आप delete service उपकमांड का उपयोग कर सकते हैं। लेबल का उपयोग यहां भी किया जा सकता है:

kubectl delete service -l app=kubernetes-bootcamp

पुष्टि करें कि सेवा समाप्त हो गई है:

kubectl get services

यह पुष्टि करता है कि हमारी सेवा हटा दी गई थी। यह पुष्टि करने के लिए कि मार्ग अब उजागर नहीं हुआ है, आप पहले से उजागर आईपी और पोर्ट को curl कर सकते हैं:

curl http://'$(minikube ip):$NODE_PORT'

यह साबित करता है कि एप्लिकेशन अब क्लस्टर के बाहर से पहुंच योग्य नहीं है। आप पुष्टि कर सकते हैं कि ऐप अभी भी पॉड के अंदर से curl के साथ चल रहा है:

kubectl exec -ti $POD_NAME -- curl http://localhost:8080

हम यहां देखते हैं कि एप्लिकेशन चालू है। ऐसा इसलिए है क्योंकि परिनियोजन एप्लिकेशन का प्रबंधन कर रहा है। एप्लिकेशन को बंद करने के लिए, आपको परिनियोजन को भी हटाना होगा।

एक बार जब आप तैयार हो जाएं, तो आगे बढ़ें अपने ऐप के कई इंस्टेंस को चलाना

5.2.5 - अपने ऐप को स्केल करें

5.2.5.1 - अपने ऐप के कई इंस्टेंस चलाना

उद्देश्य

  • kubectl का उपयोग करके किसी ऐप को स्केल करें।

एक एप्लीकेशन को स्केल करना

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

डिप्लॉयमेंट में रेप्लिका की संख्या को बदलकर स्केलिंग को प्राप्त किया जाता है।

टिप्पणी:

यदि आप पिछले अनुभाग के बाद यह प्रयास कर रहे हैं, तो हो सकता है कि आपने डिप्लॉयमेंट को उजागर करने वाली सेवा को हटा दिया हो। उस स्थिति में, कृपया निम्नलिखित कमांड का उपयोग करके डिप्लॉयमेंट को फिर से उजागर करें:

kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080

सारांश:

  • एक डिप्लॉयमेंट को स्केल करना

आप kubectl create deployment कमांड के लिए --replicas पैरामीटर का उपयोग करके कई इंस्टेंस के साथ एक डिप्लॉयमेंट शुरू से बना सकते हैं।


स्केलिंग अवलोकन


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

किसी एप्लिकेशन के कई इंस्टेंस को चलाने के लिए उन सभी को ट्रैफ़िक वितरित करने के तरीके की आवश्यकता होगी। सर्विसों में एक एकीकृत लोड-बैलेंसर होता है जो एक एक्सपोज्ड डिप्लॉयमेंट के सभी पॉड्स को नेटवर्क ट्रैफ़िक वितरित करेगा। सर्विसे एंडपॉइंट्स का उपयोग करते हुए रनिंग पॉड्स की लगातार निगरानी करेंगी यह सुनिश्चित करने के लिए कि ट्रैफ़िक केवल उपलब्ध पॉड्स को ही भेजा जाए।

डिप्लॉयमेंट में रेप्लिका की संख्या को बदलकर स्केलिंग को पूरा किया जाता है।


एक बार जब आपके पास किसी एप्लिकेशन के चलने के कई इंस्टेंस हैं, तो आप डाउनटाइम के बिना रोलिंग अपडेट करने में सक्षम होंगे। हम इसे अगले मॉड्यूल में करेंगे। अब, ऑनलाइन टर्मिनल पर चलते हैं और हमारे एप्लिकेशन को स्केल करते हैं।


डिप्लॉयमेंट को स्केल करना

अपनी तैनाती को सूचीबद्ध करने के लिए, get deployments उपकमांड का उपयोग करें:

kubectl get deployments

आउटपुट इसके समान होना चाहिए:

                NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
                kubernetes-bootcamp   1/1     1            1           11m

हमारे पास 1 पॉड होना चाहिए। यदि नहीं, तो कमांड फिर से चलाएँ। इससे पता चलता है:

  • NAME क्लस्टर में परिनियोजन के नाम सूचीबद्ध करता है।
  • READY वर्तमान/वांछित प्रतिकृतियों का अनुपात दर्शाता है
  • UP-TO-DATE उन प्रतिकृतियों की संख्या प्रदर्शित करता है जिन्हें वांछित स्थिति प्राप्त करने के लिए अद्यतन किया गया है।
  • AVAILABLE प्रदर्शित करता है कि आपके उपयोगकर्ताओं के लिए एप्लिकेशन की कितनी प्रतिकृतियां उपलब्ध हैं।
  • AGE एप्लिकेशन के चलने की अवधि प्रदर्शित करता है।

परिनियोजन द्वारा बनाए गए रेप्लिकासेट को देखने के लिए, चलाएँ:

kubectl get rs

ध्यान दें कि रेप्लिकासेट का नाम हमेशा [DEPLOYMENT-NAME]-[RANDOM-STRING] के रूप में स्वरूपित होता है। यादृच्छिक स्ट्रिंग यादृच्छिक रूप से उत्पन्न होती है और बीज के रूप में पॉड-टेम्पलेट-हैश का उपयोग करती है।

इस आउटपुट के दो महत्वपूर्ण कॉलम हैं:

  • DESIRED एप्लिकेशन की प्रतिकृतियों की वांछित संख्या प्रदर्शित करता है, जिसे आप परिनियोजन बनाते समय परिभाषित करते हैं। यह वांछित स्थिति है.
  • CURRENT दर्शाता है कि वर्तमान में कितनी प्रतिकृतियां चल रही हैं।

इसके बाद, आइए परिनियोजन को 4 प्रतिकृतियों तक मापें। हम kubectl scale कमांड का उपयोग करेंगे, इसके बाद परिनियोजन प्रकार, नाम और उदाहरणों की वांछित संख्या का उपयोग करेंगे:

kubectl scale deployment/kubernetes-bootcamp --replicas=4

अपनी तैनाती को एक बार फिर से सूचीबद्ध करने के लिए, get deployment का उपयोग करें:

kubectl get deployments

जब परिवर्तन लागू किया गया था, उसकी वजह से हमारे पास अब एप्लिकेशन के 4 उदाहरण उपलब्ध हैं। इसके बाद, आइए देखें कि पॉड्स की संख्या बदली है या नहीं:

kubectl get pods -o wide

अब अलग-अलग ip पते के साथ 4 पॉड हैं। परिवर्तन परिनियोजन ईवेंट लॉग में दर्ज किया गया था। इसे जाँचने के लिए, डिस्क्रिप्शन उपकमांड का उपयोग करें:

kubectl describe deployments/kubernetes-bootcamp

आप इस कमांड के आउटपुट में यह भी देख सकते हैं कि अब 4 प्रतिकृतियां हैं।

लोड संतुलन

आइए जांचें कि सेवा ट्रैफ़िक को लोड-संतुलित कर रही है या नहीं। उजागर आईपी और पोर्ट का पता लगाने के लिए हम वर्णन सेवा का उपयोग कर सकते हैं जैसा कि हमने ट्यूटोरियल के पिछले भाग में सीखा था:

kubectl describe services/kubernetes-bootcamp

NODE_PORT नामक एक पर्यावरण चर बनाएं जिसका मान नोड पोर्ट के रूप में हो:

export NODE_PORT='$(kubectl getservices/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')'

echo NODE_PORT=$NODE_PORT

इसके बाद, हम उजागर आईपी पते और पोर्ट पर एक curl करेंगे। कमांड को कई बार निष्पादित करें:

curl http://"$(minikube ip):$NODE_PORT"

हम प्रत्येक अनुरोध के साथ एक अलग पॉड पर पहुंचते हैं। यह दर्शाता है कि लोड-संतुलन काम कर रहा है।

स्केल डाउन

परिनियोजन को 2 प्रतिकृतियों तक कम करने के लिए, scale उपकमांड को फिर से चलाएँ:

kubectl scale deployment/kubernetes-bootcamp --replicas=2

यह जांचने के लिए परिनियोजन को सूचीबद्ध करें कि क्या परिवर्तन get deployments उपकमांड के साथ लागू किया गया था:

kubectl get deployments

प्रतिकृतियों की संख्या घटकर 2 हो गई। get pods के साथ पॉड्स की संख्या सूचीबद्ध करें:

kubectl get pods -o wide

यह पुष्टि करता है कि 2 पॉड समाप्त कर दिए गए थे।

एक बार जब आप तैयार हो जाएं, तो एक रोलिंग अपडेट निष्पादित करना पर आगे बढ़ें।

5.2.6 - अपना ऐप अपडेट करें

5.2.6.1 - रोलिंग अपडेट करना

उद्देश्य

  • kubectl का उपयोग करके रोलिंग अपडेट करें।

एप्लिकेशन को अपडेट करना

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

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

सारांश:

  • ऐप अपडेट करना

रोलिंग अपडेट पॉड्स को नए इंस्टेंस के साथ अपडेट करके डिप्लॉयमेंट के अपडेट को शून्य डाउनटाइम के साथ होने देता है।


रोलिंग अपडेट अवलोकन


एप्लिकेशन स्केलिंग के समान, यदि कोई डिप्लॉयमेंट सार्वजनिक रूप से एक्सपोज़ होता है, तो सर्विस केवल अपडेट के दौरान उपलब्ध पॉड्स पर ट्रैफ़िक को लोड-बैलेंस करेगी। उपलब्ध पॉड एक इंस्टेंस है जो एप्लिकेशन के उपयोगकर्ताओं के लिए उपलब्ध है।

रोलिंग अपडेट निम्नलिखित क्रियाओं की अनुमति देते हैं:

  • किसी एप्लिकेशन को एक एनवायरनमेंट से दूसरे एनवायरनमेंट में प्रचारित करें (कंटेनर इमेज अपडेट के माध्यम से)
  • पिछले संस्करणों में रोलबैक करें
  • शून्य डाउनटाइम के साथ एप्लीकेशन का निरंतर इंटीग्रेशन और निरंतर डिलीवरी

यदि कोई डिप्लॉयमेंट सार्वजनिक रूप से प्रकट होता है, तो सर्विस अपडेट के दौरान केवल उपलब्ध पॉड्स पर ट्रैफ़िक लोड-बैलेंस करेगी।


चलिए अगले भाग पर चलते हैं और अपने एप्लिकेशन को एक नए संस्करण में अपडेट और रोलबैक करते है।


ऐप का संस्करण अपडेट करें

अपनी तैनाती को सूचीबद्ध करने के लिए, get deployments उपकमांड चलाएँ: kubectl get deployments

चल रहे पॉड्स को सूचीबद्ध करने के लिए, get pods उपकमांड चलाएँ:

kubectl get pods

ऐप का वर्तमान छवि संस्करण देखने के लिए, describe pod उपकमांड चलाएँ और image फ़ील्ड देखें:

kubectl describe pods

एप्लिकेशन की छवि को संस्करण 2 में अद्यतन करने के लिए, set image उपकमांड का उपयोग करें, इसके बाद परिनियोजन नाम और नया छवि संस्करण लिखें:

kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=jocatalin/kubernetes-bootcamp:v2

कमांड ने आपके ऐप के लिए एक अलग छवि का उपयोग करने के लिए परिनियोजन को सूचित किया और एक रोलिंग अपडेट शुरू किया। नए पॉड्स की स्थिति जांचें, और पुराने पॉड्स को get pods उपकमांड के साथ समाप्त होते हुए देखें:

kubectl get pods

अपडेट सत्यापित करें

सबसे पहले, जांचें कि ऐप चल रहा है या नहीं। उजागर आईपी पते और पोर्ट को खोजने के लिए, describe service कमांड चलाएँ:

kubectl describe services/kubernetes-bootcamp

NODE_PORT नामक एक पर्यावरण चर बनाएं जिसमें निर्दिष्ट नोड पोर्ट का मान हो:

export NODE_PORT='$(kubectl getservices/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')'
echo "NODE_PORT=$NODE_PORT"

इसके बाद, उजागर आईपी और पोर्ट पर curl करें:

curl http://'$(minikube ip):$NODE_PORT'

हर बार जब आप curl कमांड चलाएंगे, तो आप एक अलग पॉड से टकराएंगे। ध्यान दें कि सभी पॉड्स अब नवीनतम संस्करण (v2) चला रहे हैं।

आप rollout status उपकमांड चलाकर भी अपडेट की पुष्टि कर सकते हैं:

kubectl rollout status deployments/kubernetes-bootcamp

ऐप का वर्तमान छवि संस्करण देखने के लिए, describe pod उपकमांड चलाएँ:

kubectl describe pods

आउटपुट के image फ़ील्ड में, सत्यापित करें कि आप नवीनतम छवि संस्करण (v2) चला रहे हैं।

अपडेट वापस रोल करें

आइए एक और अपडेट करें, और v10 के साथ टैग की गई छवि को तैनात करने का प्रयास करें:

kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=gcr.io/google-samples/kubernetes-bootcamp:v10

डिप्लॉयमेंट की स्थिति देखने के लिए get deployments का उपयोग करें:

kubectl get deployments

ध्यान दें कि आउटपुट उपलब्ध पॉड्स की वांछित संख्या सूचीबद्ध नहीं करता है। सभी पॉड्स को सूचीबद्ध करने के लिए get pods उपकमांड चलाएँ:

kubectl get pods

ध्यान दें कि कुछ पॉड्स की स्थिति ImagePullBackOff है।

समस्या के बारे में अधिक जानकारी प्राप्त करने के लिए, describe pod उपकमांड चलाएँ:

kubectl describe pods

प्रभावित पॉड्स के आउटपुट के event अनुभाग में, ध्यान दें कि v10 छवि संस्करण रिपॉजिटरी में मौजूद नहीं था।

परिनियोजन को अपने अंतिम कार्यशील संस्करण में वापस लाने के लिए, rollout undo उपकमांड का उपयोग करें:

kubectl rollout undo deployment/kubernetes-bootcamp

rollout undo कमांड परिनियोजन को पिछली ज्ञात स्थिति (छवि का v2) में वापस कर देता है। अद्यतन संस्करणित हैं और आप परिनियोजन की किसी भी पूर्व ज्ञात स्थिति पर वापस लौट सकते हैं।

पॉड्स को फिर से सूचीबद्ध करने के लिए get pods उपकमांड का उपयोग करें:

kubectl get pods

चार पॉड्स चल रहे हैं। इन पॉड्स पर तैनात छवि की जांच करने के लिए, <कोड>describe pods उपकमांड का उपयोग करें:

kubectl describe pods

परिनियोजन एक बार फिर ऐप के स्थिर संस्करण (v2) का उपयोग कर रहा है। रोलबैक सफल रहा.

अपने स्थानीय क्लस्टर को साफ़ करना याद रखें

kubectl delete deployments/kubernetes-bootcamp services/kubernetes-bootcamp

6 - संदर्भ

कुबेरनेट्स प्रलेखन के इस खंड में संदर्भ हैं।

API संदर्भ

आधिकारिक तौर पर समर्थित ग्राहक पुस्तकालय

कुबेरनेट्स API को प्रोग्रामिंग भाषा से कॉल करने के लिए, आप उपयोग कर सकते हैंclient libraries. आधिकारिक तौर पर समर्थित client libraries:

CLI

  • kubectl - कमांड चलाने और कुबेरनेट्स क्लस्टर के प्रबंधन के लिए मुख्य CLI उपकरण।
    • JSONPath - kubectl के साथ प्रयोग करने के लिए सिन्‌टैक्‍स्‌(वाक्य रचना)मार्गदर्शक JSONPath expressions
  • kubeadm - एक सुरक्षित कुबेरनेट्स क्लस्टर का आसानी से प्रावधान करने के लिए CLI टूल।

अवयव

  • kubelet - प्राथमिक प्रतिनिधि(एजेंट) जो प्रत्येक नोड पर चलता है। क्यूबलेट पॉडस्पेक्स का एक सेट लेता है और यह सुनिश्चित करता है कि वर्णित कंटेनर चल रहे हैं और स्वस्थ हैं।

  • kube-apiserver -REST API जो API वस्तु जैसे पॉड्स, सेवाएं, प्रतिकृति नियंत्रक के लिए डेटा को मान्य और कॉन्फ़िगर करता है।

  • kube-controller-manager - डेमॉन जो कुबेरनेट्स के साथ भेजे गए कोर कंट्रोल लूप्स को एम्बेड करता है।

  • kube-proxy - बैक-एंड के एक सेट में साधारण TCP/UDP स्ट्रीम फॉरवर्डिंग (आगे भेजना) या राउंड-रॉबिन TCP/UDP फॉरवर्डिंग कर सकते हैं।

  • kube-scheduler - अनुसूचक जो उपलब्धता, प्रदर्शन और क्षमता का प्रबंधन करता है।

कॉन्फिग APIs

इस खंड में "अप्रकाशित" API के लिए दस्तावेज़ शामिल हैं जिनका उपयोग कुबेरनेट्स घटकों या उपकरणों को कॉन्फ़िगर करने के लिए किया जाता है। इनमें से अधिकांश APIs, RESTful तरीके से API सर्वर द्वारा उजागर नहीं होते हैं हालांकि वे एक उपयोगकर्ता या क्लस्टर के उपयोगकर्ता या प्रबंधक के लिए आवश्यक हैं।

kubeadm के लिए कॉन्फिग API

डिज़ाइन दस्तावेज़

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

6.1 - शब्दकोष

6.2 - शेडुलिंग

6.3 - अन्य उपकरण

कुबेरनेट्स सिस्टम के साथ काम करने में आपकी सहायता के लिए कुबेरनेट्स में कई उपकरण शामिल हैं।

crictl

crictl CRI-संगत कंटेनर रनटाइम के निरीक्षण और डिबगिंग के लिए एक कमांड-लाइन इंटरफ़ेस है।

Dashboard

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

Helm

🛇 यह वस्तु कोई अन्य पक्ष की परियोजना या उत्पाद से जुड़ा है जो कुबेरनेट्स का हिस्सा नहीं हैं। अधिक जानकारी के लिए पढ़ें

हेल्म पूर्व-कॉन्फ़िगर कुबेरनेट्स संसाधनों के पैकेजों के प्रबंधन के लिए एक उपकरण है। इन पैकेजों को हेल्म चार्ट के रूप में जाना जाता है।

हेल्म का उपयोग करें:

  • कुबेरनेट्स चार्ट के रूप में पैक किए गए लोकप्रिय सॉफ़्टवेयर को ढूंढें और उपयोग करें।
  • अपने ख़ुद के एप्लिकेशन को कुबेरनेट्स चार्ट के रूप में साझा करें।
  • बुद्धिमत्ता से अपने कुबेरनेट्स मैनिफ़ेस्ट फ़ाइलों को प्रबंधित करें।
  • हेल्म पैकेजों के रिलीज़ प्रबंधित करें।

Kompose

कॉम्पोज़ एक उपकरण है, जो डॉकर कंपोज़ उपयोगकर्ताओं को कुबेरनेट्स पर जाने में मदद करता है।

कॉम्पोज़ का उपयोग करें:

  • डॉकर कंपोज़ फ़ाइल को कुबेरनेट्स ऑब्जेक्ट्स में अनुवाद करें।
  • स्थानीय डॉकर डेवलपमेंट से कुबेरनेट्स एप्लीकेशनों को प्रबंधित करें।
  • v1 या v2 डॉकर कंपोज़, yaml फ़ाइलों याडिस्ट्रीब्यूटेड एप्लिकेशनो के बंडलों के माध्यम से अपने एप्लिकेशन को प्रबंधित कऱे।

Kui

Kui एक GUI उपकरण है, जो आपके सामान्य kubectl कमांड लाइन अनुरोधों को लेकर ग्राफिक्स के साथ प्रतिक्रिया देता है।

Kui सामान्य kubectl कमांड लाइन अनुरोधों को लेकर ग्राफिक्स के साथ प्रतिक्रिया देता है। ASCII टेबल्स के बजाय, Kui उन टेबल्स के साथ एक GUI प्रदान करता है, जिन्हें आप सॉर्ट कर सकते हैं।

Kui आपको देता है:

  • कॉपी और पेस्ट करने के बजाय सीधे लंबे स्वचालित रूप से जेनरेटेड किए गए संसाधनों के नामों पर क्लिक करें।
  • Kubectl कमांड टाइप करें और उन्हें निष्पादन होते हुए देखें, यहां तक कि कभी-कभी Kubectl से भी तेज।
  • एक जॉब क्वेरी करें और इसके निष्पादन को वॉटरफॉल के डायग्राम के रूप में देखें।
  • एक टैब्ड UI का उपयोग करके अपने क्लस्टर में संसाधनों पर क्लिक करें।

Minikube

मिनीक्यूब एक उपकरण है, जो डेवलपमेंट और परीक्षण जैसे उद्देश्यों के लिए आपके वर्कस्टेशन पर स्थानीय रूप से एक-नोड वाले कुबेरनेट्स क्लस्टर को चलाता है।

7 - कुबेरनेटेस डॉक्स में योगदान दे

कुबेरनेटस सभी योगदानकर्ताओ से सुधार का स्वागत करता है चाहे वो नए हो या अनुभवी!

टिप्पणी:

कुबेरनेटस मे योगदान करने के बारे मे अधिक जानकारी के लिए योगदानकर्ता प्रलेखन देखें।

इस वेबसाइट की देख रेख कुबेरनेटस SIG Docs द्वारा की जाती है।

कुबेरनेटस प्रलेखन योगदानकर्ता :

  • मौजूदा विषयों को सुधारते हैं
  • नए विषय बनाते हैं
  • प्रलेखन का अनुवाद करते हैं
  • कुबेरनेटस रिलीज चक्र मे प्रलेखन की देख रेख और प्रकाशन करते हैं

शुरू करना

कोई भी प्रलेखन के बारे मे इशू खोल सकता है या कुबेरनेटस वेबसाइट kubernetes/website GitHub रिपॉजिटरी मे बदलाव पुल अनुरोध (PR) द्वारा कर सकता है। आपको Git और Github की जानकारी होनी चाहिए ताकि आप कुबेरनेटेस समुदाय मे प्रभावी रूप से काम कर सकें।

प्रलेखन मे सहयोग करने के लिए:

  1. योगदानकर्ता समझौता लाइसेन्स पर हस्ताक्षर करें।
  2. प्रलेखन रिपॉजिटरी और वेबसाइट की स्टैटिक साइट जनरेटर से खुद को परिचित करें।
  3. सुनिश्चित करें की आपको पुल अनुरोध करना और बदलाओ की समीक्षा करना आता हो।

flowchart TB subgraph third[PR ओपन करे] direction TB U[ ] -.- Q[विषय सुधारे] --- N[विषय निर्माण करे] N --- O[डॉक्स का अनुवाद करे] O --- P[K8s रिलीज़ चक्र के प्रलेखन
को संचालित /प्रकाशित करें] end subgraph second[समीक्षा] direction TB T[ ] -.- D[kubernetes/website
रिपॉजिटरी
को देखें] --- E[Hugo स्टैटिक साइट
जनरेटर
को देखें] E --- F[मूलभूत GitHub
कमांड समझें] F --- G[ओपन PR की समीक्षा करे
और समीक्षा प्रक्रिया
को बदलें] end subgraph first[साइनअप] direction TB S[ ] -.- B[CNCF
योगदानकर्ता
लइसेंस समझौता
पर हस्ताक्षर करें] --- C[sig-docs स्लैक चैनल
में जुड़ें] C --- V[kubernetes-sig-docs
मेलिंग लिस्ट में जुड़ें] V --- M[साप्ताहिक
sig-docs कॉल
या स्लैक बैठक में शामिल हों] end A([fa:fa-user नए
योगदानकर्ता]) --> first A --> second A --> third A --> H[सवाल पूछे!!!] classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class A,B,C,D,E,F,G,H,M,Q,N,O,P,V grey class S,T,U spacewhite class first,second,third white
आकृति - नए योगदानकर्ताओं के लिए योगदान शुरू करने का रास्ता

ऊपर दी गई आकृति नए योगदानकर्ता के लिए दिशानिर्देश हैं। Sign up या review के लिए आप इनमे से कुछ या सभी निर्देशों का पालन कर सकते हैं। अब आप PR ओपन करने के लिए तैयार हैं जो आपके योगदान के उद्देश को पूरा करे जो Open PR खंड मे सूचीबद्ध हैं। आपके सभी प्रश्नों का सदैव स्वागत है।

कुबेरनेटस समुदाय मे कुछ कार्यों के लिए अधिक विश्वास और अभिगम की आवश्यकता होती है। भूमिका और अनुमति के बारे मे ज्यादा जानकारी के लिए
SIG Docs मे भाग लेना को देखें।

आपका पहला योगदान

आप अपने पहले योगदान की तैयारी के लिए दिए गए दिशानिर्देश को देख सकते हैं। नीचे दिया हुआ चित्र दिशानिर्देश और उसकी विस्तार मे जानकारी देता है।

flowchart LR subgraph second[पहला योगदान] direction TB S[ ] -.- G[दूसरे K8s मेम्बर्स के
PRs की समीक्षा करें] --> A[अपने पहले इशू (गुफ फर्स्ट इशू)
के लिए kubernetes/website
की इशू सूची पर जाएं] --> B[PR ओपन करें!!] end subgraph first[सूचित तैयारी] direction TB T[ ] -.- D[योगदान अवलोकन को पढे] -->E[K8s विषय
और विषय गाइड को पढ़ें] E --> F[Hugo पेज
विषय के प्रकार
और shortcodes के बारे मे जाने] end first ----> second classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 class A,B,D,E,F,G grey class S,T spacewhite class first,second white
आकृति - आपके पहले योगदान की तैयारी

अगले कदम

सिग डॉक्स मे शामिल हो

SIG Docs योगदानकर्ताओ का एक समूह है जो कुबेरनेटेस प्रलेखन और वेबसाईट की देख रेख और उसे प्रकाशित करता है। SIG Docs मे शामिल होना कुबेरनेटस योगदानकर्ताओ (फीचर विकास या उससे अन्यथा) के लिए कुबेरनेटस परियोजना पर प्रभाव डालने का बेहतरीन तरीका है।

SIG Docs भिन्न प्रकार से संवाद करते हैं:

योगदान करने के अन्य तरीके

7.1 - प्रलेखन शैली अवलोकन

इस खंड के विषय लेखन शैली, सामग्री स्वरूपण, और संगठन, और कुबेरनेट्स प्रलेखन के लिए विशिष्ट Hugo अनुकूलन का उपयोग करने पर मार्गदर्शन प्रदान करते हैं।

7.2 - साइट विश्लेषिकी देखना

इस पृष्ठ में Kubernetes.io विश्लेषिकी डैशबोर्ड के बारे में जानकारी है।

डैशबोर्ड देखें।

यह डैशबोर्ड Google Data Studio का उपयोग करके बनाया गया है और Google Analytics का उपयोग करके Kubernetes.io पर एकत्रित जानकारी दिखाता है।

डैशबोर्ड का उपयोग करना

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

यदि आप इस डैशबोर्ड में कोई समस्या देखते हैं, या किसी सुधार का अनुरोध करना चाहते हैं, तो कृपया एक इशू बनाएं।

8 - डॉक्स स्मोक टेस्ट पेज

यह पृष्ठ दो उद्देश्यों की पूर्ति करता है:

  • यह दिखाने के लिए कि Kubernetes प्रलेखन Markdown का उपयोग कैसे करता है
  • एक "स्मोक टेस्ट" दस्तावेज़ प्रदान करना जिसे हम HTML, CSS और टेम्पलेट परिवर्तनों का परीक्षण करने के लिए उपयोग कर सकते हैं जो संपूर्ण प्रलेखन को प्रभावित करते हैं।

शीर्षक स्तर

ऊपर का शीर्षक H2 है। पृष्ठ शीर्षक H1 के रूप में प्रस्तुत होता है। निम्नलिखित अनुभाग H3 - H6 दिखाते हैं।

### H3

यह H3 अनुभाग में है।

#### H4

यह H4 अनुभाग में है।

##### H5

यह H5 अनुभाग में है।

###### H6

यह H6 अनुभाग में है।

परिणाम:

H3

यह H3 अनुभाग में है।

H4

यह H4 अनुभाग में है।

H5

यह H5 अनुभाग में है।

H6

यह H6 अनुभाग में है।

इनलाइन तत्व

इनलाइन तत्व पैराग्राफ, सूची आइटम, चेतावनी या अन्य ब्लॉक-स्तरीय तत्वों के भीतर टेक्स्ट में दिखते हैं।

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

इनलाइन टेक्स्ट शैली

Markdown में आप विभिन्न टेक्स्ट शैलियों का उपयोग कर सकते हैं:

- **बोल्ड**
- _इटालिक_
- ***बोल्ड इटालिक***
- ~~स्ट्राइकथ्रू~~
- <u>रेखांकित</u>
- _<u>रेखांकित इटालिक</u>_
- **<u>रेखांकित बोल्ड</u>**
- ***<u>रेखांकित बोल्ड इटालिक</u>***
- `मोनोस्पेस टेक्स्ट`
- **`मोनोस्पेस बोल्ड`**

परिणाम:

  • बोल्ड
  • इटालिक
  • बोल्ड इटालिक
  • स्ट्राइकथ्रू
  • रेखांकित
  • रेखांकित इटालिक
  • रेखांकित बोल्ड
  • रेखांकित बोल्ड इटालिक
  • मोनोस्पेस टेक्स्ट
  • मोनोस्पेस बोल्ड

सूचियाँ

Markdown सूचियों को संसाधित करने के लिए सख्त नियम नहीं रखता। जब हमने Jekyll से Hugo पर स्विच किया, तो कुछ सूचियाँ टूट गईं। उन्हें ठीक करने के लिए निम्न बातों का ध्यान रखें:

  • उप-सूची आइटम को 2 स्थान से इंडेंट करें।
  • एक सूची को समाप्त करने और दूसरी सूची शुरू करने के लिए, आपको सूचियों के बीच एक HTML टिप्पणी ब्लॉक डालना होगा जो बाएँ किनारे पर संरेखित हो।

बुलेट सूचियाँ

- यह एक सूची आइटम है।
* यह उसी सूची का एक अन्य आइटम है।
- आप `-` और `*` मिला सकते हैं।
  - उप-आइटम बनाने के लिए, दो स्थान इंडेंट करें।
    - यह एक उप-उप-आइटम है।
  - एक अन्य उप-आइटम।

परिणाम:

  • यह एक सूची आइटम है।
  • यह उसी सूची का एक अन्य आइटम है।
  • आप - और * मिला सकते हैं।
    • उप-आइटम बनाने के लिए, दो स्थान इंडेंट करें।
      • यह एक उप-उप-आइटम है।
    • एक अन्य उप-आइटम।

  • यह एक नई सूची है। Hugo में, दो लगातार सूचियों को अलग करने के लिए HTML टिप्पणी आवश्यक होती है।

    ls -l
    • और एक उप-सूची ब्लॉक स्तर की सामग्री के बाद।

  • एक बुलेट सूची आइटम में क्रमांकित उप-सूची हो सकती है:

    1. क्रमांकित उप-सूची 1
    2. क्रमांकित उप-सूची 2

क्रमांकित सूचियाँ

  1. यह एक सूची आइटम है।
  2. यह एक अन्य सूची आइटम है।

  1. यह एक नई सूची है।

  2. सूची आइटम में अनुच्छेद और कोड ब्लॉक हो सकते हैं।

    ls -l
    • उप-सूची जो ब्लॉक स्तर की सामग्री के बाद आती है।

टैब सूचियाँ

कृपया एक विकल्प चुनें।

  1. क्रमबद्ध
  2. (या अव्यवस्थित)
  3. सूचियाँ
echo 'टैब सूचियों में कोड ब्लॉक हो सकते हैं!'

टैब सूची के भीतर शीर्षक

चेतावनी:

टैब सूची के भीतर शीर्षक TOC में नहीं दिखाई देंगे।

चेकलिस्ट

  • यह एक चेकलिस्ट आइटम है
  • यह एक चयनित चेकलिस्ट आइटम है

कोड ब्लॉक

आप कोड ब्लॉक दो तरीकों से बना सकते हैं, तीन बैकटिक के साथ। केवल कोड के लिए बैकटिक का प्रयोग करें।

यह एक कोड ब्लॉक है

ls -l

Hugo शॉर्टकोड के साथ कोड ब्लॉक

{{< alert color="warning" >}}यह एक चेतावनी है।{{< /alert >}}

लिंक

[कुबेरनेट्स पर लिंक](https://kubernetes.io/)

चित्र

![पेंसिल आइकन](/images/pencil.png)

[![पेंसिल आइकन](/images/pencil.png)](https://kubernetes.io)

तालिकाएँ

शीर्षक 1 शीर्षक 2
बॉडी 1 बॉडी 2

Mermaid विज़ुअलाइज़ेशन

{{< mermaid >}}
graph TD;
  A-->B;
  A-->C;
  B-->D;
  C-->D;
{{</ mermaid >}}
graph TD; A-->B; A-->C; B-->D; C-->D;

साइडबार और चेतावनियाँ

यह एक साइडबार है।

sudo dmesg

चेतावनियाँ

टिप्पणी:

यह एक नोट है।

सावधान:

पाठक को सावधानी से आगे बढ़ना चाहिए।

चेतावनी:

चेतावनियाँ कुछ नुकसान की संभावना बताती हैं।

सम्मिलन

टिप्पणी:

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

Katacoda लाइव एम्बेडेड वातावरण