kubectl अधिक प्रभावीपणे कसे वापरावे: तपशीलवार मार्गदर्शक

जर तुम्ही Kubernetes सह काम करत असाल, तर kubectl ही कदाचित तुम्ही सर्वात जास्त वापरत असलेल्या युटिलिटींपैकी एक आहे. आणि जेव्हा तुम्ही एखाद्या विशिष्ट साधनासह काम करताना बराच वेळ घालवता, तेव्हा त्याचा चांगला अभ्यास करण्यासाठी आणि ते प्रभावीपणे कसे वापरावे हे शिकण्यासाठी ते पैसे देते.

संघ Mail.ru वरून Kubernetes aaS डॅनियल वेइबेलच्या लेखाचा अनुवाद केला आहे ज्यामध्ये तुम्हाला kubectl सह प्रभावीपणे काम करण्यासाठी टिपा आणि युक्त्या सापडतील. हे तुम्हाला कुबर्नेट्सची सखोल माहिती मिळविण्यात देखील मदत करेल.

लेखकाच्या मते, लेखाचे उद्दिष्ट हे आहे की कुबरनेटसह तुमचे दैनंदिन कार्य केवळ अधिक कार्यक्षमच नाही तर अधिक आनंददायक देखील आहे!

परिचय: kubectl म्हणजे काय

तुम्ही kubectl अधिक प्रभावीपणे वापरण्यास शिकण्यापूर्वी, तुम्हाला ते काय आहे आणि ते कसे कार्य करते याची मूलभूत माहिती मिळवणे आवश्यक आहे.

वापरकर्त्याच्या दृष्टीकोनातून, kubectl हे एक नियंत्रण पॅनेल आहे जे तुम्हाला Kubernetes ऑपरेशन्स करण्यास अनुमती देते.

तांत्रिकदृष्ट्या, kubectl एक Kubernetes API क्लायंट आहे.

Kubernetes API एक HTTP REST API आहे. हा API खरा Kubernetes वापरकर्ता इंटरफेस आहे, ज्याद्वारे तो पूर्णपणे नियंत्रित केला जातो. याचा अर्थ असा की प्रत्येक Kubernetes ऑपरेशन API एंडपॉइंट म्हणून उघड केले जाते आणि त्या एंडपॉइंटला HTTP विनंतीसह केले जाऊ शकते.

म्हणून, kubectl चे मुख्य काम Kubernetes API ला HTTP विनंत्या करणे आहे:

Kubernetes एक पूर्णपणे संसाधन-देणारं प्रणाली आहे. याचा अर्थ ते संसाधनांची अंतर्गत स्थिती राखते आणि सर्व कुबर्नेट्स ऑपरेशन्स CRUD ऑपरेशन्स आहेत.

ही संसाधने व्यवस्थापित करून तुम्ही कुबर्नेट्सच्या पूर्ण नियंत्रणात आहात आणि कुबर्नेट्स संसाधनांच्या सध्याच्या स्थितीच्या आधारावर काय करावे हे शोधून काढतात. या कारणास्तव, 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 संदर्भामध्ये सूचीबद्ध केलेल्या एंडपॉइंट पाथमध्ये API सर्व्हर URL जोडणे आवश्यक आहे.

म्हणून, जेव्हा तुम्ही वरील कमांड कार्यान्वित करता, तेव्हा kubectl वरील API एंडपॉइंटला HTTP POST विनंती पाठवते. तुम्ही फाइलमध्ये दिलेली ReplicaSet व्याख्या replicaset.yaml, विनंतीच्या मुख्य भागामध्ये पाठवले जाते.

कुबेरनेट क्लस्टरशी संवाद साधणाऱ्या सर्व कमांडसाठी कुबेक्टल अशा प्रकारे कार्य करते. या सर्व प्रकरणांमध्ये, kubectl फक्त योग्य Kubernetes API एंडपॉइंट्सना HTTP विनंत्या करते.

कृपया लक्षात घ्या की तुम्ही युटिलिटी वापरून कुबर्नेट्स पूर्णपणे व्यवस्थापित करू शकता जसे की curlKubernetes API ला स्वतः HTTP विनंत्या पाठवून. Kubectl फक्त कुबर्नेट्स API वापरणे सोपे करते.

