कसरी kubectl थप प्रभावकारी रूपमा प्रयोग गर्ने: एक विस्तृत गाइड

यदि तपाइँ Kubernetes सँग काम गर्नुहुन्छ भने, तब kubectl तपाइँले धेरै प्रयोग गर्ने उपयोगिताहरू मध्ये एक हो। र जब तपाइँ एक विशेष उपकरणसँग काम गर्न धेरै समय खर्च गर्नुहुन्छ, यसले यसलाई राम्रोसँग अध्ययन गर्न र प्रभावकारी रूपमा कसरी प्रयोग गर्ने भनेर सिक्न भुक्तान गर्दछ।

टोली Kubernetes aaS Mail.ru बाट डेनियल Weibel द्वारा एउटा लेख अनुवाद गरियो जसमा तपाईंले kubectl सँग प्रभावकारी रूपमा काम गर्नका लागि सुझावहरू र चालहरू पाउनुहुनेछ। यसले तपाईंलाई Kubernetes को गहिरो समझ प्राप्त गर्न पनि मद्दत गर्नेछ।

लेखकका अनुसार, लेखको लक्ष्य Kubernetes सँग तपाईको दैनिक कार्यलाई अझ प्रभावकारी मात्र होइन, अझ रमाइलो बनाउनु हो!

परिचय: kubectl के हो

तपाईंले kubectl लाई अझ प्रभावकारी रूपमा प्रयोग गर्न सिक्नु अघि, तपाईंले यो के हो र यसले कसरी काम गर्छ भन्ने आधारभूत बुझाइ प्राप्त गर्न आवश्यक छ।

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

प्राविधिक रूपमा, kubectl एक Kubernetes API ग्राहक हो।

Kubernetes API एक HTTP REST API हो। यो API साँचो Kubernetes प्रयोगकर्ता इन्टरफेस हो, जसको माध्यमबाट यो पूर्ण रूपमा नियन्त्रण गरिन्छ। यसको मतलब प्रत्येक Kubernetes अपरेसन एपीआई एन्डपोइन्टको रूपमा उजागर गरिएको छ र त्यो अन्तिम बिन्दुमा HTTP अनुरोधको साथ गर्न सकिन्छ।

त्यसैले, kubectl को मुख्य काम Kubernetes API मा HTTP अनुरोधहरू बनाउनु हो:

Kubernetes एक पूर्ण संसाधन उन्मुख प्रणाली हो। यसको अर्थ यसले स्रोतहरूको आन्तरिक अवस्था कायम राख्छ र सबै Kubernetes सञ्चालनहरू CRUD सञ्चालनहरू हुन्।

तपाईं यी स्रोतहरू व्यवस्थापन गरेर Kubernetes को पूर्ण नियन्त्रणमा हुनुहुन्छ, र Kubernetes ले स्रोतहरूको हालको अवस्थाको आधारमा के गर्ने भन्ने कुरा पत्ता लगाउँछ। यस कारणले गर्दा, Kubernetes API सन्दर्भलाई तिनीहरूसँग सम्बन्धित कार्यहरूसँग स्रोत प्रकारहरूको सूचीको रूपमा व्यवस्थित गरिएको छ।

एउटा उदाहरण हेरौं.

मानौं तपाई प्रतिकृतिसेट स्रोत सिर्जना गर्न चाहनुहुन्छ। यो गर्नको लागि, तपाईंले नामद्वारा फाइलमा प्रतिकृति सेट वर्णन गर्नुहोस् replicaset.yaml, त्यसपछि आदेश चलाउनुहोस्:

$ kubectl create -f replicaset.yaml

यसले ReplicaSet स्रोत सिर्जना गर्नेछ। तर पर्दा पछाडि के हुन्छ?

Kubernetes सँग ReplicaSet निर्माण कार्य छ। कुनै पनि अन्य अपरेशन जस्तै, यो एक एपीआई अन्त बिन्दु को रूप मा उजागर गरिएको छ। यस अपरेसनको लागि विशिष्ट API अन्त्य बिन्दु यस्तो देखिन्छ:

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

सबै Kubernetes अपरेसनहरूको लागि API अन्त्य बिन्दुहरू फेला पार्न सकिन्छ API सन्दर्भ (सहित) माथिको अन्तिम बिन्दु)। अन्तिम बिन्दुमा वास्तविक अनुरोध गर्नको लागि, तपाईंले पहिले API सन्दर्भमा सूचीबद्ध अन्तिम बिन्दु मार्गहरूमा API सर्भर URL थप्नुपर्छ।

