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

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

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

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

परिचय: kubectl क्या है

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

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

तकनीकी रूप से, kubectl एक Kubernetes API क्लाइंट है।

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

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

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

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

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

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

$ kubectl create -f replicaset.yaml

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

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

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

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

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

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

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

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

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

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

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

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

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

1. कुबेलेट — कार्यकर्ता नोड पर कंटेनरों के लॉन्च का प्रबंधन करता है।

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

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

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

1. करने के बाद kubectl create -f replicaset.yaml API सर्वर आपके ReplicaSet संसाधन परिभाषा को संग्रहण में संग्रहीत करता है:

   

2. इसके बाद, नियंत्रक प्रबंधक में रेप्लिकासेट नियंत्रक लॉन्च किया जाता है, जो रेप्लिकासेट संसाधनों के निर्माण, संशोधन और विलोपन को संभालता है:

   

3. ReplicaSet नियंत्रक ReplicaSet में प्रत्येक प्रतिकृति के लिए एक पॉड परिभाषा बनाता है (ReplicaSet परिभाषा में पॉड टेम्पलेट के अनुसार) और उन्हें स्टोर में संग्रहीत करता है:

   

4. शेड्यूलर प्रारंभ होता है, उन पॉड्स की निगरानी करता है जिन्हें अभी तक किसी भी कार्यकर्ता नोड को नहीं सौंपा गया है:

   

5. शेड्यूलर प्रत्येक पॉड के लिए एक उपयुक्त कार्यकर्ता नोड का चयन करता है और इस जानकारी को स्टोरेज में पॉड परिभाषा में जोड़ता है:

   

6. जिस कार्यकर्ता नोड को पॉड सौंपा गया है, उस पर Kubelet लॉन्च किया जाता है और उस नोड को सौंपे गए पॉड की निगरानी करता है:

   

7. क्यूबलेट स्टोरेज से पॉड परिभाषा को पढ़ता है और नोड पर कंटेनर लॉन्च करने के लिए डॉकर जैसे कंटेनर रनटाइम को निर्देश देता है:

   

नीचे इस विवरण का पाठ्य संस्करण दिया गया है।

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

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

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

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

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

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

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

Kubernetes API की भूमिका

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

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

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

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

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

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

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

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

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

1. कमांड कम्पलीशन के साथ अपनी टाइपिंग की गति बढ़ाएं

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

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

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

कमांड पूर्णता Bash और Zsh शेल्स के लिए काम करती है।

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

कमांड कम्पलीशन कैसे काम करता है

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

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

$ kubectl completion bash

Или:

$ kubectl completion zsh

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

На практике — способ подключения отличается для Bash (включая различия между Linux и MacOS) и Zsh. Ниже мы рассмотрим все эти варианты.

Bash в Linux

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

$ sudo apt-get install bash-completion

Или:

$ yum install bash-completion

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

$ type _init_completion

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

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

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

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

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

source <(kubectl completion bash)

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

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

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

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

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

MacOS में बैश

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

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

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

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

बैश स्वतःपूर्णता स्क्रिप्ट परियोजना विशिष्ट है बैश-समापन, इसलिए आपको पहले इसे स्थापित करना होगा।

आप bash-completion का उपयोग करके इसे स्थापित कर सकते हैं homebrew:

$ brew install bash-completion@2

यहां @2 kubectl पूर्णता के लिए bash-पूर्णता v2 की आवश्यकता होती है, और bash-पूर्णता v2 के लिए कम से कम Bash संस्करण 2 की आवश्यकता होती है।

कमांड आउटपुट 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

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

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

अंततः ये सभी विकल्प समान हैं।

Zsh

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

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

source <(kubectl completion zsh)

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

autoload -Uz compinit
compinit

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

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

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

आदेश का प्रारूप इस प्रकार है:

$ kubectl explain resource[.field]...

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

По умолчанию 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.

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

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

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

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

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

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

Kubectl explain सीमित संख्या में 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 संसाधन फ़ील्ड सूचियाँ हैं, और यह ऑपरेटर आपको उन सूचियों के तत्वों का चयन करने की अनुमति देता है। इसका प्रयोग अक्सर किसी सूची में सभी आइटमों का चयन करने के लिए [*] जैसे वाइल्डकार्ड के साथ किया जाता है।

आवेदन उदाहरण

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

1. पॉड्स के लिए कंटेनर छवियाँ प्रदर्शित करना:

   $ 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

   यह कमांड प्रत्येक पॉड के लिए कंटेनर छवियों के नाम प्रदर्शित करता है।

   याद रखें कि एक पॉड में कई कंटेनर हो सकते हैं, ऐसी स्थिति में छवि के नाम एक पंक्ति में सूचीबद्ध होंगे, अल्पविराम से अलग करके।

