🥇कुबेक्टल का अधिक प्रभावी ढंग से उपयोग कैसे करें: एक विस्तृत मार्गदर्शिका

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

टीम Mail.ru से Kubernetes aaS डैनियल वेइबेल के एक लेख का अनुवाद किया गया है जिसमें आपको कुबेक्टल के साथ प्रभावी ढंग से काम करने के लिए युक्तियां और युक्तियां मिलेंगी। इससे आपको कुबेरनेट्स की गहरी समझ हासिल करने में भी मदद मिलेगी।

लेखक के अनुसार, लेख का लक्ष्य कुबेरनेट्स के साथ आपके दैनिक कार्य को न केवल अधिक कुशल बनाना है, बल्कि अधिक मनोरंजक भी बनाना है!

परिचय: कुबेक्टल क्या है?

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

उपयोगकर्ता के दृष्टिकोण से, कुबेक्टल एक नियंत्रण कक्ष है जो आपको कुबेरनेट्स संचालन करने की अनुमति देता है।

तकनीकी रूप से कहें तो, कुबेक्टल एक कुबेरनेट्स एपीआई क्लाइंट है।

Kubernetes API एक HTTP REST API है। यह एपीआई सच्चा कुबेरनेट्स यूजर इंटरफेस है, जिसके माध्यम से इसे पूरी तरह से नियंत्रित किया जाता है। इसका मतलब यह है कि प्रत्येक कुबेरनेट्स ऑपरेशन को एपीआई एंडपॉइंट के रूप में उजागर किया जाता है और उस एंडपॉइंट पर HTTP अनुरोध के साथ किया जा सकता है।

इसलिए, kubectl का मुख्य कार्य Kubernetes API के लिए HTTP अनुरोध करना है:

कुबेरनेट्स पूरी तरह से संसाधन-उन्मुख प्रणाली है। इसका मतलब है कि यह संसाधनों की आंतरिक स्थिति को बनाए रखता है और सभी कुबेरनेट्स ऑपरेशन सीआरयूडी ऑपरेशन हैं।

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

आइए एक उदाहरण देखें.

मान लीजिए कि आप एक रेप्लिकासेट संसाधन बनाना चाहते हैं। ऐसा करने के लिए, आप फ़ाइल में रेप्लिकासेट का नाम से वर्णन करते हैं replicaset.yaml, फिर कमांड चलाएँ:

$ kubectl create -f replicaset.yaml

यह एक रेप्लिकासेट संसाधन बनाएगा। लेकिन पर्दे के पीछे क्या होता है?

कुबेरनेट्स के पास रेप्लिकासेट निर्माण ऑपरेशन है। किसी भी अन्य ऑपरेशन की तरह, इसे एपीआई एंडपॉइंट के रूप में प्रदर्शित किया जाता है। इस ऑपरेशन के लिए विशिष्ट एपीआई समापन बिंदु इस तरह दिखता है:

POST /apis/apps/v1/namespaces/{namespace}/replicasets

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

इसलिए, जब आप उपरोक्त कमांड निष्पादित करते हैं, तो कुबेक्टल उपरोक्त एपीआई एंडपॉइंट पर एक HTTP POST अनुरोध भेजता है। आपके द्वारा फ़ाइल में प्रदान की गई रेप्लिकासेट परिभाषा replicaset.yaml, अनुरोध के मुख्य भाग में भेजा जाता है।

Kubernetes क्लस्टर के साथ इंटरैक्ट करने वाले सभी कमांड के लिए Kubectl इस प्रकार काम करता है। इन सभी मामलों में, kubectl बस उपयुक्त Kubernetes API एंडपॉइंट पर HTTP अनुरोध करता है।

कृपया ध्यान दें कि आप इस तरह की उपयोगिता का उपयोग करके कुबेरनेट्स को पूरी तरह से प्रबंधित कर सकते हैं curlकुबेरनेट्स एपीआई को मैन्युअल रूप से HTTP अनुरोध भेजकर। Kubectl बस Kubernetes API का उपयोग करना आसान बनाता है।

यह कुबेटल क्या है और यह कैसे काम करता है इसकी मूल बातें है। लेकिन Kubernetes API के बारे में कुछ और भी है जो प्रत्येक kubectl उपयोगकर्ता को पता होना चाहिए। आइए कुबेरनेट्स की आंतरिक दुनिया पर एक नज़र डालें।

कुबेरनेट्स की आंतरिक दुनिया

कुबेरनेट्स में स्वतंत्र घटकों का एक सेट होता है जो क्लस्टर नोड्स पर अलग-अलग प्रक्रियाओं के रूप में चलता है। कुछ घटक मास्टर नोड्स पर चलते हैं, अन्य वर्कर नोड्स पर, प्रत्येक घटक अपना विशिष्ट कार्य करता है।

यहां मुख्य नोड्स पर सबसे महत्वपूर्ण घटक हैं:

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

और यहां कार्यकर्ता नोड्स पर एक सबसे महत्वपूर्ण घटक है:

क्यूबलेट - कार्यशील नोड पर कंटेनरों के लॉन्च का प्रबंधन करता है।

यह समझने के लिए कि ये घटक एक साथ कैसे काम करते हैं, आइए एक उदाहरण देखें।

चलिए मान लेते हैं कि आपने अभी-अभी पूरा किया है kubectl create -f replicaset.yaml, जिसके बाद kubectl ने एक HTTP POST अनुरोध किया रेप्लिकासेट एपीआई समापन बिंदु (रेप्लिकासेट संसाधन परिभाषा को पार करते हुए)।

क्लस्टर में क्या चल रहा है?

करने के बाद kubectl create -f replicaset.yaml एपीआई सर्वर आपके रेप्लिकासेट संसाधन परिभाषा को भंडारण में संग्रहीत करता है:
इसके बाद, कंट्रोलर मैनेजर में रेप्लिकासेट कंट्रोलर लॉन्च किया जाता है, जो रेप्लिकासेट संसाधनों के निर्माण, संशोधन और विलोपन को संभालता है:
रेप्लिकासेट नियंत्रक प्रत्येक रेप्लिकासेट प्रतिकृति के लिए एक पॉड परिभाषा बनाता है (रेप्लिकासेट परिभाषा में पॉड टेम्पलेट के अनुसार) और उन्हें भंडारण में संग्रहीत करता है:
शेड्यूलर लॉन्च किया गया है, उन पॉड्स को ट्रैक करना जिन्हें अभी तक किसी भी वर्कर नोड को नहीं सौंपा गया है:
शेड्यूलर प्रत्येक पॉड के लिए एक उपयुक्त वर्कर नोड का चयन करता है और इस जानकारी को स्टोर में पॉड परिभाषा में जोड़ता है:
जिस वर्कर नोड को पॉड सौंपा गया है, उस पर क्यूबलेट लॉन्च किया गया है, यह इस नोड को सौंपे गए पॉड्स को ट्रैक करता है:
क्यूबलेट स्टोरेज से पॉड परिभाषा को पढ़ता है और नोड पर कंटेनर लॉन्च करने के लिए डॉकर जैसे कंटेनर रनटाइम को निर्देश देता है:

नीचे इस विवरण का एक पाठ संस्करण है.

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

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

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

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

ध्यान दें कि इस बिंदु तक, क्लस्टर में कहीं भी कोई वर्कलोड कोड नहीं चल रहा था। अब तक जो कुछ भी किया गया है - यह मास्टर नोड पर रिपॉजिटरी में संसाधनों का निर्माण और अद्यतनीकरण है।

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

इस बिंदु पर, आपका रेप्लिकासेट एप्लिकेशन अंततः चल रहा है!

कुबेरनेट्स एपीआई की भूमिका

जैसा कि आपने पिछले उदाहरण में देखा, कुबेरनेट्स घटक (एपीआई सर्वर और स्टोरेज को छोड़कर) स्टोरेज में संसाधनों में बदलाव पर नजर रखते हैं और स्टोरेज में संसाधनों के बारे में जानकारी बदलते हैं।

बेशक, ये घटक सीधे स्टोरेज के साथ इंटरैक्ट नहीं करते हैं, बल्कि केवल कुबेरनेट्स एपीआई के माध्यम से इंटरैक्ट करते हैं।

निम्नलिखित उदाहरणों पर विचार करें:

रेप्लिकासेट नियंत्रक एपीआई एंडपॉइंट का उपयोग करता है सूची प्रतिकृति सेट पैरामीटर के साथ watch रेप्लिकासेट संसाधनों में परिवर्तनों की निगरानी करने के लिए।
रेप्लिकासेट नियंत्रक एपीआई एंडपॉइंट का उपयोग करता है पॉड बनाएं (create pod) पॉड बनाने के लिए।
शेड्यूलर एपीआई एंडपॉइंट का उपयोग करता है पैच पॉड (पॉड संपादित करें) चयनित वर्कर नोड के बारे में जानकारी के साथ पॉड्स को अपडेट करने के लिए।

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

अब हम संक्षेप में बता सकते हैं कि कुबेरनेट्स कैसे काम करता है:

भंडारण राज्य, यानी कुबेरनेट्स संसाधनों को संग्रहीत करता है।
एपीआई सर्वर कुबेरनेट्स एपीआई के रूप में स्टोरेज के लिए एक इंटरफ़ेस प्रदान करता है।
अन्य सभी कुबेरनेट्स घटक और उपयोगकर्ता एपीआई के माध्यम से कुबेरनेट्स स्थिति (संसाधनों) को पढ़ते हैं, निरीक्षण करते हैं और उनमें हेरफेर करते हैं।

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

आइए अब कुछ विशिष्ट युक्तियों और युक्तियों पर नजर डालें जो कुबेक्टल के साथ आपकी उत्पादकता को बेहतर बनाने में मदद करेंगी।

1. कमांड पूर्णता का उपयोग करके इनपुट को गति दें

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

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

देखें कि कुबेक्टल कमांड पूर्णता कैसे काम करती है:

बैश और Zsh शेल के लिए कमांड पूर्णता कार्य।

आधिकारिक गाइड स्वत: पूर्णता स्थापित करने के लिए विस्तृत निर्देश शामिल हैं, लेकिन नीचे हम एक संक्षिप्त अंश प्रदान करेंगे।

कमांड पूर्णता कैसे काम करती है

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

Kubectl स्वचालित रूप से निम्नलिखित कमांड का उपयोग करके बैश और Zsh के लिए एक्सटेंशन स्क्रिप्ट उत्पन्न और आउटपुट करता है:

$ kubectl completion bash

Или:

$ kubectl completion zsh

सिद्धांत रूप में, इन कमांड के आउटपुट को उपयुक्त कमांड शेल से कनेक्ट करना पर्याप्त है ताकि कुबेक्टल कमांड को पूरक कर सके।

व्यवहार में, बैश (लिनक्स और मैकओएस के बीच अंतर सहित) और ज़ेडएसएच के लिए कनेक्शन विधि अलग है। नीचे हम इन सभी विकल्पों पर गौर करेंगे।

लिनक्स पर बैश करें

बैश पूर्णता स्क्रिप्ट बैश-समापन पैकेज पर निर्भर करती है, इसलिए आपको पहले इसे इंस्टॉल करना होगा:

$ sudo apt-get install bash-completion

Или:

$ yum install bash-completion

आप निम्न आदेश का उपयोग करके परीक्षण कर सकते हैं कि पैकेज सफलतापूर्वक स्थापित हो गया है:

$ type _init_completion

यदि यह शेल फ़ंक्शन कोड आउटपुट करता है, तो बैश-समापन सही ढंग से स्थापित होता है। यदि आदेश "नहीं मिला" त्रुटि देता है, तो आपको अपनी फ़ाइल में निम्न पंक्ति जोड़नी होगी ~ / .bashrc:

$ source /usr/share/bash-completion/bash_completion

क्या इस लाइन को फ़ाइल में जोड़ना आवश्यक है? ~ / .bashrc या नहीं यह उस पैकेज मैनेजर पर निर्भर करता है जिसका उपयोग आपने बैश-समापन स्थापित करने के लिए किया था। यह APT के लिए आवश्यक है, लेकिन YUM के लिए नहीं।

बैश-समापन स्थापित करने के बाद, आपको सब कुछ कॉन्फ़िगर करने की आवश्यकता है ताकि कुबेक्टल पूर्णता स्क्रिप्ट सभी शेल सत्रों में सक्षम हो।

ऐसा करने का एक तरीका फ़ाइल में निम्न पंक्ति जोड़ना है ~ / .bashrc:

source <(kubectl completion bash)

दूसरा तरीका कुबेक्टल एक्सटेंशन स्क्रिप्ट को निर्देशिका में जोड़ना है /etc/bash_completion.d (यदि यह मौजूद नहीं है तो इसे बनाएं):

$ kubectl completion bash >/etc/bash_completion.d/kubectl

कैटलॉग में सभी ऐड-ऑन स्क्रिप्ट /etc/bash_completion.d स्वचालित रूप से बैश-समापन में शामिल हो जाते हैं।

दोनों विकल्प समान रूप से लागू हैं.

शेल को पुनरारंभ करने के बाद, kubectl कमांड पूर्णता कार्य करेगी।

MacOS पर बैश करें

MacOS पर सेटअप थोड़ा अधिक जटिल है। तथ्य यह है कि डिफ़ॉल्ट रूप से, MacOS बैश संस्करण 3.2 का उपयोग करता है, और kubectl स्वत: पूर्णता स्क्रिप्ट के लिए कम से कम 4.1 के बैश संस्करण की आवश्यकता होती है और यह बैश 3.2 में काम नहीं करता है।

