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

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

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

आपके पास एक कार्यशील kubectl बाइनरी इंस्टॉल होना चाहिए।

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

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

आप Krew का उपयोग करके ओपन सोर्स में उपलब्ध kubectl प्लगइन्स को भी खोज और इंस्टॉल कर सकते हैं। Krew एक प्लगइन मैनेजर है जो कुबेरनेट्स SIG CLI कम्युनिटी द्वारा मेंटेन किया जाता है।

प्लगइन्स की खोज

kubectl एक कमांड kubectl plugin list प्रदान करता है जो आपके PATH में वैध प्लगइन एक्जीक्यूटेबल्स की खोज करता है। इस कमांड को एक्जीक्यूट करने से आपके PATH में सभी फाइलों का ट्रैवर्सल होता है। कोई भी फाइल जो एक्जीक्यूटेबल है और kubectl- से शुरू होती है, वह इस कमांड के आउटपुट में आपके PATH में मौजूद क्रम में दिखाई देगी। kubectl- से शुरू होने वाली किसी भी फाइल के लिए एक चेतावनी शामिल की जाएगी जो एक्जीक्यूटेबल नहीं है। ऐसी किसी भी वैध प्लगइन फाइल के लिए भी एक चेतावनी शामिल की जाएगी जो एक-दूसरे के नाम को ओवरलैप करती हैं।

आप Krew का उपयोग कम्युनिटी द्वारा क्यूरेट किए गए plugin index से kubectl प्लगइन्स को खोजने और इंस्टॉल करने के लिए कर सकते हैं।

प्लगइन्स बनाना

kubectl प्लगइन्स को PATH में kubectl-create-something बाइनरी प्रदान करके kubectl create something के आकार में कस्टम क्रिएट कमांड्स जोड़ने की अनुमति देता है।

सीमाएं

वर्तमान में मौजूदा kubectl कमांड्स को ओवरराइट करने या create के अलावा अन्य कमांड्स को विस्तारित करने वाले प्लगइन बनाना संभव नहीं है। उदाहरण के लिए, एक प्लगइन kubectl-version बनाने से वह प्लगइन कभी भी एक्जीक्यूट नहीं होगा, क्योंकि मौजूदा kubectl version कमांड हमेशा इसकी तुलना में प्राथमिकता लेगा। इस सीमा के कारण, मौजूदा kubectl कमांड्स में नए सबकमांड जोड़ने के लिए प्लगइन्स का उपयोग करना भी संभव नहीं है। उदाहरण के लिए, अपने प्लगइन का नाम kubectl-attach-vm रखकर एक सबकमांड kubectl attach vm जोड़ने से वह प्लगइन नजरअंदाज कर दिया जाएगा।

kubectl plugin list ऐसा करने का प्रयास करने वाले किसी भी वैध प्लगइन के लिए चेतावनियां दिखाता है।

kubectl प्लगइन्स लिखना

आप किसी भी प्रोग्रामिंग भाषा या स्क्रिप्ट में प्लगइन लिख सकते हैं जो आपको कमांड-लाइन कमांड्स लिखने की अनुमति देती है।

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

उदाहरण प्लगइन

#!/bin/bash

# वैकल्पिक आर्गुमेंट हैंडलिंग
if [[ "$1" == "version" ]]
then
    echo "1.0.0"
    exit 0
fi

# वैकल्पिक आर्गुमेंट हैंडलिंग
if [[ "$1" == "config" ]]
then
    echo "$KUBECONFIG"
    exit 0
fi

echo "मैं kubectl-foo नाम का एक प्लगइन हूं"

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

प्लगइन का उपयोग करने के लिए, प्लगइन को एक्जीक्यूटेबल बनाएं:

sudo chmod +x ./kubectl-foo

और इसे अपने PATH में कहीं भी रखें:

sudo mv ./kubectl-foo /usr/local/bin

अब आप अपने प्लगइन को एक kubectl कमांड के रूप में इनवोक कर सकते हैं:

kubectl foo

मैं kubectl-foo नाम का एक प्लगइन हूं

सभी आर्ग्स और फ्लैग्स जैसे के तैसे एक्जीक्यूटेबल को पास किए जाते हैं:

kubectl foo version

1.0.0

सभी एनवायरनमेंट वेरिएबल्स भी जैसे के तैसे एक्जीक्यूटेबल को पास किए जाते हैं:

