🥇Cum să utilizați kubectl mai eficient: un ghid detaliat

Dacă lucrați cu Kubernetes, atunci kubectl este probabil unul dintre utilitarele pe care le utilizați cel mai mult. Și ori de câte ori petreci mult timp lucrând cu un anumit instrument, merită să îl studiezi bine și să înveți cum să-l folosești eficient.

Echipă Kubernetes aaS de la Mail.ru a tradus un articol de Daniel Weibel în care vei găsi sfaturi și trucuri pentru a lucra eficient cu kubectl. De asemenea, vă va ajuta să obțineți o înțelegere mai profundă a Kubernetes.

Potrivit autorului, scopul articolului este de a face munca zilnică cu Kubernetes nu numai mai eficientă, ci și mai plăcută!

Introducere: Ce este kubectl

Înainte de a putea învăța să utilizați kubectl mai eficient, trebuie să obțineți o înțelegere de bază despre ce este și cum funcționează.

Din perspectiva unui utilizator, kubectl este un panou de control care vă permite să efectuați operațiuni Kubernetes.

Din punct de vedere tehnic, kubectl este un client API Kubernetes.

API-ul Kubernetes este un API REST HTTP. Acest API este adevărata interfață de utilizator Kubernetes, prin care este complet controlat. Aceasta înseamnă că fiecare operațiune Kubernetes este expusă ca punct final API și poate fi efectuată cu o solicitare HTTP către acel punct final.

Prin urmare, sarcina principală a kubectl este să facă cereri HTTP către API-ul Kubernetes:

Kubernetes este un sistem complet orientat spre resurse. Aceasta înseamnă că menține starea internă a resurselor și toate operațiunile Kubernetes sunt operațiuni CRUD.

Dețineți controlul complet asupra Kubernetes gestionând aceste resurse, iar Kubernetes își dă seama ce trebuie să facă în funcție de starea actuală a resurselor. Din acest motiv, referința API Kubernetes este organizată ca o listă de tipuri de resurse cu operațiunile asociate.

Să ne uităm la un exemplu.

Să presupunem că doriți să creați o resursă ReplicaSet. Pentru a face acest lucru, descrieți ReplicaSet-ul într-un fișier după nume replicaset.yaml, apoi rulați comanda:

$ kubectl create -f replicaset.yaml

Aceasta va crea o resursă ReplicaSet. Dar ce se întâmplă în culise?

Kubernetes are o operație de creare ReplicaSet. Ca orice altă operație, este expusă ca un punct final API. Punctul final API specific pentru această operațiune arată astfel:

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

Punctele finale API pentru toate operațiunile Kubernetes pot fi găsite la Referință API (inclusiv punctul final de mai sus). Pentru a face o solicitare reală către un punct final, trebuie mai întâi să adăugați adresa URL a serverului API la căile punctului final care sunt listate în referința API.

Prin urmare, atunci când executați comanda de mai sus, kubectl trimite o solicitare HTTP POST la punctul final API de mai sus. Definiția ReplicaSet furnizată în fișier replicaset.yaml, se transmite în corpul cererii.

Iată cum funcționează kubectl pentru toate comenzile care interacționează cu clusterul Kubernetes. În toate aceste cazuri, kubectl pur și simplu face cereri HTTP către punctele finale API Kubernetes corespunzătoare.

Vă rugăm să rețineți că puteți gestiona pe deplin Kubernetes folosind un utilitar precum curlprin trimiterea manuală a solicitărilor HTTP către API-ul Kubernetes. Kubectl simplifică utilizarea API-ului Kubernetes.

Acestea sunt bazele a ceea ce este kubectl și cum funcționează. Dar mai există ceva despre API-ul Kubernetes pe care fiecare utilizator kubectl ar trebui să-l cunoască. Să aruncăm o privire rapidă în lumea interioară a Kubernetes.

Lumea interioară a Kubernetes

Kubernetes constă dintr-un set de componente independente care rulează ca procese separate pe nodurile de cluster. Unele componente rulează pe noduri master, altele pe noduri worker, fiecare componentă realizând propria sarcină specifică.

Iată cele mai importante componente de pe nodurile principale:

Seif - stochează definițiile resurselor (de obicei este etcd).
Server API — oferă un API și gestionează stocarea.
Manager de controler — Se asigură că stările resurselor respectă specificațiile.
Programator — programează pod-uri pe nodurile de lucru.

Și iată o componentă cea mai importantă a nodurilor de lucru:

kubelet — gestionează lansarea containerelor pe nodul de lucru.

Pentru a înțelege modul în care aceste componente funcționează împreună, să ne uităm la un exemplu.