MacOS पर बैश के पुराने संस्करण का उपयोग करने से संबंधित लाइसेंस संबंधी समस्याएं हैं। बैश संस्करण 4 को GPLv3 के अंतर्गत लाइसेंस प्राप्त है, जो Apple द्वारा समर्थित नहीं है।

MacOS पर kubectl स्वत: पूर्णता को कॉन्फ़िगर करने के लिए, आपको बैश का नवीनतम संस्करण स्थापित करना होगा। आप अपडेटेड बैश को अपने डिफ़ॉल्ट शेल के रूप में भी सेट कर सकते हैं, जो आपको भविष्य में कई समस्याओं से बचाएगा। यह मुश्किल नहीं है, विवरण लेख में दिया गया है "MacOS पर बैश अपडेट कर रहा है'.

जारी रखने से पहले, सुनिश्चित करें कि आप बैश के नवीनतम संस्करण का उपयोग कर रहे हैं (आउटपुट जांचें)। bash --version).

बैश पूर्णता स्क्रिप्ट परियोजना के अनुसार भिन्न होती है बैश-समापन, इसलिए आपको पहले इसे इंस्टॉल करना होगा।

आप बैश-समापन का उपयोग करके इंस्टॉल कर सकते हैं homebrew:

$ brew install bash-completion@2

यहां @2 बैश-समापन संस्करण 2 के लिए खड़ा है। kubectl स्वत: पूर्णता के लिए बैश-समापन v2 की आवश्यकता होती है, और बैश-समापन v2 के लिए न्यूनतम बैश संस्करण 4.1 की आवश्यकता होती है।

कमांड आउटपुट brew-install इसमें एक चेतावनी अनुभाग है, जो निर्दिष्ट करता है कि फ़ाइल में क्या जोड़ने की आवश्यकता है ~/.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"

हालाँकि, मैं इन पंक्तियों को इसमें नहीं जोड़ने की सलाह देता हूँ ~/.bash_profileऔर में ~/.bashrc. इस मामले में, स्वत: पूर्णता न केवल मुख्य में, बल्कि चाइल्ड कमांड शेल में भी उपलब्ध होगी।

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

$ type _init_completion

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

अब हमें यह सुनिश्चित करने की आवश्यकता है कि सभी सत्रों में kubectl स्वत: पूर्णता सक्षम है।

एक तरीका यह है कि निम्नलिखित पंक्ति को अपने में जोड़ें ~/.bashrc:

source <(kubectl completion bash)

दूसरा तरीका फ़ोल्डर में एक स्वत: पूर्ण स्क्रिप्ट जोड़ना है /usr/local/etc/bash_completion.d:

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

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

यदि आपने इंस्टॉल किया है होमब्रू का उपयोग करके क्यूबेक्टल, तो पिछले चरण को निष्पादित करने की कोई आवश्यकता नहीं है, क्योंकि स्वत: पूर्णता स्क्रिप्ट स्वचालित रूप से फ़ोल्डर में रखी जाएगी /usr/local/etc/bash_completion.d इंस्टॉलेशन के दौरान। इस स्थिति में, जैसे ही आप बैश-समापन स्थापित करेंगे, kubectl स्वत: पूर्णता काम करना शुरू कर देगी।

परिणामस्वरूप, ये सभी विकल्प समतुल्य हैं।

Zsh

Zsh के लिए स्वत: पूर्णता स्क्रिप्ट को किसी निर्भरता की आवश्यकता नहीं होती है। जब आप कमांड शेल लोड करते हैं तो आपको बस उन्हें सक्षम करना होता है।

आप अपने में एक पंक्ति जोड़कर ऐसा कर सकते हैं ~/.zshrc फ़ाइल:

source <(kubectl completion zsh)

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

autoload -Uz compinit
compinit

2. संसाधन विशिष्टताओं को शीघ्रता से देखें

जब आप YAML संसाधन परिभाषाएँ बनाते हैं, तो आपको उन संसाधनों के लिए फ़ील्ड और उनके अर्थ जानने की आवश्यकता होती है। इस जानकारी को देखने का एक स्थान एपीआई संदर्भ में है, जिसमें सभी संसाधनों के लिए पूर्ण विनिर्देश शामिल हैं।

हालाँकि, जब भी आपको कुछ खोजना हो तो वेब ब्राउज़र पर स्विच करना असुविधाजनक होता है। इसलिए kubectl कमांड प्रदान करता है kubectl explain, जो सीधे आपके टर्मिनल में सभी संसाधनों की विशिष्टताओं को दिखाता है।

कमांड प्रारूप इस प्रकार है:

$ kubectl explain resource[.field]...

कमांड अनुरोधित संसाधन या फ़ील्ड के विनिर्देशन को आउटपुट करेगा। प्रदर्शित जानकारी एपीआई मैनुअल में मौजूद जानकारी के समान है।

По умолчанию kubectl explain खेतों की नेस्टिंग का केवल पहला स्तर दिखाता है।

देखें यह कैसा दिखता है फिर आप यह कर सकते हैं.

यदि आप विकल्प जोड़ते हैं तो आप संपूर्ण पेड़ प्रदर्शित कर सकते हैं --recursive:

$ kubectl explain deployment.spec --recursive

यदि आप ठीक से नहीं जानते कि किन संसाधनों की आवश्यकता है, तो आप उन सभी को निम्नलिखित कमांड से प्रदर्शित कर सकते हैं:

$ kubectl api-resources

यह कमांड संसाधन नामों को बहुवचन रूप में प्रदर्शित करता है, उदा. deployments के बदले deployment. उदाहरण के लिए, यह संक्षिप्त नाम भी प्रदर्शित करता है deploy, उन संसाधनों के लिए जिनके पास यह है। इन मतभेदों के बारे में चिंता मत करो. ये सभी नामकरण विकल्प kubectl के लिए समतुल्य हैं। यानी आप इनमें से किसी का भी इस्तेमाल कर सकते हैं kubectl explain.

निम्नलिखित सभी आदेश समतुल्य हैं:

$ kubectl explain deployments.spec
# или
$ kubectl explain deployment.spec
# или        
$ kubectl explain deploy.spec

3. एक कस्टम कॉलम आउटपुट स्वरूप का उपयोग करें

डिफ़ॉल्ट कमांड आउटपुट स्वरूप kubectl get:

$ kubectl get pods
NAME                     READY    STATUS    RESTARTS  AGE
engine-544b6b6467-22qr6   1/1     Running     0       78d
engine-544b6b6467-lw5t8   1/1     Running     0       78d
engine-544b6b6467-tvgmg   1/1     Running     0       78d
web-ui-6db964458-8pdw4    1/1     Running     0       78d

