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

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

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

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

प्रस्तावना: क्यूबेक्टल म्हणजे काय?

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

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

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

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

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

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

या संसाधनांचे व्यवस्थापन करून तुमचे कुबर्नेट्सवर पूर्ण नियंत्रण असते आणि कुबर्नेट्स संसाधनांच्या सध्याच्या स्थितीनुसार काय करायचे ते ठरवते. या कारणास्तव, कुबर्नेट्स API हे संसाधन प्रकार आणि त्यांच्याशी संबंधित ऑपरेशन्सची यादी म्हणून आयोजित केले आहे.

चला एक उदाहरण पाहू..

समजा तुम्हाला एक ReplicaSet संसाधन तयार करायचे आहे. हे करण्यासाठी, तुम्ही ReplicaSet चे वर्णन एका फाईलमध्ये करता ज्याचे नाव आहे replicaset.yaml, नंतर कमांड चालवा:

$ kubectl create -f replicaset.yaml

हे एक ReplicaSet संसाधन तयार करेल. पण पडद्यामागे काय चालले आहे?

कुबर्नेट्समध्ये रेप्लिकासेट क्रिएशन ऑपरेशन आहे. इतर कोणत्याही ऑपरेशनप्रमाणे, ते API एंडपॉइंट म्हणून उघड केले जाते. या ऑपरेशनसाठी विशिष्ट API एंडपॉइंट असे दिसते:

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

सर्व कुबर्नेट्स ऑपरेशन्ससाठी API एंडपॉइंट्स येथे आढळू शकतात API संदर्भ (यासह वरील शेवटचा बिंदू). एंडपॉइंटला प्रत्यक्ष विनंती करण्यासाठी, तुम्हाला प्रथम API सर्व्हर URL API संदर्भामध्ये सूचीबद्ध केलेल्या एंडपॉइंट पथांमध्ये जोडणे आवश्यक आहे.

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

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

कृपया लक्षात ठेवा की तुम्ही कुबर्नेट्स पूर्णपणे व्यवस्थापित करू शकता जसे की curl, कुबर्नेट्स एपीआयला मॅन्युअली HTTP विनंत्या पाठवत आहे. कुबेक्टल कुबर्नेट्स एपीआयचा वापर सुलभ करते.

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

कुबर्नेट्सचे आतील जग

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

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

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

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

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

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

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

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

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

   

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

   

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

   

4. शेड्युलर सुरू होतो, पॉड्सचे निरीक्षण करतो जे अद्याप कोणत्याही वर्कर नोडला नियुक्त केलेले नाहीत:

   

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

   

6. ज्या वर्कर नोडला पॉड नियुक्त केला आहे, त्यावर कुबलेट लाँच केले जाते आणि त्या नोडला नियुक्त केलेल्या पॉड्सचे निरीक्षण करते:

   

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

   

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

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

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

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

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

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

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

या टप्प्यावर, तुमचा ReplicaSet अॅप्लिकेशन अखेर चालू होत आहे!

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

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

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

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

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

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

आता आपण कुबर्नेट्स कसे कार्य करते ते थोडक्यात सांगू शकतो:

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

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

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

१. कमांड पूर्ण करून टायपिंगचा वेग वाढवा

क्युबेक्टल उत्पादकता सुधारण्यासाठी सर्वात उपयुक्त, तरीही अनेकदा दुर्लक्षित केलेल्या तंत्रांपैकी एक म्हणजे कमांड पूर्ण करणे.

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

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

कमांड कम्प्लीशन बॅश आणि झेडएसएच शेल्ससाठी काम करते.

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

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

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

कुबेक्टल खालील कमांड वापरून बॅश आणि झेडएसएचसाठी कम्प्लीशन स्क्रिप्ट्स स्वयंचलितपणे तयार करते आणि आउटपुट करते:

$ kubectl completion bash

किंवा:

$ kubectl completion zsh

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

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

मारा Linux

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

$ sudo apt-get install bash-completion

किंवा:

$ yum install bash-completion

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

$ type _init_completion

जर हे शेल फंक्शन कोड आउटपुट करत असेल, तर bash-completion योग्यरित्या स्थापित केले आहे. जर कमांड "Not found" एरर परत करत असेल, तर तुम्हाला तुमच्या फाईलमध्ये खालील ओळ जोडावी लागेल. ~ / .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 बॅश-कंप्लीशनमध्ये आपोआप समाविष्ट केले जातात.

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

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

MacOS वर बॅश करा

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

MacOS वर Bash च्या जुन्या आवृत्तीचा वापर परवाना समस्यांमुळे होत आहे. Bash आवृत्ती ४ ही GPLv3 अंतर्गत परवानाकृत आहे, ज्याला Apple समर्थन देत नाही.

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

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