कुबेक्टल म्हणजे काय आणि ते कसे कार्य करते याची ही मूलभूत माहिती आहे. परंतु कुबर्नेट्स API बद्दल आणखी एक गोष्ट आहे जी प्रत्येक kubectl वापरकर्त्याला माहित असणे आवश्यक आहे. कुबर्नेट्सच्या आतील जगाकडे एक झटकन नजर टाकूया.

कुबर्नेट्सचे आंतरिक जग

कुबर्नेट्समध्ये स्वतंत्र घटकांचा संच असतो जो क्लस्टर नोड्सवर स्वतंत्र प्रक्रिया म्हणून चालतो. काही घटक मास्टर नोड्सवर चालतात, इतर वर्कर नोड्सवर, प्रत्येक घटक स्वतःचे विशिष्ट कार्य करत असतो.

मुख्य नोड्सवरील सर्वात महत्वाचे घटक येथे आहेत:

1. भांडार - संसाधन व्याख्या संग्रहित करते (सहसा ते इ).
2. API सर्व्हर — API प्रदान करते आणि स्टोरेज व्यवस्थापित करते.
3. नियंत्रक व्यवस्थापक - संसाधन स्थिती वैशिष्ट्यांचे पालन करते याची खात्री करते.
4. शेड्युलर — कामगार नोड्सवर शेड्यूल शेड्यूल.

आणि कामगार नोड्सवरील एक सर्वात महत्वाचा घटक येथे आहे:

1. कुबेलेट — कार्यरत नोडवर कंटेनरचे प्रक्षेपण व्यवस्थापित करते.

हे घटक एकत्र कसे कार्य करतात हे समजून घेण्यासाठी, एक उदाहरण पाहू या.

आपण नुकतेच पूर्ण केले आहे असे समजू kubectl create -f replicaset.yaml, ज्यानंतर kubectl ने HTTP POST विनंती केली ReplicaSet API एंडपॉइंट (ReplicaSet संसाधन व्याख्या पास करणे).

क्लस्टरमध्ये काय चालले आहे?

1. केल्यावर kubectl create -f replicaset.yaml API सर्व्हर तुमची ReplicaSet संसाधन व्याख्या स्टोरेजमध्ये संग्रहित करतो:

   

2. पुढे, कंट्रोलर मॅनेजरमध्ये ReplicaSet कंट्रोलर लाँच केला जातो, जो ReplicaSet संसाधने तयार करणे, बदल करणे आणि हटवणे हाताळतो:

   

3. ReplicaSet कंट्रोलर प्रत्येक ReplicaSet प्रतिकृतीसाठी पॉड व्याख्या तयार करतो (ReplicaSet व्याख्येतील पॉड टेम्प्लेटनुसार) आणि त्यांना स्टोरेजमध्ये संग्रहित करतो:

   

4. शेड्युलर लॉन्च केले आहे, ट्रॅकिंग पॉड्स जे अद्याप कोणत्याही कामगार नोड्सना नियुक्त केले गेले नाहीत:

   

5. शेड्युलर प्रत्येक पॉडसाठी योग्य वर्कर नोड निवडतो आणि ही माहिती स्टोअरमधील पॉड परिभाषामध्ये जोडतो:

   

6. ज्या वर्कर नोडवर पॉड नियुक्त केला जातो, कुबेलेट लाँच केला जातो, तो या नोडला नियुक्त केलेल्या पॉड्सचा मागोवा घेतो:

   

7. कुबेलेट स्टोरेजमधून पॉड व्याख्या वाचते आणि कंटेनर रनटाइमला निर्देश देते, जसे की डॉकर, नोडवर कंटेनर लॉन्च करण्यासाठी:

   

खाली या वर्णनाची मजकूर आवृत्ती आहे.

ReplicaSet निर्मिती एंडपॉइंटला API विनंती API सर्व्हरद्वारे प्रक्रिया केली जाते. API सर्व्हर विनंतीचे प्रमाणीकरण करतो आणि ReplicaSet संसाधन परिभाषा स्टोरेजमध्ये संग्रहित करतो.

हा कार्यक्रम ReplicaSet कंट्रोलर सुरू करतो, जो कंट्रोलर मॅनेजरची सबप्रोसेस आहे. ReplicaSet कंट्रोलर स्टोअरमधील ReplicaSet संसाधने तयार करणे, अद्यतनित करणे आणि हटवणे यावर लक्ष ठेवतो आणि जेव्हा हे घडते तेव्हा इव्हेंट सूचना प्राप्त करते.