Să presupunem că tocmai ați terminat kubectl create -f replicaset.yaml, după care kubectl a făcut o solicitare HTTP POST către Punct final API ReplicaSet (trecând definiția resursei ReplicaSet).

Ce se întâmplă în cluster?

După ce a făcut kubectl create -f replicaset.yaml Serverul API stochează definiția resursei ReplicaSet în stocare:
Apoi, controlerul ReplicaSet este lansat în managerul de controler, care se ocupă de crearea, modificarea și ștergerea resurselor ReplicaSet:
Controlerul ReplicaSet creează o definiție de pod pentru fiecare replică ReplicaSet (conform șablonului de pod din definiția ReplicaSet) și le stochează în stocare:
Planificatorul este lansat, urmărind podurile care nu au fost încă alocate niciunui nod de lucru:
Programatorul selectează un nod de lucru potrivit pentru fiecare pod și adaugă aceste informații la definiția podului din magazin:
Pe nodul de lucru căruia este alocat podul, Kubelet este lansat, urmărește podurile alocate acestui nod:
Kubelet citește definiția podului din stocare și indică unui container de rulare, cum ar fi Docker, să lanseze containere pe nod:

Mai jos este o versiune text a acestei descrieri.

Solicitarea API către punctul final de creare ReplicaSet este procesată de serverul API. Serverul API autentifică cererea și stochează definiția resursei ReplicaSet în stocare.

Acest eveniment pornește controlerul ReplicaSet, care este un subproces al managerului de controler. Controlerul ReplicaSet monitorizează crearea, actualizarea și ștergerea resurselor ReplicaSet din magazin și primește o notificare de eveniment atunci când se întâmplă acest lucru.

Sarcina controlerului ReplicaSet este să se asigure că există numărul necesar de poduri ReplicaSet. În exemplul nostru, încă nu există poduri, așa că controlerul ReplicaSet creează aceste definiții de pod (conform șablonului pod din definiția ReplicaSet) și le stochează în stocare.

Crearea de noi poduri este declanșată de un planificator care ține evidența definițiilor pod care nu sunt încă programate pentru nodurile de lucru. Planificatorul selectează un nod de lucru potrivit pentru fiecare pod și actualizează definițiile podului din depozit.

Rețineți că până în acest moment nu rula niciun cod de sarcină de lucru în cluster. Tot ce s-a făcut până acum - aceasta este crearea și actualizarea resurselor în depozitul de pe nodul principal.

Ultimul eveniment declanșează Kubelets, care monitorizează podurile programate pentru nodurile lor de lucru. Kubeletul nodului de lucru pe care sunt instalate pod-urile dvs. ReplicaSet trebuie să instruiască timpul de rulare al containerului, cum ar fi Docker, să descarce imaginile containerului necesare și să le ruleze.

În acest moment, aplicația dvs. ReplicaSet rulează în sfârșit!

Rolul API-ului Kubernetes

După cum ați văzut în exemplul anterior, componentele Kubernetes (cu excepția serverului API și a stocării) urmăresc modificările aduse resurselor din stocare și modifică informațiile despre resursele din stocare.

Desigur, aceste componente nu interacționează direct cu stocarea, ci doar prin intermediul API-ului Kubernetes.

Luați în considerare următoarele exemple:

Controlerul ReplicaSet utilizează punctul final API listați ReplicaSets cu parametru watch pentru a monitoriza modificările aduse resurselor ReplicaSet.
Controlerul ReplicaSet utilizează punctul final API creați Pod (create pod) a crea pod.
Scheduler folosește punctul final API patch pod (editați pod) pentru a actualiza pod-urile cu informații despre nodul de lucru selectat.

După cum puteți vedea, acesta este același API pe care îl accesează kubectl. Utilizarea aceluiași API pentru componentele interne și utilizatorii externi este un concept fundamental în proiectarea Kubernetes.

Acum putem rezuma modul în care funcționează Kubernetes:

Starea depozitelor de stocare, adică resursele Kubernetes.
Serverul API oferă o interfață pentru stocare sub forma API-ului Kubernetes.
Toate celelalte componente și utilizatori Kubernetes citesc, observă și manipulează starea (resursele) Kubernetes prin intermediul API-ului.

Cunoașterea acestor concepte vă va ajuta să înțelegeți mai bine kubectl și să profitați la maximum de el.

Acum să ne uităm la câteva sfaturi și trucuri specifice care vă vor ajuta să vă îmbunătățiți productivitatea cu kubectl.

1. Accelerați introducerea utilizând finalizarea comenzii

Una dintre cele mai utile, dar adesea trecute cu vederea, tehnici pentru îmbunătățirea performanței cu kubectl este finalizarea comenzilor.

