Cum să folosești mai eficient kubectl: un ghid detaliat

Să vedem un exemplu simplu:

$ kubectl get pods -o custom-columns='NAME:metadata.name'

NAME
engine-544b6b6467-22qr6
engine-544b6b6467-lw5t8
engine-544b6b6467-tvgmg
web-ui-6db964458-8pdw4

Ieșirea conține o coloană cu numele podurilor.

Expresia din opțiune selectează numele podurilor din câmpul metadata.name. Acest lucru se datorează faptului că numele podului este definit în câmpul fiu name al câmpului metadata din descrierea resursei podului. Poți găsi mai multe detalii în manualul API sau introduci comanda kubectl explain pod.metadata.name.

Acum să presupunem că doriți să adăugați o coloană suplimentară la ieșire, de exemplu, arătând nodul pe care rulează fiecare pod. Pentru aceasta, puteți adăuga pur și simplu specificația corespunzătoare a coloanei în opțiunea coloanelor personalizate:

$ 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

Expresia selectează numele nodului din spec.nodeName — atunci când podul este alocat unui nod, numele său este scris în câmpul spec.nodeName specificației resurselor podului. Informații mai detaliate pot fi văzute în ieșirea kubectl explain pod.spec.nodeName.

Rețineți că câmpurile resurselor Kubernetes sunt sensibil la majuscule.

Puteți vizualiza orice câmp de resursă sub formă de coloană. Pur și simplu revizuiți specificația resursei și încercați-o cu orice câmpuri doriți.

Dar mai întâi, să analizăm mai atent expresiile de selecție a câmpurilor.

Expresiile JSONPath

Expresiile pentru selectarea câmpurilor resurselor se bazează pe JSONPath.

JSONPath este un limbaj pentru extragerea datelor din documente JSON. Selectarea unui câmp este cel mai simplu caz de utilizare a JSONPath. Acesta are mult mai multe posibilități, inclusiv selecții, filtre și așa mai departe.

Kubectl explain susține un număr limitat de funcționalități JSONPath. Mai jos sunt descrise funcționalitățile și exemplele de utilizare:

# Выбрать все элементы списка
$ 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'

Operatorul [] are o semnificație specială. Multe câmpuri de resurse Kubernetes sunt liste, iar acest operator permite selectarea elementelor din aceste liste. Este adesea folosit cu un wildcard ca [*], pentru a selecta toate elementele din listă.

Exemple de aplicare

Posibilitățile de utilizare a formatului personalizat de ieșire a coloanelor sunt nelimitate, deoarece puteți afisa orice câmp sau combinație de câmpuri de resurse în ieșire. Iată câteva exemple de aplicații, dar nu ezitați să le explorați singuri și să găsiți aplicații utile pentru dvs.

1. Afișarea imaginilor containerelor pentru poduri:

   $ 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

   Această comandă afișează numele imaginilor containerelor pentru fiecare pod.

   Rețineți că sub poate conține mai multe containere, iar numele imaginilor vor fi listate într-un singur rând, separate prin virgule.

2. Afișarea zonelor de disponibilitate ale nodurilor:

   $ 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

   Această comandă este convenabilă dacă clusterul dvs. este găzduit într-un nor public. Aceasta afișează zona de disponibilitate pentru fiecare nod.

   Zona de disponibilitate este un concept în cloud care restricționează zona de replicare la o regiune geografică.

   Zonele de disponibilitate pentru fiecare nod sunt obținute printr-o etichetă specială — failure-domain.beta.kubernetes.io/zone. Dacă clusterul este lansat într-un nor public, această etichetă este creată automat și umplută cu numele zonelor de disponibilitate pentru fiecare nod.

   Etichetele nu sunt parte a specificației resurselor Kubernetes, astfel încât nu veți găsi informații despre ele în manualul API. Cu toate acestea, le puteți vedea (ca și orice alte etichete), dacă solicitați informații despre noduri în format YAML sau JSON:

   $ kubectl get nodes -o yaml
   # sau
   $ kubectl get nodes -o json

   Acesta este un mod excelent de a învăța mai multe despre resurse, în plus față de studierea specificațiilor resurselor.