ReplicaSet कंट्रोलरचे काम हे सुनिश्चित करणे आहे की आवश्यक संख्येने ReplicaSet पॉड्स अस्तित्वात आहेत. आमच्या उदाहरणामध्ये, अद्याप कोणतेही पॉड्स अस्तित्वात नाहीत, म्हणून ReplicaSet कंट्रोलर या पॉड व्याख्या तयार करतो (ReplicaSet व्याख्येतील पॉड टेम्पलेटनुसार) आणि त्यांना स्टोरेजमध्ये संग्रहित करतो.

नवीन पॉड्सची निर्मिती शेड्युलरद्वारे केली जाते जी पॉड व्याख्यांचा मागोवा ठेवते जी अद्याप कामगार नोड्ससाठी शेड्यूल केलेली नाही. शेड्युलर प्रत्येक पॉडसाठी योग्य वर्कर नोड निवडतो आणि पॉडच्या व्याख्या रेपॉजिटरीमध्ये अपडेट करतो.

लक्षात घ्या की या बिंदूपर्यंत, क्लस्टरमध्ये कुठेही वर्कलोड कोड चालू नव्हता. आतापर्यंत जे काही केले आहे - हे मास्टर नोडवरील रेपॉजिटरीमध्ये संसाधने तयार करणे आणि अद्यतनित करणे आहे.

शेवटचा कार्यक्रम कुबेलेट्स ट्रिगर करतो, जे त्यांच्या कार्यकर्ता नोड्ससाठी शेड्यूल केलेल्या पॉड्सचे निरीक्षण करतात. वर्कर नोडचे कुबेलेट ज्यावर तुमची ReplicaSet पॉड्स इन्स्टॉल केली आहेत त्यांनी कंटेनर रनटाइमला, जसे की Docker ला आवश्यक कंटेनर इमेज डाउनलोड करण्यासाठी आणि त्या चालवायला सांगणे आवश्यक आहे.

या टप्प्यावर, तुमचा ReplicaSet अनुप्रयोग शेवटी चालू आहे!

Kubernetes API ची भूमिका

तुम्ही मागील उदाहरणात पाहिल्याप्रमाणे, Kubernetes घटक (API सर्व्हर आणि स्टोरेज वगळता) स्टोरेजमधील रिसोर्सेसमधील बदलांवर लक्ष ठेवतात आणि स्टोरेजमधील रिसोर्सेसची माहिती बदलतात.

अर्थात, हे घटक स्टोरेजशी थेट संवाद साधत नाहीत, परंतु केवळ कुबर्नेट्स API द्वारे.

खालील उदाहरणे विचारात घ्या:

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

तुम्ही बघू शकता, हे समान API आहे जे kubectl ऍक्सेस करते. अंतर्गत घटक आणि बाह्य वापरकर्त्यांसाठी समान API वापरणे ही Kubernetes डिझाइनमधील मूलभूत संकल्पना आहे.

आता आम्ही कुबर्नेट्स कसे कार्य करतो याचा सारांश देऊ शकतो:

1. स्टोरेज स्टोअर्स सांगतात, म्हणजेच कुबरनेट संसाधने.
2. API सर्व्हर स्टोरेजला Kubernetes API च्या स्वरूपात इंटरफेस प्रदान करतो.
3. इतर सर्व Kubernetes घटक आणि वापरकर्ते API द्वारे Kubernetes स्थिती (संसाधने) वाचतात, निरीक्षण करतात आणि हाताळतात.

या संकल्पना जाणून घेतल्याने तुम्हाला kubectl अधिक चांगल्या प्रकारे समजून घेण्यात आणि त्यातून जास्तीत जास्त फायदा मिळवण्यात मदत होईल.

आता काही विशिष्ट टिप्स आणि युक्त्या पाहू ज्या kubectl सह तुमची उत्पादकता सुधारण्यास मदत करतील.

1. कमांड पूर्णता वापरून इनपुटची गती वाढवा

kubectl सह कार्यप्रदर्शन सुधारण्यासाठी सर्वात उपयुक्त, परंतु बर्‍याचदा दुर्लक्षित केलेले तंत्र म्हणजे कमांड पूर्ण करणे.

कमांड कम्प्लीशन तुम्हाला टॅब की वापरून kubectl कमांडचे भाग आपोआप पूर्ण करू देते. हे उपकमांड, पर्याय आणि आर्ग्युमेंट्ससाठी कार्य करते, ज्यामध्ये संसाधनांच्या नावांसारख्या जटिल गोष्टींचा समावेश आहे.