यह प्रारूप सुविधाजनक है, लेकिन इसमें सीमित मात्रा में जानकारी होती है। पूर्ण संसाधन परिभाषा प्रारूप की तुलना में, यहां केवल कुछ फ़ील्ड प्रदर्शित किए गए हैं।

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

कस्टम प्रारूप का उपयोग विकल्पों का उपयोग करके निर्धारित किया जाता है:

-o custom-columns=<header>:<jsonpath>[,<header>:<jsonpath>]...

आप प्रत्येक आउटपुट कॉलम को एक जोड़ी के रूप में परिभाषित कर सकते हैं <header>:<jsonpath>जहां <header> स्तंभ का नाम है, और <jsonpath> - संसाधन क्षेत्र को परिभाषित करने वाली एक अभिव्यक्ति।

आइए एक सरल उदाहरण देखें:

$ kubectl get pods -o custom-columns='NAME:metadata.name'

NAME
engine-544b6b6467-22qr6
engine-544b6b6467-lw5t8
engine-544b6b6467-tvgmg
web-ui-6db964458-8pdw4

आउटपुट में पॉड्स के नाम के साथ एक कॉलम होता है।

विकल्प अभिव्यक्ति फ़ील्ड से पॉड नामों का चयन करती है metadata.name. ऐसा इसलिए है क्योंकि पॉड का नाम चाइल्ड नेम फ़ील्ड में परिभाषित किया गया है metadata पॉड के संसाधन विवरण में। अधिक विवरण यहां पाया जा सकता है एपीआई गाइड या कमांड टाइप करें kubectl explain pod.metadata.name.

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

$ kubectl get pods 
  -o custom-columns='NAME:metadata.name,NODE:spec.nodeName'

NAME                       NODE
engine-544b6b6467-22qr6    ip-10-0-80-67.ec2.internal
engine-544b6b6467-lw5t8    ip-10-0-36-80.ec2.internal
engine-544b6b6467-tvgmg    ip-10-0-118-34.ec2.internal
web-ui-6db964458-8pdw4     ip-10-0-118-34.ec2.internal

अभिव्यक्ति से नोड नाम का चयन करता है spec.nodeName - जब एक पॉड को किसी नोड को सौंपा जाता है, तो उसका नाम फ़ील्ड में लिखा जाता है spec.nodeName पॉड संसाधन विशिष्टता. अधिक विस्तृत जानकारी आउटपुट में पाई जा सकती है kubectl explain pod.spec.nodeName.

कृपया ध्यान दें कि कुबेरनेट्स संसाधन फ़ील्ड केस संवेदनशील हैं।

आप किसी भी संसाधन फ़ील्ड को एक कॉलम के रूप में देख सकते हैं। बस संसाधन विनिर्देश की समीक्षा करें और इसे अपनी पसंद के किसी भी क्षेत्र के साथ आज़माएँ।

लेकिन पहले, आइए फ़ील्ड चयन अभिव्यक्तियों पर करीब से नज़र डालें।

JSONPath अभिव्यक्तियाँ

संसाधन फ़ील्ड के चयन के लिए अभिव्यक्तियाँ पर आधारित हैं JSONPath.

JSONPath JSON दस्तावेज़ों से डेटा पुनर्प्राप्त करने के लिए एक भाषा है। JSONPath के लिए एकल फ़ील्ड का चयन करना सबसे सरल उपयोग मामला है। उसके पास बहुत कुछ है बड़ी आवाज, जिसमें चयनकर्ता, फ़िल्टर इत्यादि शामिल हैं।

Kubectl व्याख्या सीमित संख्या में JSONPath सुविधाओं का समर्थन करती है। उनके उपयोग की संभावनाएँ और उदाहरण नीचे वर्णित हैं:

# Выбрать все элементы списка
$ kubectl get pods -o custom-columns='DATA:spec.containers[*].image'
# Выбрать специфический элемент списка
$ kubectl get pods -o custom-columns='DATA:spec.containers[0].image'
# Выбрать элементы списка, попадающие под фильтр
$ kubectl get pods -o custom-columns='DATA:spec.containers[?(@.image!="nginx")].image'
# Выбрать все поля по указанному пути, независимо от их имени
$ kubectl get pods -o custom-columns='DATA:metadata.*'
# Выбрать все поля с указанным именем, вне зависимости от их расположения
$ kubectl get pods -o custom-columns='DATA:..image'

[] ऑपरेटर विशेष रूप से महत्वपूर्ण है। कई Kubernetes संसाधन फ़ील्ड सूचियाँ हैं, और यह ऑपरेटर आपको उन सूचियों के सदस्यों का चयन करने की अनुमति देता है। किसी सूची के सभी तत्वों का चयन करने के लिए इसका उपयोग अक्सर [*] जैसे वाइल्डकार्ड के साथ किया जाता है।

आवेदन उदाहरण

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

पॉड्स के लिए कंटेनर चित्र प्रदर्शित करना:
```
$ kubectl get pods 
  -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'

NAME                        IMAGES
engine-544b6b6467-22qr6     rabbitmq:3.7.8-management,nginx
engine-544b6b6467-lw5t8     rabbitmq:3.7.8-management,nginx
engine-544b6b6467-tvgmg     rabbitmq:3.7.8-management,nginx
web-ui-6db964458-8pdw4      wordpress
```
यह कमांड प्रत्येक पॉड के लिए कंटेनर छवि नाम प्रदर्शित करता है।

याद रखें कि एक पॉड में कई कंटेनर हो सकते हैं, फिर छवि नाम अल्पविराम से अलग होकर एक पंक्ति में प्रदर्शित होंगे।
नोड उपलब्धता क्षेत्र प्रदर्शित करना:
```
$ kubectl get nodes 
  -o 
custom-columns='NAME:metadata.name,ZONE:metadata.labels.failure-domain.beta.kubernetes.io/zone'

NAME                          ZONE
ip-10-0-118-34.ec2.internal   us-east-1b
ip-10-0-36-80.ec2.internal    us-east-1a
ip-10-0-80-67.ec2.internal    us-east-1b
```
यदि आपका क्लस्टर सार्वजनिक क्लाउड में होस्ट किया गया है तो यह कमांड उपयोगी है। यह प्रत्येक नोड के लिए उपलब्धता क्षेत्र प्रदर्शित करता है।

उपलब्धता क्षेत्र एक क्लाउड अवधारणा है जो प्रतिकृति क्षेत्र को एक भौगोलिक क्षेत्र तक सीमित करती है।

प्रत्येक नोड के लिए उपलब्धता क्षेत्र एक विशेष लेबल के माध्यम से प्राप्त किए जाते हैं - failure-domain.beta.kubernetes.io/zone. यदि क्लस्टर सार्वजनिक क्लाउड में चल रहा है, तो यह लेबल स्वचालित रूप से बनाया जाता है और प्रत्येक नोड के लिए उपलब्धता क्षेत्रों के नामों से भरा होता है।