बॅश ऑटोकंप्लीशन स्क्रिप्ट प्रोजेक्ट-विशिष्ट आहे. bash-पूर्णता, म्हणून तुम्हाला ते प्रथम स्थापित करावे लागेल.

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

$ brew install bash-completion@2

तो आहे @2 म्हणजे बॅश-कंप्लीशन व्हर्जन २. kubectl कम्प्लीशनसाठी बॅश-कंप्लीशन v2 आवश्यक आहे आणि बॅश-कंप्लीशन v2 ला कमीत कमी बॅश व्हर्जन ४.१ आवश्यक आहे.

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

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

जर तुम्ही स्थापित केले असेल तर होमब्रू वापरून 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

२. संसाधन तपशील द्रुतपणे पहा

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

३. कस्टम कॉलम आउटपुट फॉरमॅट वापरा

डीफॉल्ट कमांड आउटपुट फॉरमॅट आहे 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.

कृपया लक्षात घ्या की कुबर्नेट्स रिसोर्स फील्ड केस-सेन्सेटिव्ह आहेत.

तुम्ही कोणतेही संसाधन फील्ड कॉलम म्हणून पाहू शकता. फक्त संसाधन तपशीलांचे पुनरावलोकन करा आणि तुम्हाला आवडणाऱ्या कोणत्याही फील्डसह ते वापरून पहा.

पण प्रथम, फील्ड सिलेक्शन एक्सप्रेशन्स जवळून पाहू.

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'

[] ऑपरेटर विशेषतः महत्त्वाचा आहे. अनेक कुबर्नेट्स रिसोर्स फील्ड ही यादी असतात आणि हा ऑपरेटर तुम्हाला त्या यादींमधून घटक निवडण्याची परवानगी देतो. सूचीतील सर्व घटक निवडण्यासाठी [*] सारख्या वाइल्डकार्ड वर्णासह याचा वापर केला जातो.

अनुप्रयोग उदाहरणे

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

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

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

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

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

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

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

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

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

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

क्यूबकॉन्फिग फाइल्स

चला kubeconfig फाइलमध्ये नेमके काय आहे ते पाहूया:

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

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

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

कोणत्याही वेळी, संदर्भांपैकी एक चालू असतो:

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

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

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

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

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

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

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

क्युबेक्टएक्स वापरा

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

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

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

या कमांड कार्यान्वित करण्याचे एक उदाहरण येथे आहे:

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

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

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

आणखी एक उपयुक्त वैशिष्ट्य 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 सारखी कार्यक्षमता प्रदान करतो. तुम्ही ते येथे कृतीत पाहू शकता:

लक्षात ठेवा की उपनाम 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 नेमस्पेस बदलण्यासाठी.

मी हे करणारे दोन प्लगइन लिहिले:

• क्यूबेक्टएल-सीटीएक्स
• क्यूबेक्टल-एनएस

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

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

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

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

५. ऑटोअॅलिअसेस वापरून इनपुट लहान करा

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

तुम्हाला कदाचित ८०० उपनाम कसे लक्षात ठेवायचे असा प्रश्न पडत असेल. पण तुम्हाला ते सर्व लक्षात ठेवण्याची गरज नाही, कारण ते खाली दाखवल्याप्रमाणे एका साध्या सूत्राचे अनुसरण करतात:

उदाहरणार्थ:

1. kgpooyaml - kubectl ला शेंगा मिळवा oyaml
2. ksysgsvcw — kubectl -n kube-system गेट svc w
3. ksysrmcm -kubectl -n kube-सिस्टम rm cm
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 स्थापित करण्यासाठी, तुम्हाला फाइल डाउनलोड करावी लागेल .कुबेक्टल_उपनाम GitHub वरून घ्या आणि ते फाइलमध्ये समाविष्ट करा ~/.bashrc किंवा ~/.zshrc:

source ~/.kubectl_aliases

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

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

$ kgpooyaml test-pod-d4b77b989

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

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

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

1. Zsh साठी, उपनामांसाठी ऑटोकंप्लीशन बॉक्सच्या बाहेर काम करते.
2. दुर्दैवाने, ऑटोकंप्लीशन कार्य करण्यासाठी बॅशला काही काम करावे लागते.

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

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

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

पुढे, मी प्रथम complete-alias कसे स्थापित करायचे ते स्पष्ट करेन आणि नंतर सर्व kubectl aliases साठी completion सक्षम करण्यासाठी ते कसे कॉन्फिगर करायचे ते सांगेन.