export KUBECONFIG=~/.kube/config
kubectl foo config

/home/<user>/.kube/config

KUBECONFIG=/etc/kube/config kubectl foo config

/etc/kube/config

इसके अतिरिक्त, प्लगइन को पास किया जाने वाला पहला आर्गुमेंट हमेशा उस स्थान का पूर्ण पाथ होगा जहां से इसे इनवोक किया गया था (ऊपर के उदाहरण में $0 /usr/local/bin/kubectl-foo के बराबर होगा)।

प्लगइन का नामकरण

जैसा कि ऊपर के उदाहरण में देखा गया है, एक प्लगइन अपने फाइलनेम के आधार पर तय करता है कि वह किस कमांड पाथ को लागू करेगा। कमांड पाथ में प्रत्येक सब-कमांड को डैश (-) से अलग किया जाता है। उदाहरण के लिए, एक प्लगइन जो यूजर द्वारा kubectl foo bar baz कमांड इनवोक किए जाने पर चलाया जाना चाहता है, उसका फाइलनेम kubectl-foo-bar-baz होगा।

फ्लैग्स और आर्गुमेंट हैंडलिंग

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

यहाँ कुछ अतिरिक्त मामले हैं जहाँ यूजर्स अतिरिक्त फ्लैग्स और आर्गुमेंट्स प्रदान करते हुए आपके प्लगइन को इनवोक करते हैं। यह ऊपर के परिदृश्य से kubectl-foo-bar-baz प्लगइन पर आधारित है।

यदि आप kubectl foo bar baz arg1 --flag=value arg2 चलाते हैं, तो kubectl का प्लगइन मैकेनिज्म पहले सबसे लंबे संभावित नाम वाले प्लगइन को खोजने का प्रयास करेगा, जो इस मामले में kubectl-foo-bar-baz-arg1 होगा। उस प्लगइन को न पाने पर, kubectl फिर अंतिम डैश-सेपरेटेड वैल्यू को एक आर्गुमेंट के रूप में मानता है (इस मामले में arg1), और अगले सबसे लंबे संभावित नाम को खोजने का प्रयास करता है, kubectl-foo-bar-baz। इस नाम वाले प्लगइन को पाने पर, kubectl फिर उस प्लगइन को इनवोक करता है, प्लगइन के नाम के बाद के सभी आर्ग्स और फ्लैग्स को प्लगइन प्रोसेस को आर्गुमेंट के रूप में पास करता है।

उदाहरण:

# create a plugin
echo -e '#!/bin/bash\n\necho "My first command-line argument was $1"' > kubectl-foo-bar-baz
sudo chmod +x ./kubectl-foo-bar-baz

# "install" your plugin by moving it to a directory in your $PATH
sudo mv ./kubectl-foo-bar-baz /usr/local/bin

# check that kubectl recognizes your plugin
kubectl plugin list

निम्नलिखित kubectl-कम्पैटिबल प्लगइन्स उपलब्ध हैं:

/usr/local/bin/kubectl-foo-bar-baz

# test that calling your plugin via a "kubectl" command works
# even when additional arguments and flags are passed to your
# plugin executable by the user.
kubectl foo bar baz arg1 --meaningless-flag=true

मेरा पहला कमांड-लाइन आर्गुमेंट था arg1

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

डैश और अंडरस्कोर वाले नाम

हालांकि kubectl प्लगइन मैकेनिज्म प्लगइन फाइलनेम में डैश (-) का उपयोग प्लगइन द्वारा प्रोसेस किए जाने वाले सब-कमांड्स के क्रम को अलग करने के लिए करता है, फिर भी अंडरस्कोर (_) का उपयोग करके अपने फाइलनेम में डैश वाले कमांडलाइन इनवोकेशन वाला प्लगइन बनाना संभव है।

उदाहरण:

# create a plugin containing an underscore in its filename
echo -e '#!/bin/bash\n\necho "I am a plugin with a dash in my name"' > ./kubectl-foo_bar
sudo chmod +x ./kubectl-foo_bar

# move the plugin into your $PATH
sudo mv ./kubectl-foo_bar /usr/local/bin

# You can now invoke your plugin via kubectl:
kubectl foo-bar