लेबल कुबेरनेट्स संसाधन विनिर्देश का हिस्सा नहीं हैं, इसलिए आपको उनके बारे में जानकारी नहीं मिलेगी एपीआई गाइड. हालाँकि, यदि आप YAML या JSON प्रारूप में नोड्स के बारे में जानकारी का अनुरोध करते हैं तो उन्हें (किसी भी अन्य लेबल की तरह) देखा जा सकता है:
```
$ kubectl get nodes -o yaml
# или
$ kubectl get nodes -o json
```
संसाधन विशिष्टताओं को सीखने के अलावा, संसाधनों के बारे में अधिक जानने का यह एक शानदार तरीका है।

4. क्लस्टर और नेमस्पेस के बीच आसानी से स्विच करें

जब Kubectl Kubernetes API के लिए अनुरोध करता है, तो यह कनेक्शन के लिए सभी आवश्यक पैरामीटर प्राप्त करने के लिए पहले kubeconfig फ़ाइल को पढ़ता है।

डिफ़ॉल्ट रूप से kubeconfig फ़ाइल है ~/.kube/config. आमतौर पर यह फ़ाइल एक विशेष कमांड द्वारा बनाई या अपडेट की जाती है।

जब आप एकाधिक क्लस्टर के साथ काम करते हैं, तो आपकी kubeconfig फ़ाइल में उन सभी क्लस्टर से कनेक्ट करने के लिए सेटिंग्स होती हैं। आपको kubectl कमांड को यह बताने का एक तरीका चाहिए कि आप किस क्लस्टर के साथ काम कर रहे हैं।

एक क्लस्टर के भीतर, आप एकाधिक नामस्थान बना सकते हैं—भौतिक क्लस्टर के भीतर एक प्रकार का वर्चुअल क्लस्टर। Kubectl यह भी निर्धारित करता है कि kubeconfig फ़ाइल के आधार पर किस नेमस्पेस का उपयोग करना है। इसका मतलब है कि आपको कुबेक्टल कमांड को यह बताने का एक तरीका भी चाहिए कि किस नेमस्पेस के साथ काम करना है।

इस अध्याय में हम बताएंगे कि यह कैसे काम करता है और इसे प्रभावी ढंग से कैसे काम करना है।

ध्यान दें कि आपके पास KUBECONFIG पर्यावरण चर में सूचीबद्ध कई kubeconfig फ़ाइलें हो सकती हैं। इस स्थिति में, इन सभी फ़ाइलों को रनटाइम पर एक सामान्य कॉन्फ़िगरेशन में संयोजित किया जाएगा। आप पैरामीटर के साथ kubectl चलाकर डिफ़ॉल्ट kubeconfig फ़ाइल को भी बदल सकते हैं --kubeconfig. देखना आधिकारिक दस्तावेज.

kubeconfig फ़ाइलें

आइए देखें कि वास्तव में kubeconfig फ़ाइल में क्या है:

जैसा कि आप देख सकते हैं, kubeconfig फ़ाइल में संदर्भों का एक सेट है। संदर्भ में तीन तत्व शामिल हैं:

क्लस्टर - क्लस्टर सर्वर का एपीआई यूआरएल।
उपयोगकर्ता - क्लस्टर में उपयोगकर्ता प्रमाणीकरण क्रेडेंशियल।
नेमस्पेस - क्लस्टर में शामिल होने पर उपयोग किया जाने वाला नेमस्पेस।

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

किसी भी समय, इनमें से एक संदर्भ वर्तमान होता है:

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

तदनुसार, किसी अन्य क्लस्टर पर स्विच करने के लिए, आपको kubeconfig फ़ाइल में वर्तमान संदर्भ को बदलना होगा:

अब कुबेक्टल फॉक्स क्लस्टर से कनेक्ट होगा।

एक ही क्लस्टर में किसी भिन्न नेमस्पेस पर स्विच करने के लिए, आपको वर्तमान संदर्भ के लिए नेमस्पेस तत्व का मान बदलना होगा:

उपरोक्त उदाहरण में, कुबेक्टल फॉक्स क्लस्टर के प्रोडक्ट नेमस्पेस (पहले टेस्ट नेमस्पेस सेट किया गया था) का उपयोग करेगा।

ध्यान दें कि kubectl विकल्प भी प्रदान करता है --cluster, --user, --namespace и --context, जो आपको व्यक्तिगत तत्वों और वर्तमान संदर्भ को अधिलेखित करने की अनुमति देता है, भले ही क्यूबकॉन्फिग में कुछ भी सेट किया गया हो। देखना kubectl options.

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

Kubectx का प्रयोग करें

क्लस्टर और नेमस्पेस के बीच स्विच करने के लिए एक बहुत लोकप्रिय उपयोगिता।

उपयोगिता आदेश प्रदान करती है kubectx и kubens वर्तमान संदर्भ और नामस्थान को क्रमशः बदलने के लिए।

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

इन आदेशों को चलाने का एक उदाहरण यहां दिया गया है:

अनिवार्य रूप से, ये कमांड ऊपर वर्णित अनुसार बस kubeconfig फ़ाइल को संपादित करते हैं।

स्थापित करने के लिए kubectx, पर दिए गए निर्देशों का पालन करें Github।

दोनों कमांड संदर्भ और नेमस्पेस नामों के स्वत: पूर्ण होने का समर्थन करते हैं, जिससे उन्हें पूरी तरह से टाइप करने की आवश्यकता समाप्त हो जाती है। स्वतः पूर्णता स्थापित करने के निर्देश यहां.

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

शेल उपनामों का उपयोग करना

आपको वर्तमान संदर्भ और नेमस्पेस को बदलने के लिए अलग-अलग टूल की आवश्यकता नहीं है क्योंकि kubectl इसके लिए कमांड भी प्रदान करता है। हाँ, टीम kubectl config kubeconfig फ़ाइलों को संपादित करने के लिए उप-कमांड प्रदान करता है।

यहाँ पर उनमें से कुछ हैं:

kubectl config get-contexts: सभी संदर्भ प्रदर्शित करें;
kubectl config current-context: वर्तमान संदर्भ प्राप्त करें;
kubectl config use-context: वर्तमान संदर्भ बदलें;
kubectl config set-context: संदर्भ तत्व बदलें.

हालाँकि, इन कमांडों का सीधे उपयोग करना बहुत सुविधाजनक नहीं है क्योंकि ये लंबे होते हैं। आप उनके लिए शेल उपनाम बना सकते हैं जिन्हें निष्पादित करना आसान है।

मैंने इन आदेशों के आधार पर उपनामों का एक सेट बनाया जो kubectx के समान कार्यक्षमता प्रदान करता है। यहां आप उन्हें कार्य करते हुए देख सकते हैं:

ध्यान दें कि उपनाम एक इंटरैक्टिव मुक्त लुकअप इंटरफ़ेस (जैसे kubectx के इंटरैक्टिव मोड) प्रदान करने के लिए fzf का उपयोग करते हैं। इसका मतलब है कि आपको चाहिए एफजेडएफ स्थापित करेंइन उपनामों का उपयोग करने के लिए.

यहाँ स्वयं उपनामों की परिभाषाएँ दी गई हैं:

# Получить текущий контекст
alias krc='kubectl config current-context'
# Список всех контекстов
alias klc='kubectl config get-contexts -o name | sed "s/^/  /;|^  $(krc)$|s/ /*/"'
# Изменить текущий контекст
alias kcc='kubectl config use-context "$(klc | fzf -e | sed "s/^..//")"'

# Получить текущее пространство имен
alias krn='kubectl config get-contexts --no-headers "$(krc)" | awk "{print $5}" | sed "s/^$/default/"'
# Список всех пространств имен
alias kln='kubectl get -o name ns | sed "s|^.*/|  |;|^  $(krn)$|s/ /*/"'
# Изменить текущее пространство имен
alias kcn='kubectl config set-context --current --namespace "$(kln | fzf -e | sed "s/^..//")"'

इन उपनामों को सेट करने के लिए आपको उपरोक्त परिभाषाओं को अपनी फ़ाइल में जोड़ना होगा ~/.bashrc या ~/.zshrc और अपने शेल को रीबूट करें।

प्लगइन्स का उपयोग करना

Kubectl आपको प्लगइन्स लोड करने की अनुमति देता है जो मूल कमांड की तरह ही निष्पादित होते हैं। उदाहरण के लिए, आप kubectl-foo प्लगइन इंस्टॉल कर सकते हैं और कमांड निष्पादित करके इसे चला सकते हैं kubectl foo.

इस तरह से संदर्भ और नामस्थान को बदलना सुविधाजनक होगा, उदाहरण के लिए दौड़कर kubectl ctx संदर्भ बदलने के लिए और kubectl ns नेमस्पेस बदलने के लिए.

मैंने दो प्लगइन्स लिखे हैं जो ऐसा करते हैं:

प्लगइन्स का कार्य पिछले अनुभाग के उपनामों पर आधारित है।

यहां बताया गया है कि वे कैसे काम करते हैं:

ध्यान दें कि प्लगइन्स एक इंटरैक्टिव मुक्त खोज इंटरफ़ेस (जैसे kubectx का इंटरैक्टिव मोड) प्रदान करने के लिए fzf का उपयोग करते हैं। इसका मतलब है कि आपको चाहिए एफजेडएफ स्थापित करेंइन उपनामों का उपयोग करने के लिए.

प्लगइन्स इंस्टॉल करने के लिए, आपको नामित शेल स्क्रिप्ट डाउनलोड करनी होगी kubectl-ctx и kubectl-ns अपने PATH वैरिएबल में किसी भी निर्देशिका के लिए और उन्हें उदाहरण के साथ निष्पादन योग्य बनाएं। chmod +x. इसके तुरंत बाद आप उपयोग कर सकेंगे kubectl ctx и kubectl ns.

5. ऑटोएलियासेस के साथ इनपुट कम करें

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

आप सोच रहे होंगे - आपको 800 उपनाम कैसे याद हैं? लेकिन आपको उन सभी को याद रखने की आवश्यकता नहीं है, क्योंकि वे एक सरल योजना के अनुसार बनाए गए हैं, जो नीचे दी गई है:

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

kgpooyaml - kubectl पॉड्स प्राप्त करें oyaml
ksysgsvcw - kubectl -n kube-system को svc w मिलता है
ksysrmcm -kubectl -n क्यूब-सिस्टम आरएम सेमी
kgdepalsl - kubectl को सभी sl पर तैनाती मिलती है

जैसा कि आप देख सकते हैं, उपनाम घटकों से बने होते हैं, जिनमें से प्रत्येक kubectl कमांड के एक विशिष्ट तत्व का प्रतिनिधित्व करता है। प्रत्येक उपनाम में बेस कमांड, ऑपरेशन और संसाधन के लिए एक घटक और पैरामीटर के लिए कई घटक हो सकते हैं। आप बस ऊपर दिए गए चित्र के अनुसार इन घटकों को बाएँ से दाएँ "पॉप्युलेट" करें।

वर्तमान विस्तृत आरेख यहां है GitHub. वहां भी आप पा सकते हैं उपनामों की पूरी सूची.

उदाहरण के लिए, उपनाम kgpooyamlall कमांड के बराबर है kubectl get pods -o yaml --all-namespaces.

विकल्पों का सापेक्ष क्रम महत्वपूर्ण नहीं है: कमांड kgpooyamlall कमांड के बराबर है kgpoalloyaml.

आपको सभी घटकों को उपनाम के रूप में उपयोग करने की आवश्यकता नहीं है। उदाहरण के लिए k, kg, klo, ksys, kgpo भी प्रयोग किया जा सकता है. इसके अलावा, आप कमांड लाइन पर उपनाम और नियमित कमांड या विकल्प जोड़ सकते हैं:

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

के बजाए kubectl proxy तुम लिख सकते हो k proxy.
के बजाए kubectl get roles तुम लिख सकते हो kg roles (वर्तमान में रोल्स संसाधन के लिए कोई उपनाम नहीं है)।
किसी विशिष्ट पॉड के लिए डेटा प्राप्त करने के लिए, आप कमांड का उपयोग कर सकते हैं kgpo my-pod — kubectl get pod my-pod.

कृपया ध्यान दें कि कुछ उपनामों के लिए कमांड लाइन तर्क की आवश्यकता होती है। उदाहरण के लिए, उपनाम kgpol साधन kubectl get pods -l. विकल्प -l एक तर्क की आवश्यकता है - एक लेबल विशिष्टता। यदि आप उपनाम का उपयोग करते हैं तो यह ऐसा दिखेगा kgpol app=ui.

क्योंकि कुछ उपनामों के लिए तर्क की आवश्यकता होती है, उपनाम a, f, और l का उपयोग अंतिम रूप से किया जाना चाहिए।

सामान्य तौर पर, एक बार जब आप इस योजना को समझ लेते हैं, तो आप उन आदेशों से सहज रूप से उपनाम प्राप्त कर सकते हैं जिन्हें आप निष्पादित करना चाहते हैं और टाइपिंग का बहुत सारा समय बचा सकते हैं।

स्थापना

Kubectl-aliases इंस्टॉल करने के लिए, आपको फ़ाइल डाउनलोड करनी होगी .kubectl_aliases GitHub से और इसे फ़ाइल में शामिल करें ~/.bashrc या ~/.zshrc:

source ~/.kubectl_aliases

स्वत: पूर्णता

जैसा कि हमने पहले कहा, आप अक्सर कमांड लाइन पर उपनाम में अतिरिक्त शब्द जोड़ते हैं। उदाहरण के लिए:

$ kgpooyaml test-pod-d4b77b989

यदि आप kubectl कमांड पूर्णता का उपयोग करते हैं, तो संभवतः आपने संसाधन नाम जैसी चीज़ों के लिए स्वत: पूर्णता का उपयोग किया है। लेकिन क्या उपनामों का उपयोग होने पर ऐसा किया जा सकता है?

यह एक बहुत ही महत्वपूर्ण प्रश्न है क्योंकि यदि स्वत: पूर्णता काम नहीं करती है, तो आप उपनामों के कुछ लाभ खो देंगे।

उत्तर इस बात पर निर्भर करता है कि आप किस शेल का उपयोग कर रहे हैं:

Zsh के लिए, उपनाम पूर्णता बॉक्स से बाहर काम करती है।
बैश के लिए, दुर्भाग्यवश, कार्य को स्वतः पूर्ण करने के लिए कुछ कार्य की आवश्यकता होती है।

बैश में उपनामों के लिए स्वत: पूर्णता सक्षम करना

बैश के साथ समस्या यह है कि यह उपनाम को पूरा करने का प्रयास करता है (हर बार जब आप टैब दबाते हैं), न कि उस आदेश को जिसे उपनाम संदर्भित करता है (उदाहरण के लिए, Zsh करता है)। चूँकि आपके पास सभी 800 उपनामों के लिए पूर्णता स्क्रिप्ट नहीं है, इसलिए स्वत: पूर्णता काम नहीं करती है।

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

निम्नलिखित में, मैं पहले समझाऊंगा कि पूर्ण-उपनाम कैसे स्थापित करें और फिर सभी कुबेक्टल उपनामों के लिए पूर्णता सक्षम करने के लिए इसे कैसे कॉन्फ़िगर करें।

पूर्ण-उपनाम स्थापित करना

सबसे पहले, पूर्ण-उपनाम पर निर्भर करता है बैश-समापन. इसलिए, पूर्ण-उपनाम स्थापित करने से पहले, आपको यह सुनिश्चित करना होगा कि बैश-समापन स्थापित है। Linux और MacOS के लिए इंस्टालेशन निर्देश पहले ही उपलब्ध करा दिए गए हैं।

MacOS उपयोगकर्ताओं के लिए महत्वपूर्ण नोट: Kubectl स्वत: पूर्णता स्क्रिप्ट की तरह, पूर्ण-उपनाम बैश 3.2 के साथ काम नहीं करता है, जो MacOS पर डिफ़ॉल्ट है। विशेष रूप से, पूर्ण-उपनाम बैश-समापन v2 पर निर्भर करता है (brew install bash-completion@2), जिसके लिए कम से कम बैश 4.1 की आवश्यकता है। इसका मतलब यह है कि MacOS पर पूर्ण-उपनाम का उपयोग करने के लिए आपको बैश का एक नया संस्करण स्थापित करना होगा।

आपको स्क्रिप्ट डाउनलोड करनी होगी bash_completion.sh से गिटहब रिपॉजिटरी और इसे अपनी फ़ाइल में शामिल करें ~/.bashrc:

source ~/bash_completion.sh

शेल को रिबूट करने के बाद, पूर्ण-उपनाम पूरी तरह से इंस्टॉल हो जाएगा।

Kubectl उपनामों के लिए स्वत: पूर्णता सक्षम करना

तकनीकी रूप से पूर्ण-उपनाम एक रैपर फ़ंक्शन प्रदान करता है _complete_alias. यह फ़ंक्शन उपनाम की जांच करता है और उपनाम कमांड के लिए पूर्णता संकेत देता है।

किसी फ़ंक्शन को किसी विशिष्ट उपनाम के साथ संबद्ध करने के लिए, आपको अंतर्निहित बैश तंत्र का उपयोग करने की आवश्यकता है पूरा, स्थापित करने के लिए _complete_alias उपनाम पूर्णता फ़ंक्शन के रूप में।

उदाहरण के तौर पर, आइए उपनाम k लें, जो kubectl कमांड के लिए है। स्थापित करने के लिए _complete_alias इस उपनाम के पूरक फ़ंक्शन के रूप में, आपको निम्नलिखित कमांड चलानी चाहिए:

$ complete -F _complete_alias k

इसका परिणाम यह होता है कि जब भी आप किसी उपनाम k को स्वत: पूर्ण करते हैं, तो फ़ंक्शन कॉल हो जाता है _complete_alias, जो उपनाम की जांच करता है और कमांड के लिए पूर्णता संकेत देता है kubectl.

दूसरे उदाहरण के रूप में, आइए उपनाम लेते हैं kg, जो दर्शाता है kubectl get:

$ complete -F _complete_alias kg

पिछले उदाहरण की तरह, जब आप किलो को स्वत: पूर्ण करते हैं, तो आपको वही पूर्णता संकेत मिलते हैं जो आपको मिलेंगे kubectl get.

ध्यान दें कि आप अपने सिस्टम पर किसी भी उपनाम के लिए पूर्ण-उपनाम का उपयोग कर सकते हैं।

इसलिए, सभी kubectl उपनामों के लिए स्वत: पूर्णता सक्षम करने के लिए, आपको उनमें से प्रत्येक के लिए उपरोक्त आदेश चलाने की आवश्यकता है। निम्नलिखित स्निपेट बिल्कुल यही करता है, बशर्ते आपने kubectl-aliases को सेट किया हो ~/.kubectl-aliases:

for _a in $(sed '/^alias /!d;s/^alias //;s/=.*$//' ~/.kubectl_aliases); 
do
  complete -F _complete_alias "$_a"
done

कोड के इस टुकड़े को आपके में रखा जाना चाहिए ~/.bashrc, कमांड शेल को पुनरारंभ करें और सभी 800 क्यूबेक्टल उपनामों के लिए स्वत: पूर्णता उपलब्ध हो जाएगी।

6. प्लगइन्स के साथ kubectl का विस्तार

से शुरू संस्करण 1.12, कुबेक्टल समर्थन करता है प्लगइन तंत्र, जो आपको अतिरिक्त कमांड के साथ इसके कार्यों का विस्तार करने की अनुमति देता है।

यदि आप परिचित हैं गिट प्लगइन तंत्र, तो kubectl प्लगइन्स उसी सिद्धांत पर बनाए गए हैं।

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

प्लगइन्स इंस्टॉल करना

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

उदाहरण के लिए, हेलो प्लगइन को एक फ़ाइल के रूप में वितरित किया जाएगा kubectl-hello.

प्लगइन इंस्टॉल करने के लिए, आपको फ़ाइल को कॉपी करना होगा kubectl-x अपने PATH में किसी भी निर्देशिका में और इसे निष्पादन योग्य बनाएं, उदाहरण के लिए chmod +x. इसके तुरंत बाद आप प्लगइन को कॉल कर सकते हैं kubectl x.