Finalizarea comenzii vă permite să completați automat părți ale comenzilor kubectl folosind tasta Tab. Acest lucru funcționează pentru subcomenzi, opțiuni și argumente, inclusiv pentru ceva la fel de complex precum numele resurselor.

Vedeți cum funcționează finalizarea comenzii kubectl:

Finalizarea comenzii funcționează pentru shell-urile Bash și Zsh.

Ghid oficial conține instrucțiuni detaliate pentru configurarea completării automate, dar mai jos vom oferi un scurt fragment.

Cum funcționează finalizarea comenzii

Finalizarea comenzii este o caracteristică shell care funcționează folosind un script de finalizare. Un script de extensie este un script shell care definește comportamentul unei extensii pentru o anumită comandă.

Kubectl generează și emite automat scripturi de extensie pentru Bash și Zsh folosind următoarele comenzi:

$ kubectl completion bash

$ kubectl completion zsh

În teorie, este suficient să conectați ieșirea acestor comenzi la shell-ul de comandă corespunzător, astfel încât kubectl să poată completa comenzile.

În practică, metoda de conectare este diferită pentru Bash (inclusiv diferențele dintre Linux și MacOS) și Zsh. Mai jos vom analiza toate aceste opțiuni.

Bash pe Linux

Scriptul de finalizare Bash depinde de pachetul bash-completion, așa că trebuie să îl instalați mai întâi:

$ sudo apt-get install bash-completion

$ yum install bash-completion

Puteți testa dacă pachetul este instalat cu succes folosind următoarea comandă:

$ type _init_completion

Dacă acesta scoate codul funcției shell, atunci bash-completion este instalat corect. Dacă comanda dă o eroare „Negăsit”, trebuie să adăugați următoarea linie la fișier ~ / .bashrc:

$ source /usr/share/bash-completion/bash_completion

Este necesar să adăugați această linie la fișier ~ / .bashrc sau nu depinde de managerul de pachete pe care l-ați folosit pentru a instala bash-completion. Acest lucru este necesar pentru APT, dar nu pentru YUM.

După instalarea bash-completion, trebuie să configurați totul astfel încât scriptul de finalizare kubectl să fie activat în toate sesiunile shell.

O modalitate de a face acest lucru este să adăugați următoarea linie la fișier ~ / .bashrc:

source <(kubectl completion bash)

O altă modalitate este să adăugați scriptul de extensie kubectl în director /etc/bash_completion.d (creeaza-l daca nu exista):

$ kubectl completion bash >/etc/bash_completion.d/kubectl

Toate scripturile de supliment din catalog /etc/bash_completion.d sunt incluse automat în completarea bash.

Ambele opțiuni sunt aplicabile în mod egal.

După repornirea shell-ului, finalizarea comenzii kubectl va funcționa.

Bash pe MacOS

Pe MacOS, configurarea este puțin mai complicată. Faptul este că, în mod implicit, MacOS utilizează versiunea Bash 3.2, iar scriptul de completare automată kubectl necesită o versiune Bash de cel puțin 4.1 și nu funcționează în Bash 3.2.

Există probleme de licențiere asociate cu utilizarea unei versiuni învechite de Bash pe MacOS. Bash versiunea 4 este licențiată sub GPLv3, care nu este acceptată de Apple.

Pentru a configura completarea automată kubectl pe MacOS, trebuie să instalați o versiune mai recentă de Bash. De asemenea, puteți seta Bash-ul actualizat ca shell implicit, ceea ce vă va scuti de multe probleme în viitor. Nu este dificil, detaliile sunt date în articol „Actualizarea Bash pe MacOS".

Înainte de a continua, asigurați-vă că utilizați o versiune recentă de Bash (verificați rezultatul bash --version).

Scriptul de finalizare Bash variază în funcție de proiect bash-completare, așa că trebuie să îl instalați mai întâi.

Puteți instala bash-completion folosind Homebrew:

$ brew install bash-completion@2

Aici @2 înseamnă bash-completion versiunea 2. Kubectl autocompletion necesită bash-completion v2, iar bash-completion v2 necesită minimum versiunea Bash 4.1.

Ieșire de comandă brew-install conține o secțiune Avertismente, care specifică ce trebuie adăugat la fișier ~/.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"

Cu toate acestea, recomand să nu adăugați aceste rânduri ~/.bash_profile, și în ~/.bashrc. În acest caz, completarea automată va fi disponibilă nu numai în shell-urile de comandă principale, ci și în copil.

După repornirea shell-ului de comandă, puteți verifica că instalarea este corectă utilizând următoarea comandă:

$ type _init_completion

Dacă vedeți o funcție shell în ieșire, atunci totul este configurat corect.

Acum trebuie să ne asigurăm că completarea automată cu kubectl este activată în toate sesiunile.

O modalitate este să adăugați următoarea linie la dvs ~/.bashrc:

source <(kubectl completion bash)

A doua modalitate este să adăugați un script de autocompletare în folder /usr/local/etc/bash_completion.d:

$ kubectl completion bash
>/usr/local/etc/bash_completion.d/kubectl

Această metodă va funcționa numai dacă ați instalat bash-completion folosind Homebrew. În acest caz, bash-completion încarcă toate scripturile din acest director.

Daca ai instalat kubectl folosind Homebrew, atunci nu este nevoie să efectuați pasul anterior, deoarece scriptul de completare automată va fi plasat automat în folder /usr/local/etc/bash_completion.d în timpul instalării. În acest caz, autocompletarea kubectl va începe să funcționeze imediat ce instalați bash-completion.

Drept urmare, toate aceste opțiuni sunt echivalente.

zsh

Scripturile de completare automată pentru Zsh nu necesită dependențe. Tot ce trebuie să faceți este să le activați când încărcați shell-ul de comandă.

Puteți face acest lucru adăugând o linie la dvs ~/.zshrc fişier:

source <(kubectl completion zsh)

Dacă primiți o eroare not found: compdef după repornirea shell-ului, trebuie să activați funcția încorporată compdef. Îl puteți activa adăugându-l la începutul fișierului ~/.zshrc următor:

autoload -Uz compinit
compinit

2. Vizualizați rapid specificațiile resurselor

Când creați definiții de resurse YAML, trebuie să cunoașteți câmpurile și semnificația acestora pentru resursele respective. Un loc pentru a căuta aceste informații este în referința API, care conține specificații complete pentru toate resursele.

Cu toate acestea, trecerea la browserul web de fiecare dată când trebuie să căutați ceva este incomod. Prin urmare, kubectl oferă comanda kubectl explain, care arată specificațiile tuturor resurselor chiar în terminalul dvs.

Formatul comenzii este următorul:

$ kubectl explain resource[.field]...

Comanda va scoate specificația resursei sau câmpului solicitat. Informațiile afișate sunt identice cu cele conținute în manualul API.

În mod implicit kubectl explain arată doar primul nivel de cuibărit al câmpurilor.

Vezi cum arată Puteți apoi.

Puteți afișa întregul arbore dacă adăugați opțiunea --recursive:

$ kubectl explain deployment.spec --recursive

Dacă nu știți exact ce resurse sunt necesare, le puteți afișa pe toate cu următoarea comandă:

$ kubectl api-resources

Această comandă afișează numele resurselor în formă de plural, de ex. deployments în loc de deployment. De asemenea, afișează numele scurt, de exemplu deploy, pentru acele resurse care o au. Nu vă faceți griji pentru aceste diferențe. Toate aceste opțiuni de denumire sunt echivalente pentru kubectl. Adică puteți folosi oricare dintre ele pentru kubectl explain.

Toate comenzile următoare sunt echivalente:

$ kubectl explain deployments.spec
# или
$ kubectl explain deployment.spec
# или        
$ kubectl explain deploy.spec

3. Utilizați un format personalizat de ieșire a coloanei

Format implicit de ieșire a comenzii 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

Acest format este convenabil, dar conține o cantitate limitată de informații. În comparație cu formatul complet al definiției resurselor, aici sunt afișate doar câteva câmpuri.

În acest caz, puteți utiliza un format personalizat de ieșire a coloanei. Vă permite să determinați ce date să scoateți. Puteți afișa orice câmp de resurse ca o coloană separată.

Utilizarea unui format personalizat este determinată folosind opțiunile:

-o custom-columns=<header>:<jsonpath>[,<header>:<jsonpath>]...

Puteți defini fiecare coloană de ieșire ca o pereche <header>:<jsonpath>Unde <header> este numele coloanei și <jsonpath> — o expresie care definește un câmp de resurse.

Să ne uităm la 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 opțiune selectează numele podurilor din câmp metadata.name. Acest lucru se datorează faptului că numele podului este definit în câmpul pentru numele copilului metadata în descrierea resursei podului. Mai multe detalii pot fi găsite în Ghid API sau tastați comanda kubectl explain pod.metadata.name.

Acum să presupunem că doriți să adăugați o coloană suplimentară la rezultat, de exemplu, arătând nodul pe care rulează fiecare pod. Pentru a face acest lucru, puteți adăuga pur și simplu specificația corespunzătoare a coloanei la opțiunea coloane 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 — când un pod este atribuit unui nod, numele acestuia este scris în câmp spec.nodeName specificația resurselor pod. Informații mai detaliate pot fi găsite în rezultat kubectl explain pod.spec.nodeName.