तसर्थ, जब तपाइँ माथिको आदेश कार्यान्वयन गर्नुहुन्छ, kubectl ले माथिको API अन्त्य बिन्दुमा HTTP POST अनुरोध पठाउँदछ। तपाईंले फाइलमा प्रदान गर्नुभएको ReplicaSet परिभाषा replicaset.yaml, अनुरोध को मुख्य भाग मा पठाइएको छ।

Kubernetes क्लस्टरसँग अन्तरक्रिया गर्ने सबै आदेशहरूको लागि kubectl यसरी काम गर्दछ। यी सबै केसहरूमा, kubectl ले उपयुक्त Kubernetes API अन्त्यबिन्दुहरूमा HTTP अनुरोधहरू मात्र गर्दछ।

कृपया ध्यान दिनुहोस् कि तपाइँ कुबेरनेटहरू पूर्ण रूपमा व्यवस्थापन गर्न सक्नुहुन्छ जस्तै उपयोगिता प्रयोग गरेर curlKubernetes API मा म्यानुअल रूपमा HTTP अनुरोधहरू पठाएर। Kubectl ले Kubernetes API प्रयोग गर्न सजिलो बनाउँछ।

यो kubectl के हो र यसले कसरी काम गर्छ भन्ने आधारभूत कुरा हो। तर त्यहाँ Kubernetes API को बारे मा केहि अन्य छ कि हरेक kubectl प्रयोगकर्ता थाहा हुनुपर्छ। Kubernetes को भित्री संसारमा एक द्रुत नजर राखौं।

Kubernetes को भित्री संसार

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

यहाँ मुख्य नोडहरूमा सबैभन्दा महत्त्वपूर्ण घटकहरू छन्:

1. रिपोजिटरी - भण्डारण स्रोत परिभाषा (सामान्यतया यो etcd हो).
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 परिभाषामा पोड टेम्प्लेट अनुसार) र तिनीहरूलाई भण्डारणमा भण्डारण गर्दछ।

नयाँ पोडहरूको सिर्जना एक शेड्युलरद्वारा ट्रिगर गरिएको छ जसले पोड परिभाषाहरूको ट्र्याक राख्छ जुन अझै कार्यकर्ता नोडहरूका लागि निर्धारित गरिएको छैन। अनुसूचकले प्रत्येक पोडको लागि उपयुक्त कार्यकर्ता नोड चयन गर्दछ र भण्डारमा पोड परिभाषाहरू अद्यावधिक गर्दछ।

नोट गर्नुहोस् कि यस बिन्दु सम्म, कुनै पनि कार्यभार कोड क्लस्टरमा कतै चलिरहेको थिएन। अहिलेसम्म भएका सबै कुरा - यो मास्टर नोडमा भण्डारमा स्रोतहरूको सिर्जना र अद्यावधिक हो।

अन्तिम घटनाले Kubelets ट्रिगर गर्दछ, जसले तिनीहरूको कार्यकर्ता नोडहरूको लागि निर्धारित पोडहरू निगरानी गर्दछ। कार्यकर्ता नोडको Kubelet जसमा तपाइँको ReplicaSet पोडहरू स्थापित छन् कन्टेनर रनटाइमलाई निर्देशन दिनुपर्छ, जस्तै डकर, आवश्यक कन्टेनर छविहरू डाउनलोड गर्न र तिनीहरूलाई चलाउन।

यस बिन्दुमा, तपाईंको ReplicaSet अनुप्रयोग अन्ततः चलिरहेको छ!

Kubernetes API को भूमिका

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

निस्सन्देह, यी कम्पोनेन्टहरूले भण्डारणसँग सीधै अन्तरक्रिया गर्दैनन्, तर Kubernetes API मार्फत मात्र।

निम्न उदाहरणहरू विचार गर्नुहोस्:

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

तपाईले देख्न सक्नुहुन्छ, यो उही API हो जुन kubectl पहुँच गर्दछ। आन्तरिक कम्पोनेन्टहरू र बाह्य प्रयोगकर्ताहरूका लागि समान API प्रयोग गर्नु Kubernetes डिजाइनमा आधारभूत अवधारणा हो।

अब हामी Kubernetes कसरी काम गर्छ संक्षेप गर्न सक्छौं:

1. भण्डारण भण्डारहरू राज्य, त्यो हो, Kubernetes स्रोतहरू।
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 ले आदेशहरूलाई पूरक बनाउन सक्छ।

अभ्यासमा, Bash (Linux र MacOS बीचको भिन्नता सहित) र Zsh को लागि जडान विधि फरक छ। तल हामी यी सबै विकल्पहरू हेर्नेछौं।