4. Comutare ușoară între clustere și spații de nume

Când kubectl trimite o cerere către API-ul Kubernetes, acesta citește fișierul kubeconfig pentru a obține toate parametrii necesari pentru conectare.

În mod implicit, fișierul kubeconfig este ~/.kube/config. De obicei, acest fișier este creat sau actualizat printr-o comandă specială.

Când lucrați cu mai multe clustere, fișierul dvs. kubeconfig conține parametri de conectare pentru toate aceste clustere. Aveți nevoie de un mod de a indica comenzii kubectl cu care cluster lucrați.

În interiorul clusterului, puteți crea mai multe spații de nume — un tip de cluster virtual în interiorul unui cluster fizic. Kubectl determină ce spațiu de nume să utilizeze tot pe baza datelor din fișierul kubeconfig. Asta înseamnă că aveți nevoie, de asemenea, de un mod de a indica comenzii kubectl cu ce spațiu de nume să lucrați.

În acest capitol, vom explica cum funcționează acest lucru și cum să obțineți o operare eficientă.

Rețineți că este posibil să aveți mai multe fișiere kubeconfig listate în variabila de mediu KUBECONFIG. În acest caz, toate aceste fișiere vor fi combinate într-o configurație comună în timpul execuției. De asemenea, puteți schimba fișierul kubeconfig utilizat în mod implicit, rulând kubectl cu parametrul --kubeconfig. Consultați documentația oficială.

Fișierele kubeconfig

Să vedem ce conține fișierul kubeconfig:

După cum puteți vedea, fișierul kubeconfig conține un set de contexte. Un context este format din trei elemente:

• Cluster — URL-ul API-ului serverului cluster-ului.
• User — acreditivele de autentificare ale utilizatorului în cluster.
• Namespace — spațiul de nume utilizat când te conectezi la cluster.

În practică, de obicei se folosește un singur context per cluster în fișierul kubeconfig. Totuși, este posibil să aveți mai multe contexte per cluster, diferite prin utilizator sau spațiu de nume. Totuși, o astfel de configurație cu mai multe contexte este rar întâlnită, deci de obicei există o corespondență reciprocă între clustere și contexte.

În orice moment, unul dintre contexte este cel curent:

Când kubectl citește fișierul de configurare, întotdeauna folosește informațiile din contextul curent. În exemplul de mai sus, kubectl se va conecta la cluster-ul Hare.

Prin urmare, pentru a schimba la un alt cluster, trebuie să schimbi contextul curent în fișierul kubeconfig:

Acum, kubectl se va conecta la cluster-ul Fox.

Pentru a schimba la un alt spațiu de nume în același cluster, trebuie să schimbi valoarea elementului namespace pentru contextul curent:

În exemplul de mai sus, kubectl va utiliza spațiul de nume Prod al cluster-ului Fox (anterior era setat spațiul de nume Test).

Rețineți că kubectl oferă de asemenea parametrii --cluster, --user, --namespace și --context, care permit suprascrierea unor elemente individuale și a contextului curent, indiferent de ceea ce este setat în fișierul kubeconfig. Consultați opțiunile kubectl.

Teoretic, puteți modifica manual parametrii din fișierul kubeconfig. Dar acest lucru nu este convenabil. Pentru a simplifica aceste operațiuni, există o varietate de utilitare care permit modificarea parametrilor în mod automat.

Folosiți kubectx

O utilitară foarte populară pentru comutarea între clustere și spații de nume.

Utilitarul oferă comenzi kubectx și kubens pentru a schimba contextul și spațiul de nume curente în consecință.

După cum am menționat, schimbarea contextului curent înseamnă schimbarea cluster-ului, dacă aveți doar un singur context pe cluster.

Iată un exemplu de execuție a acestor comenzi:

În esență, aceste comenzi editează pur și simplu fișierul kubeconfig, așa cum a fost descris mai sus.