2. नोड उपलब्धता क्षेत्र प्रदर्शित करना:

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

   लेबल Kubernetes संसाधन विनिर्देश का हिस्सा नहीं हैं, इसलिए आपको उनके बारे में जानकारी नहीं मिलेगी एपीआई मैनुअल. हालाँकि, यदि आप YAML या JSON प्रारूप में नोड जानकारी का अनुरोध करते हैं तो उन्हें (किसी भी अन्य लेबल की तरह) देखा जा सकता है:

   $ kubectl get nodes -o yaml
   # или
   $ kubectl get nodes -o json

   संसाधन विनिर्देशों का अध्ययन करने के अलावा, यह संसाधनों के बारे में अधिक जानने का एक अच्छा तरीका है।

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

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

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

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

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

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

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

kubeconfig फ़ाइलें

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

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

• क्लस्टर — क्लस्टर सर्वर API का URL.
• उपयोगकर्ता - क्लस्टर में उपयोगकर्ता प्रमाणीकरण क्रेडेंशियल.
• नामस्थान - क्लस्टर में शामिल होने पर उपयोग किया जाने वाला नामस्थान.

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

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

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

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

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

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

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

ध्यान दें कि kubectl भी विकल्प प्रदान करता है --cluster, --user, --namespace и --context, जो आपको व्यक्तिगत तत्वों और वर्तमान संदर्भ को अधिलेखित करने की अनुमति देता है, भले ही kubeconfig फ़ाइल में क्या सेट किया गया हो। देखना 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 का उपयोग करते हैं। इसका मतलब है कि आपको जरूरत है 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 नामस्थान बदलने के लिए.

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

• kubectl-ctx
• kubectl-एनएस

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

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

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

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

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

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

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

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

1. kgpooyaml - kubectl फली प्राप्त करें oyaml
2. ksysgsvcw - kubectl -n kube-system को svc w मिलता है
3. ksysrmcm -kubectl -n क्यूब-सिस्टम आरएम सेमी
4. kgdepallsl - kubectl सभी तैनाती sl प्राप्त करें

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

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

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

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

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

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

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

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

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

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

इंस्टालेशन

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

source ~/.kubectl_aliases

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

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

$ kgpooyaml test-pod-d4b77b989

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

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

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

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

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

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

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

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

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

सबसे पहले, पूर्ण-उपनाम इस पर निर्भर करता है बैश-समापन. Поэтому перед установкой complete-alias необходимо убедиться, что bash-completion установлен. Инструкции по установке были даны ранее для Linux и MacOS.

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

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

source ~/bash_completion.sh

शेल को पुनः आरंभ करने के बाद, पूर्ण-उपनाम पूरी तरह से स्थापित हो जाएगा।

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

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

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

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

$ complete -F _complete_alias k

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

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

$ complete -F _complete_alias kg

पिछले उदाहरण की तरह, जब आप 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 kubectl उपनामों के लिए स्वतः पूर्णता उपलब्ध हो जाएगी।

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

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

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

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

प्लगइन्स स्थापित करना

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

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

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

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

$ kubectl plugin list

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

Krew के साथ प्लगइन्स ढूँढना और इंस्टॉल करना

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

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

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

इसका मतलब यह है कि Krew को स्थापित करना अनिवार्य रूप से किसी भी अन्य kubectl प्लगइन को स्थापित करने की तरह काम करता है। आप विस्तृत निर्देश यहां पा सकते हैं GitHub पेज.

सबसे महत्वपूर्ण क्रू आदेश हैं:

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

कृपया ध्यान दें कि Krew का उपयोग करके प्लगइन्स स्थापित करना ऊपर वर्णित मानक विधि का उपयोग करके प्लगइन्स स्थापित करने में हस्तक्षेप नहीं करता है।

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

अन्य स्थानों पर प्लगइन्स खोजें

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

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

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

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

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

आइये अभी एक उदाहरण प्लगइन बनाएं। पिछले अनुभाग में, आपने प्रत्येक पॉड के लिए कंटेनरों को सूचीबद्ध करने के लिए kubectl कमांड का उपयोग किया था। आप इस कमांड को आसानी से एक प्लगइन में बदल सकते हैं जिसे आप कॉल कर सकते हैं, उदाहरण के लिए, 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 को कॉल कर सकते हैं। हालाँकि, आप वास्तविक प्रोग्रामिंग भाषाओं में अधिक जटिल प्लगइन्स लिख सकते हैं कुबेरनेट्स क्लाइंट लाइब्रेरी. यदि आप Go का उपयोग करते हैं, तो आप इसका भी उपयोग कर सकते हैं cli-रनटाइम लाइब्रेरी, जो विशेष रूप से kubectl प्लगइन्स लिखने के लिए मौजूद है।

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

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

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

आदेश पूर्णता

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

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

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

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

1. कुबेरनेट्स में ऑटोस्केलिंग के तीन स्तर और उनका प्रभावी ढंग से उपयोग कैसे करें.
2. कार्यान्वयन के लिए टेम्पलेट के साथ पाइरेसी की भावना में Kubernetes.
3. टेलीग्राम में हमारा चैनल अराउंड कुबेरनेट्स.

स्रोत: www.habr.com