Rețineți că câmpurile de resurse Kubernetes țin cont de majuscule și minuscule.

Puteți vizualiza orice câmp de resurse ca o coloană. Examinați specificația resursei și încercați-l cu orice câmpuri doriți.

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

Expresii JSONPath

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

JSONPath este un limbaj pentru preluarea datelor din documente JSON. Selectarea unui singur câmp este cel mai simplu caz de utilizare pentru JSONPath. Are multe mai multe posibilitati, inclusiv selectoare, filtre și așa mai departe.

Kubectl explica acceptă un număr limitat de caracteristici JSONPath. Posibilitățile și exemplele de utilizare ale acestora sunt descrise mai jos:

# Выбрать все элементы списка
$ 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 [] este deosebit de important. Multe câmpuri de resurse Kubernetes sunt liste, iar acest operator vă permite să selectați membrii acestor liste. Este adesea folosit cu un wildcard precum [*] pentru a selecta toate elementele unei liste.

Exemple de aplicații

Posibilitățile de utilizare a unui format personalizat de ieșire a coloanei sunt nelimitate, deoarece puteți afișa 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 singur și să găsiți aplicații care funcționează pentru dvs.

Afișarea imaginilor containerului pentru păstăi:

$ 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 containerului pentru fiecare pod.

Rețineți că un pod poate conține mai multe containere, apoi numele imaginilor vor fi afișate pe o singură linie, separate prin virgulă.

Afișarea zonelor de disponibilitate a 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 utilă dacă clusterul dvs. este găzduit într-un cloud public. Afișează zona de disponibilitate pentru fiecare nod.

Zona de disponibilitate este un concept de nor care limitează 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 rulează într-un cloud public, această etichetă este creată automat și completată cu numele zonelor de disponibilitate pentru fiecare nod.

Etichetele nu fac parte din specificația resurselor Kubernetes, așa că nu veți găsi informații despre ele în Ghid API. Cu toate acestea, ele pot fi văzute (ca orice alte etichete) dacă solicitați informații despre nodurile în format YAML sau JSON:
```
$ kubectl get nodes -o yaml
# или
$ kubectl get nodes -o json
```
Aceasta este o modalitate excelentă de a afla mai multe despre resurse, pe lângă specificațiile resurselor de învățare.

4. Comutați cu ușurință între clustere și spații de nume

Când kubectl face o solicitare către API-ul Kubernetes, mai întâi citește fișierul kubeconfig pentru a obține toți parametrii necesari pentru conexiune.

Î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 kubeconfig conține setări pentru conectarea la toate aceste clustere. Aveți nevoie de o modalitate de a spune comenzii kubectl cu ce cluster lucrați.

În cadrul unui cluster, puteți crea mai multe spații de nume — un tip de cluster virtual într-un cluster fizic. De asemenea, Kubectl determină ce spațiu de nume să folosească pe baza fișierului kubeconfig. Aceasta înseamnă că aveți nevoie și de o modalitate de a spune comenzii kubectl cu ce spațiu de nume să lucreze.

În acest capitol vom explica cum funcționează și cum să-l facem să funcționeze 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 singură configurație comună în timpul execuției. De asemenea, puteți modifica fișierul kubeconfig implicit rulând kubectl cu parametrul --kubeconfig. Uite documentație oficială.

fișierele kubeconfig

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

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

Cluster — URL-ul API al serverului cluster.
Utilizator - acreditări de autentificare a utilizatorului în cluster.
Spațiu de nume - spațiul de nume folosit la alăturarea clusterului.

În practică, ei folosesc adesea un context per cluster în kubeconfig. Cu toate acestea, puteți avea mai multe contexte per cluster, diferențiate în funcție de utilizator sau spațiu de nume. Cu toate acestea, această configurație multi-context este neobișnuită, deci există de obicei o mapare unu-la-unu între clustere și contexte.

În orice moment, unul dintre contexte este actual:

Când kubectl citește un fișier de configurare, preia întotdeauna informații din contextul curent. În exemplul de mai sus, kubectl se va conecta la clusterul Hare.

În consecință, pentru a comuta la un alt cluster, trebuie să schimbați contextul curent în fișierul kubeconfig:

Acum, kubectl se va conecta la clusterul Fox.

Pentru a comuta la un spațiu de nume diferit în același cluster, trebuie să modificați valoarea elementului spațiu de nume pentru contextul curent:

În exemplul de mai sus, kubectl va folosi spațiul de nume Prod al clusterului Fox (anterior era setat spațiul de nume Test).

Rețineți că kubectl oferă și opțiuni --cluster, --user, --namespace и --context, care vă permit să suprascrieți elemente individuale și contextul curent în sine, indiferent de ceea ce este setat în kubeconfig. Uite kubectl options.

În teorie, puteți modifica manual setările din kubeconfig. Dar este incomod. Pentru a simplifica aceste operațiuni, există diverse utilități care vă permit să schimbați parametrii automat.

Folosiți kubectx

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

Utilitarul oferă comenzi kubectx и kubens pentru a schimba contextul curent și respectiv spațiul de nume.

După cum am menționat, schimbarea contextului actual înseamnă schimbarea clusterului dacă aveți doar un context per cluster.

Iată un exemplu de rulare a acestor comenzi:

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

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

Ambele comenzi acceptă completarea automată a numelor de context și de spațiu de nume, ceea ce elimină complet necesitatea de a le introduce. Instrucțiuni pentru configurarea completării automate aici.

O altă caracteristică utilă kubectx este modul interactiv. Funcționează împreună cu utilitarul fzf, care trebuie instalat separat. Instalarea fzf face automat disponibil modul interactiv în kubectx. În mod interactiv, puteți selecta contextul și spațiul de nume prin interfața interactivă de căutare gratuită oferită de fzf.

Folosind aliasuri shell

Nu aveți nevoie de instrumente separate pentru a schimba contextul și spațiul de nume curent, deoarece kubectl oferă și comenzi pentru aceasta. Da, echipa kubectl config oferă subcomenzi pentru editarea fișierelor kubeconfig.

Iată câteva dintre ele:

kubectl config get-contexts: afișați toate contextele;
kubectl config current-context: obține contextul actual;
kubectl config use-context: schimbarea contextului actual;
kubectl config set-context: Schimbați elementul de context.

Cu toate acestea, utilizarea directă a acestor comenzi 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 bazate pe aceste comenzi care oferă funcționalități similare cu kubectx. Aici le puteți vedea în acțiune:

Rețineți că aliasurile folosesc fzf pentru a oferi o interfață interactivă de căutare gratuită (cum ar fi modul interactiv al lui kubectx). Asta înseamnă că ai nevoie instalați fzfpentru a folosi aceste pseudonime.

Iată definițiile alias-urilor în sine:

# Получить текущий контекст
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 seta aceste aliasuri, trebuie să adăugați definițiile de mai sus în fișierul dvs ~/.bashrc sau ~/.zshrc și reporniți-vă shell-ul.

Folosind pluginuri

Kubectl vă permite să încărcați pluginuri care sunt executate în același mod ca și comenzile de bază. Puteți, de exemplu, să instalați pluginul kubectl-foo și să îl rulați executând comanda kubectl foo.

Ar fi convenabil să schimbați contextul și spațiul de nume în acest fel, de exemplu prin rulare kubectl ctx să schimbe contextul și kubectl ns pentru a schimba spațiul de nume.

Am scris două plugin-uri care fac asta:

Lucrarea pluginurilor se bazează pe aliasuri din secțiunea anterioară.

Iată cum funcționează:

Rețineți că pluginurile folosesc fzf pentru a oferi o interfață interactivă de căutare gratuită (cum ar fi modul interactiv al lui kubectx). Asta înseamnă că ai nevoie instalați fzfpentru a folosi aceste pseudonime.

Pentru a instala pluginuri, trebuie să descărcați scripturile shell numite kubectl-ctx и kubectl-ns în orice director din variabila PATH și faceți-le executabile cu, de ex. chmod +x. Imediat după aceasta veți putea folosi kubectl ctx и kubectl ns.

5. Reduceți intrarea cu aliasuri automate

Aliasurile Shell sunt o modalitate bună de a accelera tastarea. Proiect kubectl-aliasuri conține aproximativ 800 de comenzi rapide pentru comenzile kubectl de bază.

S-ar putea să vă întrebați - cum vă amintiți 800 de aliasuri? Dar nu trebuie să le amintiți pe toate, deoarece sunt construite după o schemă simplă, care este prezentată mai jos:

De exemplu:

kgpooyaml - kubectl get pods oyaml
ksysgsvcw — kubectl -n kube-system get svc w
ksysrmcm -kubectl -n kube-system rm cm
kgdepallsl - kubectl obține implementarea tuturor sl

După cum puteți vedea, aliasurile sunt alcătuite din componente, fiecare dintre acestea 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 „populați” aceste componente de la stânga la dreapta conform diagramei de mai sus.