Pentru a instala kubectx, urmați instrucțiunile de pe Github.

Ambele comenzi suportă completarea automată a numelui contextelor și spațiilor de nume, ceea ce permite să nu le introduceți complet. Instrucțiunile pentru configurarea completării automate aici.

O altă funcție utilă kubectx este modul interactiv. Acesta funcționează împreună cu utilitarul fzf, care trebuie instalat separat. Instalarea fzf face automat disponibil modul interactiv în kubectx. În modul interactiv, puteți alege contextul și spațiul de nume printr-o interfață interactivă de căutare liberă, oferită de fzf.

Utilizarea aliasurilor de shell

Nu aveți nevoie de instrumente separate pentru a schimba contextul și spațiul de nume curente, deoarece kubectl oferă și comenzi pentru asta. Astfel, comanda kubectl config oferă subcomenzi pentru editarea fișierelor kubeconfig.

Iată câteva dintre acestea:

• kubectl config get-contexts: afișa toate contexturile;
• kubectl config current-context: obține contextul curent;
• kubectl config use-context: schimbă contextul curent;
• kubectl config set-context: schimbă elementul contextului.

Cu toate acestea, utilizarea acestor comenzi direct nu este foarte convenabilă, deoarece sunt lungi. Puteți crea aliasuri de shell pentru ele, care sunt ușor de executat.

Am creat un set de aliasuri pe baza acestor comenzi, care oferă funcționalitate similară cu kubectx. Aici puteți vedea acțiunea lor:

Rețineți că aliasurile folosesc fzf pentru a oferi o interfață interactivă de căutare liberă (la fel ca în modul interactiv kubectx). Asta înseamnă că trebuie să instalați fzf, pentru a folosi aceste aliasuri.

Iată definițiile aliasurilor:

# Получить текущий контекст
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/^..//")"'

Pentru a instala aceste aliasuri, trebuie să adăugați definițiile de mai sus în fișierul dvs. ~/bashrc sau ~/zshrc și să reîncărcați shell-ul.

Utilizarea pluginurilor

Kubectl permite încărcarea pluginurilor, care se execută la fel ca comenzile principale. Puteți, de exemplu, să instalați pluginul kubectl-foo și să îl rulați executând comanda kubectl foo.

Ar fi convenabil să schimbi contextul și spațiul de nume în acest mod, de exemplu, rulând kubectl ctx pentru a schimba contextul și kubectl ns pentru a schimba spațiul de nume.

Am scris două plug-in-uri care fac asta:

• kubectl-ctx
• kubectl-ns

Funcționarea plug-in-urilor se bazează pe aliasurile din secțiunea anterioară.

Iată cum funcționează:

Rețineți că plug-in-urile folosesc fzf pentru a oferi o interfață interactivă de căutare liberă (așa cum este în modul interactiv kubectx). Asta înseamnă că trebuie să instalați fzf, pentru a folosi aceste aliasuri.

Pentru a instala plug-in-uri, trebuie să descărcați scripturile shell cu numele kubectl-ctx și kubectl-ns într-un director din variabila PATH și să le faceți executabile, de exemplu, folosind chmod +x. Imediat după asta, veți putea folosi kubectl ctx și kubectl ns.

5. Scurtarea introducerii cu aliasuri automate

Aliasurile shell-ului sunt o oportunitate bună de a accelera introducerea. Proiectul kubectl-aliases conține aproximativ 800 de scurtături pentru comenzile de bază kubectl.

S-ar putea să te întrebi — cum să reții 800 de aliasuri? Dar nu trebuie să le reții pe toate, deoarece acestea sunt construite după un model simplu, care este prezentat mai jos:

De exemplu:

1. kgpooyaml — kubectl get pods oyaml
2. ksysgsvcw — kubectl -n kube-system get svc w
3. ksysrmcm — kubectl -n kube-system rm cm
4. kgdepallsl — kubectl get deployment all sl