मैं अपने नाम में डैश वाला एक प्लगइन हूं

ध्यान दें कि प्लगइन फाइलनेम में अंडरस्कोर का प्रयोग आपको kubectl foo_bar जैसे कमांड्स से नहीं रोकता है। ऊपर के उदाहरण का कमांड, डैश (-) या अंडरस्कोर (_) दोनों का उपयोग करके इनवोक किया जा सकता है:

# You can invoke your custom command with a dash
kubectl foo-bar

मैं अपने नाम में डैश वाला एक प्लगइन हूं

# You can also invoke your custom command with an underscore
kubectl foo_bar

मैं अपने नाम में डैश वाला एक प्लगइन हूं

नाम विवाद और ओवरशैडोइंग

आपके PATH में विभिन्न स्थानों पर एक ही फाइलनेम वाले कई प्लगइन होना संभव है। उदाहरण के लिए, निम्नलिखित मान वाले PATH के लिए: PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins, प्लगइन kubectl-foo की एक कॉपी /usr/local/bin/plugins और /usr/local/bin/moreplugins में मौजूद हो सकती है, ताकि kubectl plugin list कमांड का आउटपुट हो:

PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins kubectl plugin list

The following kubectl-compatible plugins are available:

/usr/local/bin/plugins/kubectl-foo
/usr/local/bin/moreplugins/kubectl-foo
  - warning: /usr/local/bin/moreplugins/kubectl-foo is overshadowed by a similarly named plugin: /usr/local/bin/plugins/kubectl-foo

error: one plugin warning was found

उपरोक्त परिदृश्य में, /usr/local/bin/moreplugins/kubectl-foo के नीचे की चेतावनी आपको बताती है कि यह प्लगइन कभी भी एक्जीक्यूट नहीं किया जाएगा। इसके बजाय, आपके PATH में पहले दिखाई देने वाला एक्जीक्यूटेबल, /usr/local/bin/plugins/kubectl-foo, हमेशा kubectl प्लगइन मैकेनिज्म द्वारा पहले पाया और एक्जीक्यूट किया जाएगा।

इस समस्या को हल करने का एक तरीका यह सुनिश्चित करना है कि जिस प्लगइन का उपयोग आप kubectl के साथ करना चाहते हैं, वह हमेशा आपके PATH में पहले आए। उदाहरण के लिए, यदि आप हमेशा /usr/local/bin/moreplugins/kubectl-foo का उपयोग करना चाहते हैं जब भी kubectl कमांड kubectl foo इनवोक किया जाता है, तो अपने PATH का मान /usr/local/bin/moreplugins:/usr/local/bin/plugins में बदलें।

सबसे लंबे एक्जीक्यूटेबल फाइलनेम का इनवोकेशन

प्लगइन फाइलनेम के साथ एक और प्रकार का ओवरशैडोइंग हो सकता है। यूजर के PATH में मौजूद दो प्लगइन्स के लिए: kubectl-foo-bar और kubectl-foo-bar-baz, kubectl प्लगइन मैकेनिज्म हमेशा दिए गए यूजर कमांड के लिए सबसे लंबा संभव प्लगइन नाम चुनेगा। नीचे दिए गए कुछ उदाहरण इसे और स्पष्ट करते हैं:

# एक दिए गए kubectl कमांड के लिए, सबसे लंबे संभव फाइलनेम वाले प्लगइन को हमेशा प्राथमिकता दी जाएगी
kubectl foo bar baz

प्लगइन kubectl-foo-bar-baz एक्जीक्यूट किया गया

kubectl foo bar

प्लगइन kubectl-foo-bar एक्जीक्यूट किया गया

kubectl foo bar baz buz

प्लगइन kubectl-foo-bar-baz एक्जीक्यूट किया गया, "buz" को इसके पहले आर्गुमेंट के रूप में

kubectl foo bar buz

प्लगइन kubectl-foo-bar एक्जीक्यूट किया गया, "buz" को इसके पहले आर्गुमेंट के रूप में

यह डिजाइन चॉइस सुनिश्चित करता है कि प्लगइन सब-कमांड्स को, यदि आवश्यक हो, कई फाइलों में लागू किया जा सकता है, और इन सब-कमांड्स को एक "पैरेंट" प्लगइन कमांड के नीचे नेस्टेड किया जा सकता है:

ls ./plugin_command_tree

kubectl-parent
kubectl-parent-subcommand
kubectl-parent-subcommand-subsubcommand

प्लगइन चेतावनियों की जांच

आप पूर्वोक्त kubectl plugin list कमांड का उपयोग यह सुनिश्चित करने के लिए कर सकते हैं कि आपका प्लगइन kubectl द्वारा दिखाई दे रहा है, और सत्यापित करें कि कोई चेतावनियां नहीं हैं जो इसे एक kubectl कमांड के रूप में कॉल किए जाने से रोक रही हैं।

kubectl plugin list

निम्नलिखित kubectl-कम्पैटिबल प्लगइन्स उपलब्ध हैं:

test/fixtures/pkg/kubectl/plugins/kubectl-foo
/usr/local/bin/kubectl-foo
  - चेतावनी: /usr/local/bin/kubectl-foo एक समान नाम वाले प्लगइन द्वारा ओवरशैडो किया गया है: test/fixtures/pkg/kubectl/plugins/kubectl-foo
plugins/kubectl-invalid
  - चेतावनी: plugins/kubectl-invalid एक kubectl प्लगइन के रूप में पहचाना गया, लेकिन यह एक्जीक्यूटेबल नहीं है

त्रुटि: 2 प्लगइन चेतावनियां पाई गईं

कमांड लाइन रनटाइम पैकेज का उपयोग करना

यदि आप kubectl के लिए एक प्लगइन लिख रहे हैं और आप Go का उपयोग कर रहे हैं, तो आप cli-runtime यूटिलिटी लाइब्रेरीज का उपयोग कर सकते हैं।

ये लाइब्रेरीज यूजर की kubeconfig फाइल को पार्स या अपडेट करने, API सर्वर को REST-स्टाइल रिक्वेस्ट भेजने, या कॉन्फ़िगरेशन और प्रिंटिंग से जुड़े फ्लैग्स को बाइंड करने के लिए हेल्पर्स प्रदान करती हैं।

CLI Runtime रेपो में प्रदान किए गए टूल्स के उपयोग के उदाहरण के लिए Sample CLI Plugin देखें।

kubectl प्लगइन्स का वितरण

यदि आपने दूसरों के उपयोग के लिए एक प्लगइन विकसित किया है, तो आपको इसे कैसे पैकेज करें, वितरित करें और अपने उपयोगकर्ताओं को अपडेट प्रदान करें, इस पर विचार करना चाहिए।

Krew

Krew आपके प्लगइन्स को पैकेज और वितरित करने का एक क्रॉस-प्लेटफ़ॉर्म तरीका प्रदान करता है। इस तरह, आप सभी लक्षित प्लेटफ़ॉर्म (Linux, Windows, macOS आदि) के लिए एक ही पैकेजिंग फॉर्मेट का उपयोग करते हैं और अपने उपयोगकर्ताओं को अपडेट प्रदान करते हैं। Krew एक प्लगइन इंडेक्स भी बनाए रखता है ताकि अन्य लोग आपके प्लगइन को खोज और इंस्टॉल कर सकें।

नेटिव / प्लेटफ़ॉर्म विशिष्ट पैकेज प्रबंधन

वैकल्पिक रूप से, आप पारंपरिक पैकेज मैनेजर्स जैसे Linux पर apt या yum, Windows पर Chocolatey, और macOS पर Homebrew का उपयोग कर सकते हैं। कोई भी पैकेज मैनेजर उपयुक्त होगा यदि वह नई एक्जीक्यूटेबल्स को यूजर के PATH में कहीं भी रख सकता है। एक प्लगइन लेखक के रूप में, यदि आप यह विकल्प चुनते हैं तो आप पर प्रत्येक रिलीज के लिए कई प्लेटफ़ॉर्म पर अपने kubectl प्लगइन के वितरण पैकेज को अपडेट करने का भार भी होता है।

सोर्स कोड

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

आगे क्या है

• Go में लिखे गए प्लगइन के एक विस्तृत उदाहरण के लिए Sample CLI Plugin रिपॉजिटरी देखें। किसी भी प्रश्न के मामले में, SIG CLI टीम से संपर्क करने में संकोच न करें।
• kubectl प्लगइन्स के लिए एक पैकेज मैनेजर, Krew के बारे में पढ़ें।