Diagrama detaliată actuală este la GitHub. Acolo gasesti si lista completă de aliasuri.

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

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

Nu trebuie să utilizați toate componentele ca alias. De exemplu k, kg, klo, ksys, kgpo poate fi de asemenea folosit. Mai mult, puteți combina aliasuri și comenzi sau opțiuni obișnuite pe linia de comandă:

De exemplu:

În loc de kubectl proxy poti sa scrii k proxy.
În loc de kubectl get roles poti sa scrii kg roles (în prezent nu există un alias pentru resursa Roluri).
Pentru a obține date pentru un anumit pod, puteți utiliza comanda kgpo my-pod — kubectl get pod my-pod.

Vă rugăm să rețineți că unele aliasuri necesită un argument în linia de comandă. De exemplu, alias kgpol mijloace kubectl get pods -l. Opțiune -l necesită un argument - o specificație de etichetă. Dacă utilizați un alias, va arăta ca kgpol app=ui.

Deoarece unele aliasuri necesită argumente, aliasurile a, f și l trebuie folosite ultimele.

În general, odată ce ați înțeles această schemă, puteți obține în mod intuitiv aliasuri din comenzile pe care doriți să le executați și să economisiți mult timp de tastare.

instalare

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

source ~/.kubectl_aliases

Completare automată

După cum am spus mai devreme, adăugați adesea cuvinte suplimentare la un alias pe linia de comandă. De exemplu:

$ kgpooyaml test-pod-d4b77b989

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

Aceasta este o întrebare foarte importantă, deoarece dacă completarea automată nu funcționează, veți pierde unele dintre beneficiile aliasurilor.

Răspunsul depinde de shell-ul pe care îl utilizați:

Pentru Zsh, completarea aliasului funcționează imediat.
Pentru Bash, din păcate, este nevoie de ceva muncă pentru ca completarea automată să funcționeze.

Activarea completării automate pentru aliasuri în Bash

Problema cu Bash este că încearcă să completeze (de fiecare dată când apăsați Tab) aliasul, mai degrabă decât comanda la care se referă aliasul (cum face Zsh, de exemplu). Deoarece nu aveți scripturi de completare pentru toate cele 800 de aliasuri, completarea automată nu funcționează.

Proiect complet-alias oferă o soluție generală la această problemă. Se conectează la mecanismul de completare a aliasului, extinde intern aliasul la o comandă și returnează opțiunile de completare pentru comanda finalizată. Aceasta înseamnă că umplutura pentru un alias se comportă exact la fel ca pentru o comandă completă.

În cele ce urmează, voi explica mai întâi cum să instalez complete-alias și apoi cum să-l configurez pentru a permite finalizarea pentru toate aliasurile kubectl.

Instalarea complete-alias

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

Notă importantă pentru utilizatorii MacOS: La fel ca scriptul de completare automată kubectl, aliasul complet nu funcționează cu Bash 3.2, care este implicit pe MacOS. În special, aliasul complet depinde de completarea bash v2 (brew install bash-completion@2), care necesită cel puțin Bash 4.1. Aceasta înseamnă că, pentru a utiliza aliasul complet pe MacOS, trebuie să instalați o versiune mai nouă de Bash.

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

source ~/bash_completion.sh

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

Activarea completării automate pentru aliasurile kubectl

Aliasul complet din punct de vedere tehnic oferă o funcție de wrapper _complete_alias. Această funcție verifică alias-ul și returnează indicii de completare pentru comanda alias.

Pentru a asocia o funcție cu un alias specific, trebuie să utilizați mecanismul Bash încorporat Completă, a instala _complete_alias ca o funcție de completare a aliasului.

Ca exemplu, să luăm alias-ul k, care reprezintă comanda kubectl. a instala _complete_alias Ca funcție complementară pentru acest alias, ar trebui să rulați următoarea comandă:

$ complete -F _complete_alias k

Rezultatul este că ori de câte ori completați automat un alias k, funcția este apelată _complete_alias, care verifică aliasul și returnează indicii de completare pentru comandă kubectl.

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

$ complete -F _complete_alias kg

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

Rețineți că puteți utiliza complete-alias pentru orice alias de pe sistemul dumneavoastră.

Prin urmare, pentru a activa completarea automată pentru toate aliasurile kubectl, trebuie să rulați comanda de mai sus pentru fiecare dintre ele. Următorul fragment face exact acest lucru, cu condiția să fi setat kubectl-aliases la ~/.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 să fie plasată în dvs ~/.bashrc, reporniți shell-ul de comandă și completarea automată va deveni disponibilă pentru toate cele 800 de aliasuri kubectl.

6. Extinderea kubectl cu pluginuri