După cum vezi, aliasurile constau din componente, fiecare dintre ele reprezentând un element specific al comenzii kubectl. Fiecare alias poate avea o componentă pentru comanda de bază, operație și resursă și mai multe componente pentru parametri. Pur și simplu «umpli» aceste componente din stânga spre dreapta conform modelului de mai sus.

Schema detaliată curentă se află la GitHub. Acolo poți găsi și lista completă a pseudonimelor.

De exemplu, aliasul kgpooyamlall este echivalent cu comanda kubectl get pods -o yaml --all-namespaces.

Ordinea relativă a opțiunilor nu contează: comanda kgpooyamlall este echivalentă cu comanda kgpoalloyaml.

Nu trebuie să folosești toate componentele ca aliasuri. De exemplu, k, kg, klo, ksys, kgpo de asemenea, pot fi folosite. Mai mult, în linia de comandă pot fi combinate aliasurile și comenzile sau opțiunile obișnuite:

De exemplu:

1. În loc de kubectl proxy poate fi scris k proxy.
2. În loc de kubectl get roles poate fi scris kg roles (în prezent nu există un alias pentru resursa Roles).
3. Pentru a obține date despre un anumit pod, poți folosi comanda kgpo my-pod — kubectl get pod my-pod.

Rețineți că unele aliasuri necesită un argument în linia de comandă. De exemplu, aliasul kgpol înseamnă kubectl get pods -l. Opțiunea -l necesită un argument - specificația aliasului. Dacă folosiți un alias, acesta va arăta ca kgpol app=ui.

Dacă o parte din aliasuri necesită argumente, aliasurile a, f și l trebuie să fie utilizate la final.

În general, odată ce stăpâniți acest model, veți putea să extrageți intuitiv aliasurile din comenzi pe care doriți să le executați, economisind mult timp la introducerea lor.

Instalare

Pentru a instala kubectl-aliases, trebuie să descărcați fișierul .kubectl_aliases de pe GitHub și să-l includeți în fișierul ~/bashrc sau ~/zshrc:

source ~/.kubectl_aliases

Autocompletare

Așa cum am menționat, adesea adăugați cuvinte suplimentare la alias în linia de comandă. De exemplu:

$ kgpooyaml test-pod-d4b77b989

Dacă folosiți autocompletarea comenzii kubectl, probabil ați folosit autocompletarea pentru lucruri precum numele resurselor. Dar se poate face acest lucru atunci când folosiți aliasuri?

Aceasta este o întrebare foarte importantă, deoarece, dacă autocompletarea nu funcționează, veți pierde o parte din avantajele aliasurilor.

Răspunsul depinde de ce shell de comandă folosiți:

1. Pentru Zsh, autocompletarea pentru aliasuri funcționează 'din cutie'.
2. Din păcate, pentru Bash, sunt necesare unele acțiuni pentru a activa autocompletarea.

Activarea autocompletării pentru aliasuri în Bash

Problema cu Bash este că încearcă să autocompleteze (de fiecare dată când apăsați Tab) aliasul, nu comanda la care face referire aliasul (așa cum face, de exemplu, Zsh). Deoarece nu aveți scripturi de completare pentru toate cele 800 de aliasuri, autocompletarea nu funcționează.

Proiect complete-alias oferă o soluție generală pentru această problemă. Se leagă de mecanismul de completare pentru aliasuri, completează aliasul până la comandă și returnează opțiunile de completare pentru comanda completată. Aceasta înseamnă că completarea pentru un alias se comportă exact ca pentru o comandă completă.

Mai întâi, voi explica cum să instalați complete-alias și apoi cum să-l configurați pentru a activa completarea pentru toate aliasurile kubectl.

Instalarea complete-alias

În primul rând, complete-alias depinde de bash-completion. Așadar, înainte de a instala complete-alias, trebuie să vă asigurați că bash-completion este instalat. Instrucțiunile de instalare au fost date anterior pentru Linux și MacOS.