kubectl कमांड पूर्ण करणे कसे कार्य करते ते पहा:

Bash आणि Zsh शेलसाठी कमांड पूर्ण करणे कार्य करते.

अधिकृत मार्गदर्शक स्वयंपूर्णता सेट करण्यासाठी तपशीलवार सूचना आहेत, परंतु खाली आम्ही एक छोटा उतारा देऊ.

कमांड पूर्ण करणे कसे कार्य करते

कमांड कम्प्लिशन हे एक शेल वैशिष्ट्य आहे जे पूर्णत्व स्क्रिप्ट वापरून कार्य करते. एक्स्टेंशन स्क्रिप्ट ही शेल स्क्रिप्ट असते जी विशिष्ट कमांडसाठी एक्स्टेंशनचे वर्तन परिभाषित करते.

Kubectl खालील आदेशांचा वापर करून Bash आणि Zsh साठी एक्स्टेंशन स्क्रिप्ट स्वयंचलितपणे व्युत्पन्न करते आणि आउटपुट करते:

$ kubectl completion bash

किंवा:

$ kubectl completion zsh

सिद्धांतानुसार, या आदेशांचे आउटपुट योग्य कमांड शेलशी जोडणे पुरेसे आहे जेणेकरून kubectl कमांडस पूरक ठरू शकेल.

व्यवहारात, बॅश (लिनक्स आणि मॅकओएसमधील फरकांसह) आणि Zsh साठी कनेक्शन पद्धत वेगळी आहे. आम्ही खाली हे सर्व पर्याय पाहू.

लिनक्स वर बॅश

बॅश पूर्णता स्क्रिप्ट बॅश-कम्प्लिशन पॅकेजवर अवलंबून असते, म्हणून तुम्हाला ते प्रथम स्थापित करणे आवश्यक आहे:

$ sudo apt-get install bash-completion

किंवा:

$ yum install bash-completion

खालील आदेश वापरून पॅकेज यशस्वीरित्या स्थापित झाले आहे याची चाचणी घेऊ शकता:

$ type _init_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-completion मध्ये स्वयंचलितपणे समाविष्ट केले जातात.

दोन्ही पर्याय तितकेच लागू आहेत.

शेल रीस्टार्ट केल्यानंतर, kubectl कमांड पूर्ण करणे कार्य करेल.

MacOS वर बॅश

MacOS वर सेटअप थोडे अधिक क्लिष्ट आहे. वस्तुस्थिती अशी आहे की डीफॉल्टनुसार, MacOS Bash आवृत्ती 3.2 वापरते आणि kubectl स्वयंपूर्ण स्क्रिप्टसाठी किमान 4.1 ची Bash आवृत्ती आवश्यक आहे आणि Bash 3.2 मध्ये कार्य करत नाही.

MacOS वर Bash ची जुनी आवृत्ती वापरण्याशी संबंधित परवाना समस्या आहेत. Bash आवृत्ती 4 GPLv3 अंतर्गत परवानाकृत आहे, जी Apple द्वारे समर्थित नाही.

MacOS वर kubectl स्वयंपूर्णता कॉन्फिगर करण्यासाठी, तुम्हाला Bash ची अधिक अलीकडील आवृत्ती स्थापित करणे आवश्यक आहे. तुम्‍ही तुमच्‍या डीफॉल्‍ट शेल म्‍हणून अपडेट केलेले बॅश देखील सेट करू शकता, जे तुम्‍हाला भविष्‍यात अनेक समस्यांपासून वाचवेल. हे अवघड नाही, तपशील लेखात दिलेला आहे "MacOS वर बॅश अपडेट करत आहे».

सुरू ठेवण्यापूर्वी, तुम्ही बॅशची अलीकडील आवृत्ती वापरत असल्याची खात्री करा (आउटपुट तपासा bash --version).

बॅश पूर्णत्वाची स्क्रिप्ट प्रकल्पानुसार बदलते bash-पूर्णता, म्हणून आपण प्रथम ते स्थापित करणे आवश्यक आहे.

वापरून तुम्ही bash-completion इन्स्टॉल करू शकता होमब्री:

$ brew install bash-completion@2

तो आहे @2 bash-completion version 2 चा अर्थ आहे. kubectl autocompletion साठी bash-completion v2 आवश्यक आहे आणि bash-completion v2 ला किमान Bash आवृत्ती 4.1 आवश्यक आहे.

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