लिनक्समा ब्यास

Bash पूरा गर्ने स्क्रिप्ट 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-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 अद्यावधिक गर्दै"।

जारी राख्नु अघि, सुनिश्चित गर्नुहोस् कि तपाइँ Bash को भर्खरको संस्करण प्रयोग गर्दै हुनुहुन्छ (आउटपुट जाँच गर्नुहोस् bash --version).

Bash पूरा लिपि परियोजना अनुसार भिन्न हुन्छ bash-समापन, त्यसैले तपाईंले पहिले यसलाई स्थापना गर्न आवश्यक छ।

तपाईं प्रयोग गरेर bash-completion स्थापना गर्न सक्नुहुन्छ होमबाउ:

$ brew install bash-completion@2

यो छ @2 bash-completion संस्करण 2 को लागि खडा छ। kubectl स्वत: पूरा गर्न 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, र in ~/.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

यदि तपाईंले Homebrew प्रयोग गरेर bash-completion स्थापना गर्नुभयो भने मात्र यो विधिले काम गर्नेछ। यस अवस्थामा, bash-completion ले यस डाइरेक्टरीबाट सबै स्क्रिप्टहरू लोड गर्दछ।

यदि तपाइँ स्थापना गर्नुभयो Homebrew प्रयोग गरेर kubectl, त्यसोभए अघिल्लो चरण प्रदर्शन गर्न आवश्यक छैन, किनकि स्वत: पूर्णता लिपि स्वतः फोल्डरमा राखिनेछ। /usr/local/etc/bash_completion.d स्थापना को समयमा। यस अवस्थामा, kubectl autocompletion तपाईंले bash-completion स्थापना गर्ने बित्तिकै काम गर्न थाल्छ।

नतिजाको रूपमा, यी सबै विकल्पहरू बराबर छन्।

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]...

आदेशले अनुरोध गरिएको स्रोत वा क्षेत्रको विशिष्टता आउटपुट गर्नेछ। देखाइएको जानकारी एपीआई म्यानुअलमा समावेश भएकोसँग मिल्दोजुल्दो छ।

पूर्वनिर्धारित 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। यदि क्लस्टर सार्वजनिक क्लाउडमा चलिरहेको छ भने, यो लेबल स्वचालित रूपमा सिर्जना हुन्छ र प्रत्येक नोडको लागि उपलब्धता क्षेत्रहरूको नामले भरिन्छ।

   लेबलहरू Kubernetes संसाधन विशिष्टताको अंश होइनन्, त्यसैले तपाईंले तिनीहरूको बारेमा जानकारी पाउनुहुनेछैन API गाइड। यद्यपि, यदि तपाइँ 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 Hare क्लस्टरमा जडान हुनेछ।

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

अब kubectl फक्स क्लस्टरमा जडान हुनेछ।

एउटै क्लस्टरमा फरक नेमस्पेसमा स्विच गर्न, तपाईंले हालको सन्दर्भको लागि नेमस्पेस तत्वको मान परिवर्तन गर्न आवश्यक छ:

माथिको उदाहरणमा, kubectl ले फक्स क्लस्टरको प्रोड नेमस्पेस प्रयोग गर्नेछ (पहिले टेस्ट नेमस्पेस सेट गरिएको थियो)।

ध्यान दिनुहोस् कि 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 जस्तै कार्यक्षमता प्रदान गर्दछ। यहाँ तपाईंले तिनीहरूलाई कार्यमा देख्न सक्नुहुन्छ:

ध्यान दिनुहोस् कि उपनामहरूले एक अन्तरक्रियात्मक मुक्त लुकअप इन्टरफेस प्रदान गर्न 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. autoaliases को साथ इनपुट घटाउनुहोस्

शेल उपनामहरू इनपुट गति बढाउनको लागि राम्रो तरिका हो। परियोजना kubectl-उपनाम आधारभूत kubectl आदेशहरूको लागि लगभग 800 सर्टकटहरू समावेश गर्दछ।

तपाई सोचिरहनु भएको हुन सक्छ - तपाई 800 उपनाम कसरी सम्झनुहुन्छ? तर तपाईले ती सबै सम्झनु आवश्यक छैन, किनकि तिनीहरू एक साधारण योजना अनुसार बनाइएका छन्, जुन तल दिइएको छ:

उदाहरणका लागि:

1. kgpooyaml - kubectl प्राप्त pods oyaml
2. ksysgsvcw — kubectl -n kube-system svc w प्राप्त गर्नुहोस्
3. ksysrmcm -kubectl -n kube-सिस्टम rm सेमी
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_aliases GitHub बाट र फाइलमा समावेश गर्नुहोस् ~/.bashrc वा ~/.zshrc:

source ~/.kubectl_aliases

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

हामीले पहिले भनेझैं, तपाइँ प्राय: कमांड लाइनमा उपनाममा थप शब्दहरू थप्नुहुन्छ। उदाहरणका लागि:

$ kgpooyaml test-pod-d4b77b989

यदि तपाइँ kubectl आदेश समाप्ति प्रयोग गर्नुहुन्छ भने, तपाइँले सम्भवतः स्रोत नामहरू जस्तै चीजहरूको लागि स्वत: पूर्णता प्रयोग गर्नुभएको छ। तर उपनाम प्रयोग गर्दा यो गर्न सकिन्छ?

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

जवाफ तपाईले प्रयोग गरिरहनु भएको शेलमा निर्भर गर्दछ:

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

Bash मा उपनामहरूको लागि स्वत: पूर्णता सक्षम गर्दै

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

परियोजना पूर्ण उपनाम यस समस्याको सामान्य समाधान प्रदान गर्दछ। यसले उपनामका लागि पूर्णता संयन्त्रमा जडान गर्दछ, आन्तरिक रूपमा उपनामलाई आदेशमा विस्तार गर्दछ, र पूरा आदेशको लागि पूरा विकल्पहरू फर्काउँछ। यसको मतलब उपनामका लागि प्याडिङले पूर्ण आदेशको लागि जस्तै व्यवहार गर्छ।

निम्नमा, म पहिले कसरी पूर्ण-उपनाम स्थापना गर्ने र त्यसपछि सबै kubectl उपनामहरूको लागि पूर्णता सक्षम गर्न यसलाई कसरी कन्फिगर गर्ने भनेर वर्णन गर्नेछु।

पूर्ण उपनाम स्थापना गर्दै

सबै भन्दा पहिले, पूर्ण उपनाम मा निर्भर गर्दछ bash-समापन। तसर्थ, पूरा-उपनाम स्थापना गर्नु अघि, तपाईंले bash-completion स्थापित छ भनेर सुनिश्चित गर्न आवश्यक छ। स्थापना निर्देशनहरू लिनक्स र MacOS को लागि पहिले प्रदान गरिएको छ।

MacOS प्रयोगकर्ताहरूको लागि महत्त्वपूर्ण नोट: kubectl autocompletion स्क्रिप्ट जस्तै, पूर्ण उपनामले Bash 3.2 सँग काम गर्दैन, जुन MacOS मा पूर्वनिर्धारित हो। विशेष गरी, पूर्ण उपनाम bash-completion v2 मा निर्भर गर्दछ (brew install bash-completion@2), जसलाई कम्तिमा बास ४.१ चाहिन्छ। यसको मतलब यो हो कि 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

अघिल्लो उदाहरणमा जस्तै, जब तपाइँ 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 विस्तार गर्दै

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

यदि तपाइँ परिचित हुनुहुन्छ भने Git प्लगइन संयन्त्र, त्यसपछि kubectl प्लगइनहरू समान सिद्धान्तमा बनाइएका छन्।

यस अध्यायमा, हामी कसरी प्लगइनहरू स्थापना गर्ने, तिनीहरूलाई कहाँ फेला पार्ने, र तपाईंको आफ्नै प्लगइनहरू कसरी सिर्जना गर्ने भनेर कभर गर्नेछौं।

प्लगइनहरू स्थापना गर्दै

Kubectl प्लगइनहरू नाम जस्तै साधारण कार्यान्वयनयोग्य फाइलहरूको रूपमा वितरण गरिन्छ kubectl-x। उपसर्ग kubectl- आवश्यक छ, त्यसपछि नयाँ kubectl subcommand ले तपाईंलाई प्लगइन कल गर्न अनुमति दिन्छ।

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

प्लगइन स्थापना गर्न, तपाईंले फाइल प्रतिलिपि गर्न आवश्यक छ kubectl-x तपाईंको PATH मा कुनै पनि डाइरेक्टरीमा र यसलाई कार्यान्वयनयोग्य बनाउनुहोस्, उदाहरणका लागि chmod +x। यस पछि तुरुन्तै तपाईले प्लगइनलाई कल गर्न सक्नुहुन्छ kubectl x.

तपाइँ तपाइँको प्रणालीमा हाल स्थापित भएका सबै प्लगइनहरू सूचीबद्ध गर्न निम्न आदेश प्रयोग गर्न सक्नुहुन्छ:

$ kubectl plugin list

यदि तपाइँसँग एउटै नामको धेरै प्लगइनहरू छन् भने, वा यदि कार्यान्वयनयोग्य नभएको प्लगइन फाइल छ भने यो आदेशले चेतावनीहरू पनि प्रदर्शन गर्नेछ।

Krew प्रयोग गरेर प्लगइनहरू खोज्दै र स्थापना गर्दै

Kubectl प्लगइनहरू साझेदारी वा सफ्टवेयर प्याकेजहरू जस्तै पुन: प्रयोग गर्न सकिन्छ। तर तपाईले अरूले साझा गरेको प्लगइनहरू कहाँ फेला पार्न सक्नुहुन्छ?

परियोजना क्रु kubectl प्लगइनहरू साझेदारी, खोजी, स्थापना र प्रबन्धका लागि एकीकृत समाधान प्रदान गर्ने लक्ष्य राख्छ। परियोजनाले आफैलाई "kubectl प्लगइनहरूको लागि प्याकेज प्रबन्धक" (Krew सँग मिल्दोजुल्दो छ। Brew).

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 प्रयोग गरेर स्थापना गरिएका र अन्य विधिहरूद्वारा स्थापना गरिएका।

अन्यत्र प्लगइनहरू खोज्दै

Krew एक युवा परियोजना हो, हाल यसको मा सूची केवल लगभग 30 प्लगइनहरू। यदि तपाइँ तपाइँलाई चाहिने चीजहरू फेला पार्न सक्नुहुन्न भने, तपाइँ अन्यत्र प्लगइनहरू फेला पार्न सक्नुहुन्छ, जस्तै GitHub।

म GitHub सेक्सन हेर्न सिफारिस गर्दछु kubectl-plugins। त्यहाँ तपाईले दर्जनौं उपलब्ध प्लगइनहरू फेला पार्नुहुनेछ जुन जाँच गर्न लायक छन्।

तपाईंको आफ्नै प्लगइनहरू लेख्दै

तपाईं आफैले सक्नुहुन्छ प्लगइनहरू सिर्जना गर्नुहोस् - यो गाह्रो छैन। तपाईले एउटा कार्यान्वयन योग्य बनाउनु पर्छ जसले तपाईलाई के चाहिन्छ, यसलाई नाम दिनुहोस् kubectl-x र माथि वर्णन गरे अनुसार स्थापना गर्नुहोस्।

फाइल एक bash स्क्रिप्ट, एक python स्क्रिप्ट, वा एक संकलित 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 ग्राहक पुस्तकालय। यदि तपाइँ Go प्रयोग गर्दै हुनुहुन्छ भने, तपाइँ पनि प्रयोग गर्न सक्नुहुन्छ cli-रनटाइम पुस्तकालय, जुन kubectl प्लगइनहरू लेख्नको लागि विशेष रूपमा अवस्थित छ।

तपाईंको प्लगइनहरू कसरी साझेदारी गर्ने

यदि तपाईं आफ्नो प्लगइनहरू अरूको लागि उपयोगी हुन सक्छ भन्ने सोच्नुहुन्छ भने, यसलाई GitHub मा साझेदारी गर्न स्वतन्त्र महसुस गर्नुहोस्। तिनीहरूलाई शीर्षकमा थप्न निश्चित हुनुहोस् kubectl-plugins.

तपाईं आफ्नो प्लगइन थप्न अनुरोध गर्न सक्नुहुन्छ क्रु सूची। यो कसरी गर्ने भन्ने बारे निर्देशनहरू छन् GitHub भण्डारहरू.

आदेश पूरा

प्लगइनहरूले हाल स्वत: पूर्णतालाई समर्थन गर्दैन। त्यो हो, तपाईंले प्लगइनको पूरा नाम र तर्कहरूको पूरा नाम प्रविष्ट गर्नुपर्छ।

यस प्रकार्यको लागि GitHub kubectl भण्डार छ खुला अनुरोध। त्यसैले यो सुविधा भविष्यमा केही समय लागू हुने सम्भावना छ।

भाग्यले साथ दिओस्!!!

बिषयमा अरु के पढ्नु होला:

1. Kubernetes मा स्वत: स्केलिङ को तीन स्तर र कसरी प्रभावकारी रूपमा प्रयोग गर्ने.
2. कार्यान्वयनको लागि टेम्प्लेटको साथ पाइरेसीको भावनामा Kubernetes.
3. Telegram मा Kubernetes को आसपास हाम्रो च्यानल.

स्रोत: www.habr.com