pornind de la versiunea 1.12, kubectl suportă mecanism de plugin, care vă permit să-și extindeți funcțiile cu comenzi suplimentare.

Dacă sunteți familiarizat cu Mecanisme de plugin Git, atunci pluginurile kubectl sunt construite pe același principiu.

În acest capitol, vom aborda cum să instalați pluginuri, unde să le găsiți și cum să vă creați propriile plugin-uri.

Instalarea pluginurilor

Pluginurile Kubectl sunt distribuite ca simple fișiere executabile cu numele similar kubectl-x. Prefix kubectl- este necesar, urmat de o nouă subcomandă kubectl care vă permite să apelați pluginul.

De exemplu, pluginul hello va fi distribuit ca un fișier numit kubectl-hello.

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

Puteți utiliza următoarea comandă pentru a lista toate pluginurile care sunt instalate în prezent pe sistemul dvs.:

$ kubectl plugin list

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

Găsirea și instalarea pluginurilor folosind Krew

Pluginurile Kubectl pot fi partajate sau reutilizate ca pachete software. Dar unde poți găsi pluginuri pe care alții le-au distribuit?

Proiectul Krew își propune să ofere o soluție unificată pentru partajarea, căutarea, instalarea și gestionarea pluginurilor kubectl. Proiectul se numește „manager de pachete pentru pluginuri kubectl” (Krew este similar cu pune la cale).

Krew este o listă de plugin-uri kubectl pe care le puteți selecta și instala. În același timp, Krew este și un plugin pentru kubectl.

Aceasta înseamnă că instalarea Krew funcționează în esență ca și instalarea oricărui alt plugin kubectl. Puteți găsi instrucțiuni detaliate la Pagina GitHub.

Cele mai importante comenzi Krew sunt:

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

Vă rugăm să rețineți că instalarea pluginurilor folosind Krew nu interferează cu instalarea pluginurilor folosind metoda standard descrisă mai sus.

Vă rugăm să rețineți că comanda kubectl krew list afișează numai pluginurile care au fost instalate folosind Krew, în timp ce comanda kubectl plugin list listează toate pluginurile, adică cele instalate folosind Krew și cele instalate prin alte metode.

Găsirea pluginurilor în altă parte

Krew este un proiect tânăr, aflat în prezent lista doar aproximativ 30 de plugin-uri. Dacă nu găsiți ceea ce aveți nevoie, puteți găsi pluginuri în altă parte, cum ar fi GitHub.

Recomand să te uiți la secțiunea GitHub kubectl-plugins. Acolo veți găsi zeci de plugin-uri disponibile care merită verificate.

Scrierea propriilor pluginuri

poți tu însuți creați pluginuri - Nu este greu. Trebuie să creați un executabil care să facă ceea ce aveți nevoie, numiți-l așa kubectl-x și instalați așa cum este descris mai sus.

Fișierul ar putea fi un script bash, un script python sau o aplicație GO compilată - nu contează. Singura condiție este ca acesta să poată fi executat direct în sistemul de operare.

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 ex. kubectl img.

Creați un fișier kubectl-img urmatorul continut:

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

Acum faceți fișierul executabil cu chmod +x kubectl-img și mutați-l în orice director din PATH. Imediat după aceasta puteți utiliza pluginul kubectl img.

După cum am menționat, pluginurile kubectl pot fi scrise în orice limbaj de programare sau scripting. Dacă utilizați scripturi shell, avantajul de a putea apela cu ușurință kubectl din interiorul pluginului. Cu toate acestea, puteți scrie plugin-uri mai complexe în limbaje de programare reale folosind Biblioteca client Kubernetes. Dacă utilizați Go, puteți utiliza și biblioteca cli-runtime, care există special pentru scrierea pluginurilor kubectl.

Cum să-ți partajezi pluginurile

Dacă credeți că pluginurile dvs. ar putea fi utile altora, nu ezitați să le distribuiți pe GitHub. Asigurați-vă că le adăugați la subiect kubectl-plugins.

De asemenea, puteți solicita adăugarea pluginului dvs. la Lista Krew. Instrucțiunile despre cum să faceți acest lucru sunt în Arhivele GitHub.

Finalizarea comenzii

Pluginurile nu acceptă în prezent completarea automată. Adică trebuie să introduceți numele complet al pluginului și numele complete ale argumentelor.

Depozitul GitHub kubectl pentru această funcție are cerere deschisă. Deci, este posibil ca această caracteristică să fie implementată cândva în viitor.

Mult noroc!

Ce să mai citești pe subiect:

Sursa: www.habr.com

Cum să utilizați kubectl mai eficient: un ghid detaliat