पूर्ण-उर्फ स्थापित करणे

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

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

तुम्हाला स्क्रिप्ट डाउनलोड करावी लागेल. बॅश_कंप्लीशन.श पासून गिटहब रिपॉझिटरी आणि ते तुमच्या फाईलमध्ये समाविष्ट करा. ~/.bashrc:

source ~/bash_completion.sh

शेल रीस्टार्ट केल्यानंतर, पूर्ण-उपनाम पूर्णपणे स्थापित होईल.

kubectl उपनामांसाठी स्वयंपूर्णता सक्षम करणे

तांत्रिकदृष्ट्या, पूर्ण-उर्फ एक शेल फंक्शन प्रदान करते _complete_aliasहे फंक्शन उपनाम तपासते आणि उपनाम कमांडसाठी पूर्णत्वाचे संकेत देते.

एखाद्या विशिष्ट उपनामाशी फंक्शन जोडण्यासाठी, तुम्हाला बॅश बिल्ट-इन मेकॅनिझम वापरावे लागेल. पूर्णस्थापित करणे _complete_alias उपनाव पूरकाचे कार्य म्हणून.

उदाहरण म्हणून, चला 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-उपनामांना ~/.kubectl-aliases:

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

हा कोड तुमच्या मध्ये ठेवला पाहिजे ~/.bashrc, कमांड शेल रीस्टार्ट करा, आणि सर्व ८०० kubectl उपनामांसाठी ऑटोकंप्लीशन उपलब्ध होईल.

६. प्लगइन्ससह kubectl वाढवणे

पासून प्रारंभ आवृत्ती 1.12, kubectl सपोर्ट करते प्लगइन यंत्रणा, जे तुम्हाला अतिरिक्त आदेशांसह त्याची कार्यक्षमता वाढविण्यास अनुमती देते.

जर तुम्हाला माहिती असेल तर गिट प्लगइन यंत्रणा, तर kubectl प्लगइन्स त्याच तत्त्वावर तयार केले जातात.

या प्रकरणात, आपण प्लगइन्स कसे स्थापित करायचे, ते कुठे शोधायचे आणि तुमचे स्वतःचे प्लगइन्स कसे तयार करायचे ते पाहू.

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

कुबेक्टल प्लगइन्स अशा नावाच्या साध्या एक्झिक्युटेबल फाइल्स म्हणून वितरित केल्या जातात kubectl-x. उपसर्ग kubectl- आवश्यक आहे, त्यानंतर एक नवीन kubectl सबकमांड येतो जो तुम्हाला प्लगइन कॉल करण्याची परवानगी देतो.

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

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

तुमच्या सिस्टमवर सध्या स्थापित असलेल्या सर्व प्लगइन्सची यादी करण्यासाठी तुम्ही खालील कमांड वापरू शकता:

$ kubectl plugin list

जर तुमच्याकडे एकाच नावाचे अनेक प्लगइन असतील किंवा तुमच्याकडे एक्झिक्युटेबल नसलेली प्लगइन फाइल असेल तर ही कमांड चेतावणी देखील दाखवते.

क्रू वापरून प्लगइन्स शोधणे आणि स्थापित करणे

सॉफ्टवेअर पॅकेजेसप्रमाणेच कुबेक्टल प्लगइन्स शेअर करणे आणि पुन्हा वापरणे सोपे आहे. पण इतरांनी शेअर केलेले प्लगइन्स तुम्हाला कुठे मिळतील?

प्रोजेक्ट क्रू 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 फक्त तेच प्लगइन्स दाखवते जे Krew वापरून इंस्टॉल केले होते, तर कमांड kubectl plugin list सर्व प्लगइन्सची यादी करते, जे क्रू वापरून स्थापित केले जातात आणि जे इतर मार्गांनी स्थापित केले जातात.

इतर ठिकाणी प्लगइन शोधा

क्रू हा एक तरुण प्रकल्प आहे, सध्या त्याच्या यादी एकूण सुमारे ३० प्लगइन्स आहेत. जर तुम्हाला हवे असलेले प्लगइन्स सापडले नाहीत, तर तुम्ही इतरत्र, जसे की GitHub वर, प्लगइन्स शोधू शकता.

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

तुमचे स्वतःचे प्लगइन्स लिहिणे

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

तुमचे प्लगइन्स कसे शेअर करायचे

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

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

आदेश पूर्ण

प्लगइन सध्या ऑटोकंप्लीशनला सपोर्ट करत नाहीत. याचा अर्थ तुम्हाला पूर्ण प्लगइन नाव आणि वितर्क नावे एंटर करावी लागतील.

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

शुभेच्छा!!!

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

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

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