Notă importantă pentru utilizatorii MacOS: la fel ca și scriptul de autocompletare kubectl, complete-alias nu funcționează cu Bash 3.2, care este utilizat implicit în MacOS. În special, complete-alias depinde de bash-completion v2 (brew install bash-completion@2), pentru care este necesară cel puțin versiunea Bash 4.1. Aceasta înseamnă că pentru a utiliza complete-alias pe MacOS, trebuie să instalați o versiune mai nouă de Bash.

Trebuie să descărcați scriptul bash_completion.sh din din depozitul GitHub și să-l includeți în fișierul dumneavoastră ~/bashrc:

source ~/bash_completion.sh

După repornirea shell-ului, complete-alias va fi complet instalat.

Activarea autocompletării pentru aliasurile kubectl

Din punct de vedere tehnic, complete-alias oferă o funcție de shell _complete_alias. Această funcție verifică aliasurile și returnează sugestii de completare pentru comanda aliasului.

Pentru a asocia funcția cu un anumit alias, trebuie să folosiți mecanismul încorporat Bash complete, pentru a stabili _complete_alias ca funcție de completare a aliasului.

Ca exemplu, să luăm aliasul k, care reprezintă comanda kubectl. Pentru a stabili _complete_alias ca funcție de completare pentru acest alias, trebuie să executați următoarea comandă:

$ complete -F _complete_alias k

Rezultatul este că de fiecare dată când completați aliasul k, se apelează funcția _complete_alias, care verifică aliasul și returnează sugestiile de completare pentru comanda kubectl.

Ca al doilea exemplu, să luăm aliasul kg, care reprezintă kubectl get:

$ complete -F _complete_alias kg

La fel ca în exemplul anterior, când completați kg, veți obține aceleași sugestii de completare pe care le-ați obține pentru kubectl get.

Rețineți că se poate folosi complete-alias pentru orice alias în sistemul dumneavoastră.

Prin urmare, pentru a activa autocompletarea pentru toate aliasurile kubectl, trebuie să executați comanda de mai sus pentru fiecare dintre ele. Fragmentul următor face exact acest lucru, presupunând că ați instalat kubectl-aliases în ~/ .kubectl-aliases:

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

Această bucată de cod trebuie plasată în fișierul dumneavoastră ~/bashrc, reporniți shell-ul și autocompletarea va fi disponibilă pentru toate cele 800 de aliasuri kubectl.

6. Extinderea kubectl prin pluginuri

Începând cu versiunea 1.12, kubectl suportă un mecanism de pluginuri, care permit extinderea funcțiilor sale cu comenzi suplimentare.

Dacă sunteți familiarizat cu mecanismele pluginurilor Git, pluginurile kubectl sunt construite pe același principiu.

În acest capitol, vă vom arăta cum să instalați pluginuri, unde să le căutați și cum să creați propriile pluginuri.

Instalarea pluginurilor

Plugin-urile kubectl sunt distribuite sub formă de fișiere executabile simple numite kubectl-x. Prefixul kubectl- este obligatorie, urmată de o nouă subcomandă kubectl care permite apelarea pluginului.

De exemplu, pluginul hello va fi distribuit sub forma unui fișier denumit kubectl-hello.

Pentru a instala pluginul, trebuie să copiați fișierul kubectl-x în orice director din variabila dvs. PATH și să-l faceți executabil, de exemplu cu ajutorul chmod +x. Imediat după aceea, puteți apela pluginul folosind kubectl x.

Puteți folosi următoarea comandă pentru a afișa lista tuturor pluginurilor care sunt în prezent instalate în sistemul dumneavoastră:

$ kubectl plugin list

Această comandă va afișa, de asemenea, avertismente, dacă aveți mai multe pluginuri cu nume identice sau dacă există un fișier de pluginuri care nu este executabil.

Căutarea și instalarea pluginurilor folosind Krew

Pluginurile kubectl sunt disponibile pentru partajare sau reutilizare similar cu pachetele software. Dar unde puteți găsi pluginuri pe care le-au împărtășit alții?