परिणामी, हे सर्व पर्याय समतुल्य आहेत.

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 पॉड च्या संसाधन वर्णन मध्ये. मध्ये अधिक तपशील मिळू शकतात API मार्गदर्शक किंवा कमांड टाईप करा 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 स्पष्टीकरण मर्यादित संख्येने 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. क्लस्टर सार्वजनिक क्लाउडमध्ये चालू असल्यास, हे लेबल स्वयंचलितपणे तयार केले जाते आणि प्रत्येक नोडसाठी उपलब्धता क्षेत्रांच्या नावांनी भरले जाते.

   लेबले कुबर्नेट्स रिसोर्स स्पेसिफिकेशनचा भाग नाहीत, त्यामुळे तुम्हाला त्यांच्याबद्दल माहिती मिळणार नाही API मार्गदर्शक. तथापि, तुम्ही YAML किंवा JSON फॉरमॅटमध्ये नोड्सबद्दल माहितीची विनंती केल्यास ते (इतर कोणत्याही लेबलांप्रमाणे) पाहिले जाऊ शकतात:

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

   संसाधन तपशील शिकण्याव्यतिरिक्त, संसाधनांबद्दल अधिक जाणून घेण्याचा हा एक चांगला मार्ग आहे.

4. क्लस्टर आणि नेमस्पेसमध्ये सहजपणे स्विच करा

जेव्हा kubectl Kubernetes API ला विनंती करते, तेव्हा ते कनेक्शनसाठी सर्व आवश्यक पॅरामीटर्स मिळविण्यासाठी प्रथम kubeconfig फाइल वाचते.

डीफॉल्टनुसार kubeconfig फाइल आहे ~/.kube/config. सामान्यत: ही फाईल विशेष कमांडद्वारे तयार किंवा अपडेट केली जाते.

जेव्हा तुम्ही एकाधिक क्लस्टर्ससह कार्य करता, तेव्हा तुमच्या kubeconfig फाइलमध्ये त्या सर्व क्लस्टरशी कनेक्ट करण्यासाठी सेटिंग्ज असतात. तुम्ही कोणत्या क्लस्टरसोबत काम करत आहात हे kubectl कमांडला सांगण्यासाठी तुम्हाला एक मार्ग हवा आहे.

क्लस्टरमध्ये, तुम्ही अनेक नेमस्पेस तयार करू शकता—भौतिक क्लस्टरमध्ये व्हर्च्युअल क्लस्टरचा एक प्रकार. kubeconfig फाइलवर आधारित कोणते नेमस्पेस वापरायचे हे देखील Kubectl ठरवते. याचा अर्थ तुम्हाला kubectl कमांडला कोणत्या नेमस्पेससह कार्य करावे हे सांगण्याचा मार्ग देखील आवश्यक आहे.

हे कसे कार्य करते आणि ते प्रभावीपणे कसे कार्य करते हे या प्रकरणात आम्ही स्पष्ट करू.

लक्षात घ्या की तुमच्याकडे KUBECONFIG पर्यावरण व्हेरिएबलमध्ये सूचीबद्ध केलेल्या एकाधिक kubeconfig फाइल्स असू शकतात. या प्रकरणात, रनटाइमच्या वेळी या सर्व फायली एका सामान्य कॉन्फिगरेशनमध्ये एकत्रित केल्या जातील. तुम्ही पॅरामीटरसह kubectl चालवून डिफॉल्ट kubeconfig फाइल देखील बदलू शकता --kubeconfig. दिसत अधिकृत दस्तऐवजीकरण.

kubeconfig फाइल्स

kubeconfig फाइलमध्ये नेमके काय समाविष्ट आहे ते पाहूया:

तुम्ही बघू शकता, kubeconfig फाइलमध्ये संदर्भांचा संच आहे. संदर्भामध्ये तीन घटक असतात:

• क्लस्टर — क्लस्टर सर्व्हरची API URL.
• वापरकर्ता - क्लस्टरमधील वापरकर्ता प्रमाणीकरण क्रेडेन्शियल्स.
• नेमस्पेस - क्लस्टरमध्ये सामील होताना वापरलेली नेमस्पेस.

सराव मध्ये, ते त्यांच्या kubeconfig मध्ये प्रति क्लस्टर एक संदर्भ वापरतात. तथापि, तुमच्याकडे प्रति क्लस्टर अनेक संदर्भ असू शकतात, वापरकर्ता किंवा नेमस्पेस द्वारे भिन्न. तथापि, हे बहु-संदर्भ कॉन्फिगरेशन असामान्य आहे, म्हणून क्लस्टर आणि संदर्भांमध्ये सामान्यतः एक-टू-वन मॅपिंग असते.