आप अपने सिस्टम पर वर्तमान में स्थापित सभी प्लगइन्स को सूचीबद्ध करने के लिए निम्नलिखित कमांड का उपयोग कर सकते हैं:

$ kubectl plugin list

यदि आपके पास एक ही नाम के कई प्लगइन हैं, या यदि कोई प्लगइन फ़ाइल है जो निष्पादन योग्य नहीं है तो यह कमांड चेतावनियां भी प्रदर्शित करेगा।

क्रू का उपयोग करके प्लगइन्स ढूंढना और इंस्टॉल करना

Kubectl प्लगइन्स को सॉफ़्टवेयर पैकेजों की तरह साझा या पुन: उपयोग किया जा सकता है। लेकिन आप दूसरों द्वारा साझा किए गए प्लगइन्स कहां पा सकते हैं?

प्रोजेक्ट क्रू इसका उद्देश्य Kubectl प्लगइन्स को साझा करने, खोजने, स्थापित करने और प्रबंधित करने के लिए एक एकीकृत समाधान प्रदान करना है। प्रोजेक्ट खुद को "कुबेक्टल प्लगइन्स के लिए पैकेज मैनेजर" कहता है (क्रू के समान है)। शराब बनाना).

क्रू kubectl प्लगइन्स की एक सूची है जिसे आप चुन सकते हैं और इंस्टॉल कर सकते हैं। वहीं, Krew kubectl के लिए एक प्लगइन भी है।

इसका मतलब यह है कि क्रू को इंस्टॉल करना अनिवार्य रूप से किसी अन्य कुबेक्टल प्लगइन को इंस्टॉल करने जैसा ही काम करता है। आप विस्तृत निर्देश यहां पा सकते हैं गिटहब पेज.

सबसे महत्वपूर्ण क्रू कमांड हैं:

# Поиск в списке плагинов
$ kubectl krew search [<query>]
# Посмотреть информацию о плагине
$ kubectl krew info <plugin>
# Установить плагин
$ kubectl krew install <plugin>
# Обновить все плагины до последней версии
$ kubectl krew upgrade
# Посмотреть все плагины, установленные через Krew
$ kubectl krew list
# Деинсталлировать плагин
$ kubectl krew remove <plugin>

कृपया ध्यान दें कि क्रू का उपयोग करके प्लगइन्स इंस्टॉल करने से ऊपर वर्णित मानक विधि का उपयोग करके प्लगइन्स इंस्टॉल करने में कोई बाधा नहीं आती है।

कृपया ध्यान दें कि आदेश kubectl krew list केवल उन प्लगइन्स को प्रदर्शित करता है जो क्रू का उपयोग करके इंस्टॉल किए गए थे, जबकि कमांड kubectl plugin list सभी प्लगइन्स को सूचीबद्ध करता है, अर्थात क्रू का उपयोग करके इंस्टॉल किए गए और अन्य तरीकों से इंस्टॉल किए गए।

अन्यत्र प्लगइन ढूँढना

क्रू एक युवा परियोजना है, वर्तमान में की सूची केवल लगभग 30 प्लगइन्स। यदि आपको वह नहीं मिल रहा है जिसकी आपको आवश्यकता है, तो आप GitHub जैसे कहीं और प्लगइन्स पा सकते हैं।

मैं GitHub अनुभाग को देखने की अनुशंसा करता हूं kubectl-प्लगइन्स. वहां आपको दर्जनों उपलब्ध प्लगइन्स मिलेंगे जो जांचने लायक हैं।

अपने स्वयं के प्लगइन्स लिखना

आप स्वयं कर सकते हैं प्लगइन्स बनाएं - यह कठिन नहीं है. आपको एक निष्पादन योग्य बनाना होगा जो आपकी आवश्यकतानुसार काम करे, इसे नाम दें kubectl-x और ऊपर बताए अनुसार इंस्टॉल करें।

फ़ाइल एक बैश स्क्रिप्ट, एक पायथन स्क्रिप्ट, या एक संकलित GO एप्लिकेशन हो सकती है - इससे कोई फर्क नहीं पड़ता। एकमात्र शर्त यह है कि इसे सीधे ऑपरेटिंग सिस्टम में निष्पादित किया जा सकता है।

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

एक फ़ाइल बनाएं kubectl-img निम्नलिखित सामग्री:

#!/bin/bash
kubectl get pods -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'

अब फ़ाइल को निष्पादन योग्य बनाएं chmod +x kubectl-img और इसे अपने PATH में किसी भी निर्देशिका में ले जाएँ। इसके तुरंत बाद आप प्लगइन का उपयोग कर सकते हैं kubectl img.

जैसा कि उल्लेख किया गया है, kubectl प्लगइन्स किसी भी प्रोग्रामिंग या स्क्रिप्टिंग भाषा में लिखे जा सकते हैं। यदि आप शेल स्क्रिप्ट का उपयोग कर रहे हैं, तो प्लगइन के भीतर से kubectl को आसानी से कॉल करने में सक्षम होने का लाभ होगा। हालाँकि, आप वास्तविक प्रोग्रामिंग भाषाओं का उपयोग करके अधिक जटिल प्लगइन्स लिख सकते हैं कुबेरनेट्स क्लाइंट लाइब्रेरी. अगर आप गो का इस्तेमाल कर रहे हैं तो आप भी इस्तेमाल कर सकते हैं सीएलआई-रनटाइम लाइब्रेरी, जो विशेष रूप से kubectl प्लगइन्स लिखने के लिए मौजूद है।

अपने प्लगइन्स कैसे साझा करें

यदि आपको लगता है कि आपके प्लगइन्स दूसरों के लिए उपयोगी हो सकते हैं, तो बेझिझक इसे GitHub पर साझा करें। उन्हें विषय में अवश्य जोड़ें kubectl-प्लगइन्स.

आप यह भी अनुरोध कर सकते हैं कि आपका प्लगइन इसमें जोड़ा जाए क्रू सूची. इसे कैसे करें इस पर निर्देश दिए गए हैं GitHub रिपॉजिटरी.

आदेश पूरा होना

प्लगइन्स वर्तमान में स्वत: पूर्णता का समर्थन नहीं करते हैं। यानी आपको प्लगइन का पूरा नाम और तर्कों का पूरा नाम दर्ज करना होगा।

इस फ़ंक्शन के लिए GitHub kubectl रिपॉजिटरी है खुला अनुरोध. इसलिए संभव है कि यह सुविधा भविष्य में किसी समय लागू की जाएगी.

शुभकामनाएँ !!!

विषय पर और क्या पढ़ना है:

स्रोत: www.habr.com

Kubectl का अधिक प्रभावी ढंग से उपयोग कैसे करें: एक विस्तृत मार्गदर्शिका