Proiectul Krew este destinat să ofere o soluție unificată pentru partajarea, căutarea, instalarea și gestionarea pluginurilor kubectl. Proiectul se prezintă ca un "manager de pachete pentru pluginurile kubectl" (Krew este similar cu Brew).

Krew este o listă de pluginuri kubectl din care puteți alege și instala. De asemenea, Krew este un plugin pentru kubectl.

Asta înseamnă că instalarea Krew funcționează, în esență, ca instalarea oricărui alt plugin kubectl. Puteți găsi instrucțiuni detaliate pe pagina GitHub.

Cele mai importante comenzi Krew:

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

Rețineți că instalarea pluginurilor folosind Krew nu împiedică instalarea pluginurilor în mod standard, descris mai sus.

Observați că comanda kubectl krew list arată doar pluginurile care au fost instalate folosind Krew, în timp ce comanda kubectl plugin list enumeră toate pluginurile, adică pe cele instalate folosind Krew și pe cele instalate prin alte metode.

Căutarea pluginurilor în alte locuri

Krew este un proiect tânăr, în prezent în lista sa sunt doar aproximativ 30 de pluginuri. Dacă nu puteți găsi ceea ce aveți nevoie, puteți găsi pluginuri în alte locuri, cum ar fi GitHub.

Vă recomand să verificați secțiunea GitHub kubectl-plugins. Acolo veți găsi câteva zeci de pluginuri disponibile pe care merită să le verificați.

Scrierea propriilor pluginuri

Puteți crea propriile creați pluginuri — nu este greu. Trebuie să creați un fișier executabil care să facă ceea ce trebuie, numindu-l sub forma kubectl-x și să-l instalați, așa cum a fost descris mai sus.

Fișierul poate fi un script bash, un script python sau o aplicație compilată go — nu este important. Singura condiție este să poată fi executat direct în sistemul de operare.

Haideți să creăm un exemplu de plugin chiar acum. În secțiunea anterioară, ați folosit comanda kubectl pentru a lista containerele pentru fiecare pod. Este ușor să transformați această comandă într-un plugin pe care îl puteți apela, de exemplu, folosind kubectl img.

Creați un fișier kubectl-img users.module.ts

#!/bin/bash
kubectl get pods -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'

Acum faceți fișierul executabil cu ajutorul chmod +x kubectl-img și mutați-l într-un director din PATH-ul dumneavoastră. Imediat după aceasta, puteți folosi pluginul kubectl img.

Așa cum a fost menționat, pluginurile kubectl pot fi scrise în orice limbaj de programare sau scriptare. Dacă folosiți scripturi de shell, avantajul este posibilitatea de a apela cu ușurință kubectl din plugin. Cu toate acestea, puteți scrie pluginuri mai complexe în limbaje de programare reale, folosind biblioteca client Kubernetes. Dacă folosiți Go, puteți folosi de asemenea biblioteca cli-runtime, care a fost creată special pentru scrierea pluginurilor kubectl.

Cum să împărtășiți pluginurile dumneavoastră

Dacă credeți că pluginurile dumneavoastră ar putea fi utile altora, nu ezitați să le împărtășiți pe GitHub. Asigurați-vă că le adăugați la subiectul kubectl-plugins.

De asemenea, puteți solicita adăugarea pluginului dumneavoastră în lista Krew. Instrucțiuni despre cum să faceți acest lucru pot fi găsite în repozitoriul GitHub.

Completarea automată a comenzilor

În prezent, pluginurile nu suportă completarea automată. Adică, trebuie să introduceți numele complet al pluginului și numele complet al argumentelor.

În repo-ul GitHub kubectl, pentru această funcție există o cerere deschisă. Prin urmare, este posibil ca această funcție să fie implementată vreodată în viitor.

Mult noroc!!!

What else to read on the topic:

1. Three levels of autoscaling in Kubernetes and how to use them effectively.
2. Kubernetes in the spirit of piracy with an implementation template.
3. Our Around Kubernetes channel on Telegram.

Sursa: habr.com