कोणत्याही वेळी, संदर्भांपैकी एक वर्तमान आहे:

जेव्हा kubectl कॉन्फिगरेशन फाइल वाचते, तेव्हा ती नेहमी वर्तमान संदर्भातील माहिती घेते. वरील उदाहरणात, kubectl Hare क्लस्टरशी कनेक्ट होईल.

त्यानुसार, दुसर्‍या क्लस्टरवर जाण्यासाठी, तुम्हाला kubeconfig फाइलमधील वर्तमान संदर्भ बदलण्याची आवश्यकता आहे:

आता kubectl फॉक्स क्लस्टरशी कनेक्ट होईल.

त्याच क्लस्टरमधील वेगळ्या नेमस्पेसवर स्विच करण्यासाठी, तुम्हाला सध्याच्या संदर्भासाठी नेमस्पेस घटकाचे मूल्य बदलणे आवश्यक आहे:

वरील उदाहरणात, kubectl फॉक्स क्लस्टरचे प्रॉड नेमस्पेस वापरेल (पूर्वी चाचणी नेमस्पेस सेट केले होते).

लक्षात घ्या की kubectl देखील पर्याय प्रदान करते --cluster, --user, --namespace и --context, जे तुम्हाला kubeconfig मध्ये काय सेट केले आहे याची पर्वा न करता, वैयक्तिक घटक आणि वर्तमान संदर्भ स्वतःच अधिलिखित करण्याची परवानगी देते. दिसत kubectl options.

सिद्धांतानुसार, आपण kubeconfig मधील सेटिंग्ज व्यक्तिचलितपणे बदलू शकता. पण गैरसोयीचे आहे. या ऑपरेशन्स सुलभ करण्यासाठी, विविध उपयुक्तता आहेत ज्या आपल्याला स्वयंचलितपणे पॅरामीटर्स बदलण्याची परवानगी देतात.

kubectx वापरा

क्लस्टर आणि नेमस्पेस दरम्यान स्विच करण्यासाठी एक अतिशय लोकप्रिय उपयुक्तता.

युटिलिटी कमांड प्रदान करते kubectx и kubens क्रमशः वर्तमान संदर्भ आणि नेमस्पेस बदलण्यासाठी.

नमूद केल्याप्रमाणे, वर्तमान संदर्भ बदलणे म्हणजे क्लस्टर बदलणे जर तुमच्याकडे प्रति क्लस्टर फक्त एकच संदर्भ असेल.

या आज्ञा चालवण्याचे एक उदाहरण येथे आहे:

मूलत:, या कमांड्स वर वर्णन केल्याप्रमाणे फक्त kubeconfig फाइल संपादित करतात.

स्थापित करण्यासाठी kubectx, वरील सूचनांचे अनुसरण करा जिथूब

दोन्ही कमांड्स संदर्भ आणि नेमस्पेस नावांच्या स्वयंपूर्णतेला समर्थन देतात, ज्यामुळे त्यांना पूर्णपणे टाइप करण्याची आवश्यकता नाहीशी होते. स्वयंपूर्णता सेट करण्यासाठी सूचना येथे.

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

शेल उपनाम वापरणे

वर्तमान संदर्भ आणि नेमस्पेस बदलण्यासाठी तुम्हाला वेगळ्या साधनांची आवश्यकता नाही कारण kubectl यासाठी कमांड देखील प्रदान करते. होय, संघ kubectl config kubeconfig फाइल्स संपादित करण्यासाठी subcommands पुरवते.

त्यापैकी काही आहेत:

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

तथापि, या आज्ञा थेट वापरणे फार सोयीचे नाही कारण ते लांब आहेत. तुम्ही त्यांच्यासाठी शेल उपनाम बनवू शकता जे कार्यान्वित करणे सोपे आहे.

मी या आदेशांवर आधारित उपनामांचा एक संच तयार केला आहे जो kubectx सारखी कार्यक्षमता प्रदान करतो. येथे आपण त्यांना क्रिया करताना पाहू शकता:

लक्षात ठेवा की उपनाव एक परस्पर मुक्त लुकअप इंटरफेस प्रदान करण्यासाठी fzf वापरतात (जसे 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 नेमस्पेस बदलण्यासाठी.

मी असे दोन प्लगइन लिहिले आहेत:

• kubectl-ctx
• kubectl-ns

प्लगइनचे कार्य मागील विभागातील उपनामांवर आधारित आहे.

ते कसे कार्य करतात ते येथे आहे:

लक्षात ठेवा की प्लगइन परस्परसंवादी विनामूल्य शोध इंटरफेस प्रदान करण्यासाठी fzf वापरतात (जसे की kubectx च्या परस्परसंवादी मोड). याचा अर्थ तुम्हाला गरज आहे fzf स्थापित कराही उपनावे वापरण्यासाठी.

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

5. ऑटोअलियासेससह इनपुट कमी करा

इनपुट वेगवान करण्यासाठी शेल उपनाम हा एक चांगला मार्ग आहे. प्रकल्प kubectl-उपनाम मूलभूत kubectl कमांडसाठी सुमारे 800 शॉर्टकट आहेत.

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

उदाहरणार्थ:

1. kgpooyaml - kubectl get pods oyaml
2. ksysgsvcw — kubectl -n kube-system गेट svc w
3. ksysrmcm -kubectl -n kube-सिस्टम rm cm
4. kgdepalsl - 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_aliases GitHub वरून आणि फाइलमध्ये समाविष्ट करा ~/.bashrc किंवा ~/.zshrc:

source ~/.kubectl_aliases

स्वयंपूर्णता

आम्ही आधी म्हटल्याप्रमाणे, तुम्ही अनेकदा कमांड लाइनवरील उपनामामध्ये अतिरिक्त शब्द जोडता. उदाहरणार्थ:

$ kgpooyaml test-pod-d4b77b989

जर तुम्ही kubectl कमांड कम्प्लीशन वापरत असाल, तर तुम्ही कदाचित रिसोर्स नेम सारख्या गोष्टींसाठी स्वयंपूर्णता वापरली असेल. पण जेव्हा उपनावे वापरली जातात तेव्हा हे करता येते का?

हा एक अतिशय महत्त्वाचा प्रश्न आहे कारण जर स्वयंपूर्णता कार्य करत नसेल, तर तुम्ही उपनामांचे काही फायदे गमवाल.

तुम्ही कोणते शेल वापरत आहात यावर उत्तर अवलंबून आहे:

1. Zsh साठी, उर्फ ​​पूर्णता बॉक्सच्या बाहेर कार्य करते.
2. Bash साठी, दुर्दैवाने, कार्य करण्यासाठी स्वयंपूर्णता प्राप्त करण्यासाठी काही कार्य आवश्यक आहे.

बॅशमधील उपनामांसाठी स्वयंपूर्णता सक्षम करत आहे

बॅशची समस्या अशी आहे की ते उपनाव पूर्ण करण्याचा (प्रत्येक वेळी तुम्ही टॅब दाबता) प्रयत्न करते, उपनावाने संदर्भित केलेली आज्ञा नाही (उदाहरणार्थ, Zsh करते). तुमच्याकडे सर्व 800 उपनामांसाठी पूर्ण स्क्रिप्ट नसल्यामुळे, स्वयंपूर्णता कार्य करत नाही.

प्रकल्प पूर्ण-उर्फ या समस्येचे सामान्य समाधान प्रदान करते. हे उपनावांसाठी पूर्णत्व यंत्रणेशी जोडते, आतील उपनाम कमांडमध्ये विस्तृत करते आणि पूर्ण केलेल्या कमांडसाठी पूर्णता पर्याय परत करते. याचा अर्थ उपनामासाठी पॅडिंग पूर्ण आदेशाप्रमाणेच वागते.

खालील मध्ये, मी प्रथम पूर्ण-अलियास कसे स्थापित करायचे आणि नंतर सर्व kubectl उपनामांसाठी पूर्णत्व सक्षम करण्यासाठी ते कसे कॉन्फिगर करायचे ते स्पष्ट करेन.

पूर्ण उपनाम स्थापित करत आहे

सर्व प्रथम, पूर्ण-उर्फ अवलंबून असते bash-पूर्णता. म्हणून, पूर्ण उपनाम स्थापित करण्यापूर्वी, आपण bash-completion स्थापित केले आहे याची खात्री करणे आवश्यक आहे. लिनक्स आणि मॅकओएससाठी यापूर्वी इन्स्टॉलेशन सूचना प्रदान केल्या आहेत.

MacOS वापरकर्त्यांसाठी महत्त्वाची सूचना: kubectl autocompletion स्क्रिप्ट प्रमाणे, पूर्ण-अलियास Bash 3.2 सह कार्य करत नाही, जे MacOS वर डीफॉल्ट आहे. विशेषतः, पूर्ण उपनाम bash-completion v2 वर अवलंबून आहे (brew install bash-completion@2), ज्यासाठी किमान बॅश 4.1 आवश्यक आहे. याचा अर्थ MacOS वर पूर्ण उपनाम वापरण्यासाठी तुम्हाला Bash ची नवीन आवृत्ती स्थापित करणे आवश्यक आहे.

आपल्याला स्क्रिप्ट डाउनलोड करण्याची आवश्यकता आहे bash_completion.sh पासून GitHub भांडार आणि ते तुमच्या फाईलमध्ये समाविष्ट करा ~/.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 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 प्लगइन सामायिक करणे, शोधणे, स्थापित करणे आणि व्यवस्थापित करणे यासाठी एकत्रित समाधान प्रदान करण्याचे उद्दिष्ट आहे. प्रकल्प स्वतःला "क्यूबेक्टल प्लगइन्ससाठी पॅकेज व्यवस्थापक" म्हणतो (क्रू सारखे आहे ब्रू).

Krew ही kubectl प्लगइनची सूची आहे जी तुम्ही निवडू शकता आणि स्थापित करू शकता. त्याच वेळी, Krew देखील kubectl साठी प्लगइन आहे.

याचा अर्थ असा की Krew स्थापित करणे हे इतर कोणतेही kubectl प्लगइन स्थापित करण्यासारखे कार्य करते. येथे आपण तपशीलवार सूचना शोधू शकता GitHub पृष्ठ.

सर्वात महत्वाच्या Krew आदेश आहेत:

# Поиск в списке плагинов
$ 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 सारख्या इतरत्र प्लगइन शोधू शकता.

मी गिटहब विभाग पाहण्याची शिफारस करतो kubectl-plugins. तेथे तुम्हाला डझनभर उपलब्ध प्लगइन सापडतील जे तपासण्यासारखे आहेत.

आपले स्वतःचे प्लगइन लिहित आहे

आपण स्वत: करू शकता प्लगइन तयार करा - हे कठीण नाही. तुम्हाला एक एक्झिक्युटेबल तयार करणे आवश्यक आहे जे तुम्हाला जे हवे आहे ते करते, त्याला नाव द्या kubectl-x आणि वर वर्णन केल्याप्रमाणे स्थापित करा.

फाइल बॅश स्क्रिप्ट, पायथन स्क्रिप्ट किंवा संकलित GO ऍप्लिकेशन असू शकते - काही फरक पडत नाही. फक्त अट अशी आहे की ती थेट ऑपरेटिंग सिस्टममध्ये कार्यान्वित केली जाऊ शकते.

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

आपले प्लगइन कसे सामायिक करावे

तुमचे प्लगइन इतरांसाठी उपयुक्त ठरू शकतात असे तुम्हाला वाटत असल्यास, ते GitHub वर शेअर करण्यास मोकळ्या मनाने. त्यांना विषयात जोडण्याची खात्री करा kubectl-plugins.

आपण आपले प्लगइन जोडले जावे अशी विनंती देखील करू शकता क्रू यादी. हे कसे करावे यावरील सूचना मध्ये आहेत GitHub भांडार.

आदेश पूर्ण

प्लगइन सध्या स्वयंपूर्णतेला समर्थन देत नाहीत. म्हणजेच, तुम्ही प्लगइनचे पूर्ण नाव आणि युक्तिवादांची पूर्ण नावे प्रविष्ट करणे आवश्यक आहे.

या कार्यासाठी GitHub kubectl भांडार आहे खुली विनंती. त्यामुळे हे वैशिष्ट्य भविष्यात कधीतरी लागू केले जाण्याची शक्यता आहे.

शुभेच्छा!!!

विषयावर अजून काय वाचायचे:

1. कुबर्नेट्समधील ऑटोस्केलिंगचे तीन स्तर आणि ते प्रभावीपणे कसे वापरायचे.
2. अंमलबजावणीसाठी टेम्पलेटसह चाचेगिरीच्या भावनेत कुबर्नेट्स.
3. आमचे चॅनेल अराउंड कुबरनेटेस टेलीग्राममध्ये.

स्त्रोत: www.habr.com