🥇Si të përdorni kubectl në mënyrë më efektive: një udhëzues i detajuar

Nëse punoni me Kubernetes, atëherë kubectl është ndoshta një nga shërbimet që përdorni më shumë. Dhe sa herë që kaloni shumë kohë duke punuar me një mjet të caktuar, ia vlen ta studioni mirë dhe të mësoni se si ta përdorni në mënyrë efektive.

Ekip Kubernetes aaS nga Mail.ru përktheu një artikull nga Daniel Weibel në të cilin do të gjeni këshilla dhe truket për të punuar në mënyrë efektive me kubectl. Gjithashtu do t'ju ndihmojë të fitoni një kuptim më të thellë të Kubernetes.

Sipas autorit, qëllimi i artikullit është ta bëjë punën tuaj të përditshme me Kubernetes jo vetëm më efikase, por edhe më të këndshme!

Hyrje: Çfarë është kubectl

Përpara se të mësoni të përdorni kubectl në mënyrë më efektive, duhet të fitoni një kuptim bazë të asaj që është dhe si funksionon.

Nga këndvështrimi i një përdoruesi, kubectl është një panel kontrolli që ju lejon të kryeni operacionet Kubernetes.

Duke folur teknikisht, kubectl është një klient API i Kubernetes.

Kubernetes API është një API HTTP REST. Ky API është ndërfaqja e vërtetë e përdoruesit Kubernetes, përmes së cilës kontrollohet plotësisht. Kjo do të thotë që çdo operacion Kubernetes ekspozohet si një pikë fundore API dhe mund të bëhet me një kërkesë HTTP në atë pikë fundore.

Prandaj, puna kryesore e kubectl është të bëjë kërkesa HTTP në Kubernetes API:

Kubernetes është një sistem plotësisht i orientuar drejt burimeve. Kjo do të thotë që ruan gjendjen e brendshme të burimeve dhe të gjitha operacionet e Kubernetes janë operacione CRUD.

Ju jeni në kontroll të plotë të Kubernetes duke menaxhuar këto burime dhe Kubernetes kupton se çfarë të bëjë bazuar në gjendjen aktuale të burimeve. Për këtë arsye, referenca Kubernetes API organizohet si një listë e llojeve të burimeve me operacionet e tyre të lidhura.

Le të shohim një shembull.

Le të themi se dëshironi të krijoni një burim ReplicaSet. Për ta bërë këtë, ju përshkruani ReplicaSet në një skedar me emër replicaset.yaml, pastaj ekzekutoni komandën:

$ kubectl create -f replicaset.yaml

Kjo do të krijojë një burim ReplicaSet. Por çfarë ndodh prapa skenave?

Kubernetes ka një operacion krijimi ReplicaSet. Si çdo operacion tjetër, ai ekspozohet si një pikë fundore e API. Pika përfundimtare specifike e API-së për këtë operacion duket si kjo:

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

Pikat përfundimtare të API për të gjitha operacionet e Kubernetes mund të gjenden në Referenca API (duke përfshirë pikën përfundimtare të mësipërme). Për të bërë një kërkesë aktuale në një pikë fundore, fillimisht duhet të shtoni URL-në e serverit API në shtigjet e pikës fundore që janë të listuara në referencën API.

Prandaj, kur ekzekutoni komandën e mësipërme, kubectl dërgon një kërkesë HTTP POST në pikën përfundimtare të API-së së mësipërme. Përkufizimi i ReplicaSet që keni dhënë në skedar replicaset.yaml, dërgohet në trupin e kërkesës.

Kështu funksionon kubectl për të gjitha komandat që ndërveprojnë me grupin Kubernetes. Në të gjitha këto raste, kubectl thjesht bën kërkesa HTTP në pikat e duhura fundore të Kubernetes API.

Ju lutemi vini re se mund të menaxhoni plotësisht Kubernetes duke përdorur një mjet si p.sh curlduke dërguar manualisht kërkesat HTTP në Kubernetes API. Kubectl thjesht e bën më të lehtë përdorimin e Kubernetes API.

Këto janë bazat e asaj se çfarë është kubectl dhe si funksionon. Por ka diçka tjetër rreth Kubernetes API që çdo përdorues i kubectl duhet ta dijë. Le të hedhim një vështrim të shpejtë në botën e brendshme të Kubernetes.

Bota e brendshme e Kubernetes

Kubernetes përbëhet nga një grup komponentësh të pavarur që funksionojnë si procese të veçanta në nyjet e grupimit. Disa komponentë funksionojnë në nyjet kryesore, të tjerët në nyjet e punës, secili komponent kryen detyrën e tij specifike.

Këtu janë komponentët më të rëndësishëm në nyjet kryesore:

Qemer - ruan përkufizimet e burimeve (zakonisht është etj).
Serveri API — siguron një API dhe menaxhon ruajtjen.
Menaxheri i Kontrolluesit — Siguron që statuset e burimeve të përputhen me specifikimet.
Programuesi — planifikon pods në nyjet e punëtorëve.

Dhe këtu është një komponent më i rëndësishëm në nyjet e punëtorëve:

kubelet — menaxhon nisjen e kontejnerëve në nyjen e punës.

Për të kuptuar se si këta komponentë punojnë së bashku, le të shohim një shembull.

Le të supozojmë se sapo keni përfunduar kubectl create -f replicaset.yaml, pas së cilës kubectl bëri një kërkesë HTTP POST për të Pika e fundit e API-së ReplicaSet (duke kaluar përkufizimin e burimit ReplicaSet).

Çfarë po ndodh në grup?

Pasi bëri kubectl create -f replicaset.yaml Serveri API ruan përkufizimin tuaj të burimit ReplicaSet në ruajtje:
Më pas, kontrolluesi ReplicaSet lëshohet në menaxherin e kontrolluesit, i cili merret me krijimin, modifikimin dhe fshirjen e burimeve të ReplicaSet:
Kontrolluesi ReplicaSet krijon një përkufizim pod për çdo kopje të ReplicaSet (sipas shabllonit të pod në përkufizimin ReplicaSet) dhe i ruan ato në ruajtje:
Planifikuesi është nisur, duke gjurmuar podet që nuk janë caktuar ende në asnjë nyje punonjësi:
Planifikuesi zgjedh një nyje pune të përshtatshme për çdo pod dhe shton këtë informacion në përkufizimin e pod në dyqan:
Në nyjen e punës së cilës i është caktuar pod, Kubelet lëshohet, ai gjurmon podet e caktuara në këtë nyje:
Kubelet lexon përkufizimin e pod nga ruajtja dhe udhëzon një kohë ekzekutimi të kontejnerit, siç është Docker, për të nisur kontejnerët në nyje:

Më poshtë është një version tekst i këtij përshkrimi.

Kërkesa API për pikën përfundimtare të krijimit të ReplicaSet përpunohet nga serveri API. Serveri API vërteton kërkesën dhe ruan përkufizimin e burimit ReplicaSet në ruajtje.

Kjo ngjarje fillon kontrolluesin ReplicaSet, i cili është një nënproces i menaxherit të kontrolluesit. Kontrolluesi ReplicaSet monitoron krijimin, përditësimin dhe fshirjen e burimeve të ReplicaSet në dyqan dhe merr një njoftim ngjarjeje kur kjo ndodh.

Detyra e kontrolluesit të ReplicaSet është të sigurojë që numri i kërkuar i podeve të ReplicaSet ekziston. Në shembullin tonë, nuk ekzistojnë ende pods, kështu që kontrolluesi ReplicaSet krijon këto përkufizime të pod (sipas shabllonit të pod në përkufizimin ReplicaSet) dhe i ruan ato në ruajtje.

Krijimi i pods-eve të reja nxitet nga një planifikues që mban gjurmët e përkufizimeve të pod që nuk janë planifikuar ende për nyjet e punës. Planifikuesi zgjedh një nyje pune të përshtatshme për çdo pod dhe përditëson përkufizimet e pod në depo.

Vini re se deri në këtë pikë, asnjë kod i ngarkesës së punës nuk funksiononte askund në grup. Gjithçka që është bërë deri tani - ky është krijimi dhe përditësimi i burimeve në depo në nyjen kryesore.

Ngjarja e fundit aktivizon Kubelets, të cilat monitorojnë podet e planifikuara për nyjet e tyre të punës. Kubelet i nyjës punëtore në të cilën janë instaluar podet tuaja ReplicaSet duhet të udhëzojë kohën e ekzekutimit të kontejnerit, si p.sh. Docker, të shkarkojë imazhet e kërkuara të kontejnerit dhe t'i ekzekutojë ato.

Në këtë pikë, aplikacioni juaj ReplicaSet më në fund po funksionon!

Roli i Kubernetes API

Siç e patë në shembullin e mëparshëm, komponentët e Kubernetes (përveç serverit API dhe ruajtjes) vëzhgojnë ndryshimet në burimet në ruajtje dhe ndryshojnë informacionin rreth burimeve në ruajtje.

Sigurisht, këta komponentë nuk ndërveprojnë drejtpërdrejt me hapësirën ruajtëse, por vetëm përmes Kubernetes API.

Merrni parasysh shembujt e mëposhtëm:

Kontrolluesi ReplicaSet përdor pikën përfundimtare të API lista ReplicaSets me parametër watch për të monitoruar ndryshimet në burimet e ReplicaSet.
Kontrolluesi ReplicaSet përdor pikën përfundimtare të API krijoni Pod (krijo pod) për të krijuar pods.
Scheduler përdor pikën përfundimtare të API-së patch pod (redakto pod) për të përditësuar pods me informacion në lidhje me nyjen e zgjedhur të punëtorit.

Siç mund ta shihni, ky është i njëjti API që ka qasje kubectl. Përdorimi i të njëjtës API për komponentët e brendshëm dhe përdoruesit e jashtëm është një koncept themelor në dizajnin e Kubernetes.

Tani mund të përmbledhim se si funksionon Kubernetes:

Dyqanet e ruajtjes deklarojnë, domethënë burimet e Kubernetes.
Serveri API ofron një ndërfaqe për ruajtjen në formën e Kubernetes API.
Të gjithë përbërësit dhe përdoruesit e tjerë të Kubernetes lexojnë, vëzhgojnë dhe manipulojnë gjendjen (burimet) e Kubernetes përmes API-së.

Njohja e këtyre koncepteve do t'ju ndihmojë të kuptoni më mirë kubectl dhe të përfitoni sa më shumë prej tij.

Tani le të shohim disa këshilla dhe truke specifike që do të ndihmojnë në përmirësimin e produktivitetit tuaj me kubectl.

1. Përshpejtoni hyrjen duke përdorur përfundimin e komandës

Një nga teknikat më të dobishme, por shpesh të anashkaluara, për përmirësimin e performancës me kubectl është përfundimi i komandës.

Përfundimi i komandës ju lejon të plotësoni automatikisht pjesë të komandave kubectl duke përdorur tastin Tab. Kjo funksionon për nënkomandat, opsionet dhe argumentet, duke përfshirë diçka aq komplekse sa emrat e burimeve.

Shihni se si funksionon kompletimi i komandës kubectl:

Përfundimi i komandës punon për predhat Bash dhe Zsh.

Udhëzues zyrtar përmban udhëzime të hollësishme për vendosjen e plotësimit automatik, por më poshtë do të ofrojmë një fragment të shkurtër.

Si funksionon kompletimi i komandës

Përfundimi i komandës është një veçori e guaskës që funksionon duke përdorur një skript përfundimi. Një skrip shtesë është një skrip shell që përcakton sjelljen e një zgjerimi për një komandë specifike.

Kubectl gjeneron dhe nxjerr automatikisht skriptet shtesë për Bash dhe Zsh duke përdorur komandat e mëposhtme:

$ kubectl completion bash

ose:

$ kubectl completion zsh

Në teori, mjafton të lidhni daljen e këtyre komandave me guaskën e duhur të komandës në mënyrë që kubectl të mund të plotësojë komandat.

Në praktikë, metoda e lidhjes është e ndryshme për Bash (përfshirë ndryshimet midis Linux dhe MacOS) dhe Zsh. Më poshtë do t'i shikojmë të gjitha këto opsione.

Bash në Linux

Skripti i përfundimit të Bash varet nga paketa e plotësimit të bash-it, kështu që duhet ta instaloni fillimisht:

$ sudo apt-get install bash-completion

ose:

$ yum install bash-completion

Ju mund të provoni që paketa të jetë instaluar me sukses duke përdorur komandën e mëposhtme:

$ type _init_completion

Nëse kjo nxjerr kodin e funksionit të guaskës, atëherë bash-completion është instaluar saktë. Nëse komanda jep një gabim "Nuk u gjet", duhet të shtoni rreshtin e mëposhtëm në skedarin tuaj ~ / .bashrc:

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

A është e nevojshme të shtoni këtë rresht në skedar ~ / .bashrc ose jo varet nga menaxheri i paketave që keni përdorur për të instaluar bash-completion. Kjo është e nevojshme për APT, por jo për YUM.

Pas instalimit të bash-completion, duhet të konfiguroni gjithçka në mënyrë që skripti i përfundimit kubectl të aktivizohet në të gjitha sesionet e shell.

Një mënyrë për ta bërë këtë është të shtoni rreshtin e mëposhtëm në skedar ~ / .bashrc:

source <(kubectl completion bash)

Një mënyrë tjetër është të shtoni skriptin shtesë kubectl në drejtori /etc/bash_completion.d (krijojeni nëse nuk ekziston):

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

Të gjitha skriptet shtesë në katalog /etc/bash_completion.d përfshihen automatikisht në bash-completion.

Të dyja opsionet janë njëlloj të zbatueshme.

Pas rinisjes së guaskës, kompletimi i komandës kubectl do të funksionojë.

Bash në MacOS

Në MacOS konfigurimi është pak më i komplikuar. Fakti është se si parazgjedhje, MacOS përdor versionin Bash 3.2 dhe skripti i plotësimit automatik kubectl kërkon një version Bash të paktën 4.1 dhe nuk funksionon në Bash 3.2.

Ka probleme licencimi që lidhen me përdorimin e një versioni të vjetëruar të Bash në MacOS. Versioni 4 i Bash është i licencuar sipas GPLv3, i cili nuk mbështetet nga Apple.

Për të konfiguruar plotësimin automatik të kubectl në MacOS, duhet të instaloni një version më të fundit të Bash. Ju gjithashtu mund të vendosni Bash-in e përditësuar si predhën tuaj të paracaktuar, gjë që do t'ju kursejë shumë probleme në të ardhmen. Nuk është e vështirë, detajet janë dhënë në artikull "Po përditëson Bash në MacOS'.

Përpara se të vazhdoni, sigurohuni që po përdorni një version të fundit të Bash (kontrolloni daljen bash --version).

Skripti i përfundimit të Bash ndryshon sipas projektit bash-përfundim, kështu që duhet ta instaloni së pari.

Mund të instaloni bash-completion duke përdorur Homebrew:

$ brew install bash-completion@2

Këtu @2 do të thotë bash-completion version 2. Përfundimi automatik i kubectl kërkon bash-completion v2 dhe bash-completion v2 kërkon një minimum prej Bash version 4.1.

Prodhimi i komandës brew-install përmban një seksion Caveats, i cili specifikon se çfarë duhet të shtohet në skedar ~/.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"

Megjithatë, unë rekomandoj që të mos i shtoni këto rreshta ~/.bash_profiledhe në ~/.bashrc. Në këtë rast, plotësimi automatik do të jetë i disponueshëm jo vetëm në predhat kryesore, por edhe në predhat e komandës së fëmijëve.

Pas rinisjes së guaskës së komandës, mund të verifikoni se instalimi është i saktë duke përdorur komandën e mëposhtme:

$ type _init_completion

Nëse shihni një funksion shell në dalje, atëherë gjithçka është konfiguruar saktë.

Tani duhet të sigurohemi që plotësimi automatik i kubectl është i aktivizuar në të gjitha seancat.

Një mënyrë është të shtoni rreshtin e mëposhtëm në tuaj ~/.bashrc:

source <(kubectl completion bash)

Mënyra e dytë është të shtoni një skrip të plotësimit automatik në dosje /usr/local/etc/bash_completion.d:

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

Kjo metodë do të funksionojë vetëm nëse keni instaluar bash-completion duke përdorur Homebrew. Në këtë rast, bash-completion ngarkon të gjitha skriptet nga kjo direktori.

Nëse keni instaluar kubectl duke përdorur Homebrew, atëherë nuk ka nevojë të kryeni hapin e mëparshëm, pasi skripti i plotësimit automatik do të vendoset automatikisht në dosje /usr/local/etc/bash_completion.d gjatë instalimit. Në këtë rast, plotësimi automatik i kubectl do të fillojë të funksionojë sapo të instaloni bash-completion.

Si rezultat, të gjitha këto opsione janë ekuivalente.

zsh

Skriptet e plotësimit automatik për Zsh nuk kërkojnë ndonjë varësi. E tëra çfarë ju duhet të bëni është t'i aktivizoni ato kur të ngarkoni guaskën e komandës.

Ju mund ta bëni këtë duke shtuar një rresht në tuaj ~/.zshrc dosje:

source <(kubectl completion zsh)

Nëse merrni një gabim not found: compdef pasi të rindizni guaskën tuaj, duhet të aktivizoni funksionin e integruar compdef. Mund ta aktivizoni duke e shtuar në fillim të skedarit tuaj ~/.zshrc sa vijon:

autoload -Uz compinit
compinit

2. Shikoni shpejt specifikimet e burimeve

Kur krijoni përkufizime të burimeve YAML, duhet të dini fushat dhe kuptimin e tyre për ato burime. Një vend për të kërkuar këtë informacion është në referencën API, e cila përmban specifikime të plota për të gjitha burimet.

Sidoqoftë, kalimi në shfletuesin e internetit sa herë që duhet të kërkoni për diçka është i papërshtatshëm. Prandaj kubectl ofron komandën kubectl explain, i cili tregon specifikimet e të gjitha burimeve pikërisht në terminalin tuaj.

Formati i komandës është si më poshtë:

$ kubectl explain resource[.field]...

Komanda do të nxjerrë specifikimin e burimit ose fushës së kërkuar. Informacioni i shfaqur është identik me atë që përmban manuali API.

By default kubectl explain tregon vetëm nivelin e parë të foleve të fushave.

Shihni se si duket Ju pastaj mund të.

Ju mund të shfaqni të gjithë pemën nëse shtoni opsionin --recursive:

$ kubectl explain deployment.spec --recursive

Nëse nuk e dini saktësisht se cilat burime nevojiten, mund t'i shfaqni të gjitha me komandën e mëposhtme:

$ kubectl api-resources

Kjo komandë shfaq emrat e burimeve në formë shumësi, p.sh. deployments në vend të deployment. Ai gjithashtu shfaq emrin e shkurtër, për shembull deploy, për ato burime që e kanë atë. Mos u shqetësoni për këto dallime. Të gjitha këto opsione emërtimi janë ekuivalente për kubectl. Kjo është, ju mund të përdorni ndonjë prej tyre për kubectl explain.

Të gjitha komandat e mëposhtme janë ekuivalente:

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

3. Përdorni një format të prodhimit të kolonës me porosi

Formati i parazgjedhur i daljes së komandës 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

Ky format është i përshtatshëm, por përmban një sasi të kufizuar informacioni. Krahasuar me formatin e plotë të përkufizimit të burimit, këtu shfaqen vetëm disa fusha.

Në këtë rast, mund të përdorni një format të prodhimit të kolonës me porosi. Kjo ju lejon të përcaktoni se çfarë të dhënash të nxirrni. Ju mund të shfaqni çdo fushë burimi si një kolonë të veçantë.

Përdorimi i një formati të personalizuar përcaktohet duke përdorur opsionet:

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

Ju mund të përcaktoni çdo kolonë dalëse si një çift <header>:<jsonpath>Ku <header> është emri i kolonës, dhe <jsonpath> - një shprehje që përcakton një fushë burimi.

Le të shohim një shembull të thjeshtë:

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

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

Prodhimi përmban një kolonë me emrat e pods.

Shprehja e opsionit zgjedh emrat e pod nga fusha metadata.name. Kjo është për shkak se emri i pod është përcaktuar në fushën e emrit të fëmijës metadata në përshkrimin e burimit të pod. Më shumë detaje mund të gjenden në Udhëzues API ose shkruani komandën kubectl explain pod.metadata.name.

Tani le të themi se dëshironi të shtoni një kolonë shtesë në dalje, për shembull duke treguar nyjen ku çdo pod po funksionon. Për ta bërë këtë, thjesht mund të shtoni specifikimin e duhur të kolonës në opsionin e kolonave me porosi:

$ 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

Shprehja zgjedh emrin e nyjës nga spec.nodeName — kur një pod i caktohet një nyje, emri i saj shkruhet në fushë spec.nodeName specifikimi i burimit të pod. Informacion më të detajuar mund të gjendet në dalje kubectl explain pod.spec.nodeName.

Ju lutemi vini re se fushat e burimeve të Kubernetes janë të ndjeshme ndaj shkronjave të vogla.

Ju mund të shikoni çdo fushë burimi si një kolonë. Thjesht rishikoni specifikimin e burimit dhe provojeni me çdo fushë që ju pëlqen.

Por së pari, le të hedhim një vështrim më të afërt në shprehjet e përzgjedhjes së fushës.

Shprehjet JSONPath

Shprehjet për zgjedhjen e fushave të burimeve bazohen në JSONPath.

JSONPath është një gjuhë për marrjen e të dhënave nga dokumentet JSON. Zgjedhja e një fushe të vetme është rasti më i thjeshtë i përdorimit për JSONPath. Ai ka shumë më shumë mundësi, duke përfshirë përzgjedhësit, filtrat dhe kështu me radhë.

Shpjegimi i Kubectl mbështet një numër të kufizuar veçorish JSONPath. Mundësitë dhe shembujt e përdorimit të tyre janë përshkruar më poshtë:

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

Operatori [] është veçanërisht i rëndësishëm. Shumë fusha burimesh Kubernetes janë lista dhe ky operator ju lejon të zgjidhni anëtarët e atyre listave. Përdoret shpesh me një gërmë si [*] për të zgjedhur të gjithë elementët e një liste.

Shembuj aplikimi

Mundësitë për përdorimin e një formati të prodhimit të kolonës me porosi janë të pafundme, pasi mund të shfaqni çdo fushë ose kombinim të fushave të burimeve në dalje. Këtu janë disa aplikacione shembull, por mos ngurroni t'i eksploroni vetë dhe të gjeni aplikacione që funksionojnë për ju.

Shfaqja e imazheve të kontejnerëve për pods:

$ 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

Kjo komandë shfaq emrat e imazheve të kontejnerit për çdo pod.

Mos harroni se një pod mund të përmbajë disa kontejnerë, atëherë emrat e imazheve do të shfaqen në një rresht, të ndarë me presje.

Shfaqja e zonave të disponueshmërisë së nyjeve:
```
$ 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
```
Kjo komandë është e dobishme nëse grupi juaj është i pritur në një re publike. Ai shfaq zonën e disponueshmërisë për secilën nyje.

Zona e disponueshmërisë është një koncept cloud që kufizon zonën e përsëritjes në një rajon gjeografik.

Zonat e disponueshmërisë për secilën nyje merren përmes një etikete të veçantë - failure-domain.beta.kubernetes.io/zone. Nëse grupi funksionon në një re publike, kjo etiketë krijohet automatikisht dhe plotësohet me emrat e zonave të disponueshmërisë për secilën nyje.

Etiketat nuk janë pjesë e specifikimit të burimeve të Kubernetes, kështu që nuk do të gjeni informacione rreth tyre Udhëzues API. Sidoqoftë, ato mund të shihen (si çdo etiketë tjetër) nëse kërkoni informacione për nyjet në formatin YAML ose JSON:
```
$ kubectl get nodes -o yaml
# или
$ kubectl get nodes -o json
```
Kjo është një mënyrë e shkëlqyer për të mësuar më shumë rreth burimeve, përveç të mësuarit të specifikimeve të burimeve.

4. Kaloni me lehtësi midis grupimeve dhe hapësirave të emrave

Kur kubectl bën një kërkesë në Kubernetes API, ai fillimisht lexon skedarin kubeconfig për të marrë të gjithë parametrat e nevojshëm për lidhjen.

Si parazgjedhje skedari kubeconfig është ~/.kube/config. Zakonisht ky skedar krijohet ose përditësohet nga një komandë e veçantë.

Kur punoni me grupe të shumta, skedari juaj kubeconfig përmban cilësime për t'u lidhur me të gjitha ato grupe. Ju duhet një mënyrë për t'i treguar komandës kubectl me cilin grup po punoni.

Brenda një grupi, ju mund të krijoni hapësira të shumta emrash - një lloj grupi virtual brenda një grupi fizik. Kubectl gjithashtu përcakton se cilën hapësirë emri të përdoret bazuar në skedarin kubeconfig. Kjo do të thotë se ju duhet gjithashtu një mënyrë për t'i treguar komandës kubectl se me cilën hapësirë emri të punoni.

Në këtë kapitull do të shpjegojmë se si funksionon dhe si ta bëjmë atë të funksionojë në mënyrë efektive.

Vini re se mund të keni disa skedarë kubeconfig të listuar në variablin e mjedisit KUBECONFIG. Në këtë rast, të gjithë këta skedarë do të kombinohen në një konfigurim të përbashkët në kohën e ekzekutimit. Ju gjithashtu mund të ndryshoni skedarin e paracaktuar kubeconfig duke ekzekutuar kubectl me parametrin --kubeconfig. Shikoni dokumentacion zyrtar.

skedarët kubeconfig

Le të shohim se çfarë përmban saktësisht skedari kubeconfig:

Siç mund ta shihni, skedari kubeconfig përmban një grup kontekstesh. Konteksti përbëhet nga tre elementë:

Cluster - URL API e serverit të grupit.
Kredencialet e vërtetimit të përdoruesit - përdoruesit në grup.
Hapësira e emrave - hapësira e emrave që përdoret kur bashkohet grupi.

Në praktikë, ata shpesh përdorin një kontekst për grup në kubeconfig. Sidoqoftë, mund të keni shumë kontekste për grup, të diferencuara sipas përdoruesit ose hapësirës së emrave. Megjithatë, ky konfigurim me shumë kontekste është i pazakontë, kështu që zakonisht ekziston një hartë një-për-një midis grupimeve dhe konteksteve.

Në çdo kohë, një nga kontekstet është aktual:

Kur kubectl lexon një skedar konfigurimi, ai gjithmonë merr informacion nga konteksti aktual. Në shembullin e mësipërm, kubectl do të lidhet me grupin Hare.

Prandaj, për të kaluar në një grup tjetër, duhet të ndryshoni kontekstin aktual në skedarin kubeconfig:

Tani kubectl do të lidhet me grupin Fox.

Për të kaluar në një hapësirë tjetër emri në të njëjtin grup, duhet të ndryshoni vlerën e elementit të hapësirës së emrave për kontekstin aktual:

Në shembullin e mësipërm, kubectl do të përdorë hapësirën e emrave Prod të grupit Fox (më parë ishte vendosur hapësira e emrave Test).

Vini re se kubectl gjithashtu ofron opsione --cluster, --user, --namespace и --context, të cilat ju lejojnë të mbishkruani elemente individuale dhe vetë kontekstin aktual, pavarësisht se çfarë është vendosur në kubeconfig. Shikoni kubectl options.

Në teori, ju mund të ndryshoni manualisht cilësimet në kubeconfig. Por është e papërshtatshme. Për të thjeshtuar këto operacione, ekzistojnë mjete të ndryshme që ju lejojnë të ndryshoni parametrat automatikisht.

Përdorni kubectx

Një mjet shumë i njohur për kalimin midis grupimeve dhe hapësirave të emrave.

Programi ofron komanda kubectx и kubens për të ndryshuar përkatësisht kontekstin aktual dhe hapësirën e emrave.

Siç u përmend, ndryshimi i kontekstit aktual nënkupton ndryshimin e grupit nëse keni vetëm një kontekst për grup.

Këtu është një shembull i ekzekutimit të këtyre komandave:

Në thelb, këto komanda thjesht modifikojnë skedarin kubeconfig siç përshkruhet më sipër.

për të instaluar kubectx, ndiqni udhëzimet në Github.

Të dyja komandat mbështesin plotësimin automatik të emrave të kontekstit dhe hapësirës së emrave, gjë që eliminon nevojën për t'i shtypur plotësisht ato. Udhëzime për konfigurimin e plotësimit automatik këtu.

Një tjetër veçori e dobishme kubectx është modaliteti interaktiv. Punon në lidhje me shërbimin fzf, i cili duhet të instalohet veçmas. Instalimi i fzf mundëson automatikisht modalitetin interaktiv në kubectx. Në mënyrë interaktive, ju mund të zgjidhni kontekstin dhe hapësirën e emrit përmes ndërfaqes interaktive të kërkimit falas të ofruar nga fzf.

Përdorimi i pseudonimeve të guaskës

Ju nuk keni nevojë për mjete të veçanta për të ndryshuar kontekstin aktual dhe hapësirën e emrave sepse kubectl gjithashtu ofron komanda për këtë. Po, ekipi kubectl config ofron nënkomanda për redaktimin e skedarëve kubeconfig.

Këtu janë disa prej tyre:

kubectl config get-contexts: shfaq të gjitha kontekstet;
kubectl config current-context: merrni kontekstin aktual;
kubectl config use-context: ndryshimi i kontekstit aktual;
kubectl config set-context: Ndryshoni elementin e kontekstit.

Megjithatë, përdorimi i drejtpërdrejtë i këtyre komandave nuk është shumë i përshtatshëm, sepse ato janë të gjata. Ju mund të bëni pseudonime të predhave për to që janë të lehta për t'u ekzekutuar.

Unë krijova një grup pseudonimesh bazuar në këto komanda që ofrojnë funksionalitet të ngjashëm me kubectx. Këtu mund t'i shihni ato në veprim:

Vini re se pseudonimet përdorin fzf për të ofruar një ndërfaqe interaktive kërkimi falas (si modaliteti ndërveprues i kubectx). Kjo do të thotë që keni nevojë instaloni fzfpër të përdorur këto pseudonime.

Këtu janë vetë përkufizimet e pseudonimeve:

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

Për të vendosur këto pseudonime, duhet të shtoni përkufizimet e mësipërme në skedarin tuaj ~/.bashrc ose ~/.zshrc dhe rindizni guaskën tuaj.

Përdorimi i shtojcave

Kubectl ju lejon të ngarkoni shtojcat që ekzekutohen në të njëjtën mënyrë si komandat bazë. Për shembull, mund të instaloni shtojcën kubectl-foo dhe ta ekzekutoni atë duke ekzekutuar komandën kubectl foo.

Do të ishte e përshtatshme për të ndryshuar kontekstin dhe hapësirën e emrave në këtë mënyrë, për shembull duke ekzekutuar kubectl ctx për të ndryshuar kontekstin dhe kubectl ns për të ndryshuar hapësirën e emrave.

Unë kam shkruar dy shtojca që e bëjnë këtë:

Puna e shtojcave bazohet në pseudonimet nga seksioni i mëparshëm.

Ja se si funksionojnë:

Vini re se shtojcat përdorin fzf për të ofruar një ndërfaqe interaktive kërkimi falas (si modaliteti ndërveprues i kubectx). Kjo do të thotë që keni nevojë instaloni fzfpër të përdorur këto pseudonime.

Për të instaluar shtojcat, duhet të shkarkoni skriptet e guaskës me emër kubectl-ctx и kubectl-ns në çdo direktori në variablin tuaj PATH dhe bëjini ato të ekzekutueshme me p.sh. chmod +x. Menjëherë pas kësaj do të mund të përdorni kubectl ctx и kubectl ns.

5. Zvogëloni hyrjen me autoaliase

Pseudonimet e shell janë një mënyrë e mirë për të shpejtuar hyrjen. Projekti kubectl-aliases përmban rreth 800 shkurtore për komandat bazë të kubectl.

Ju mund të pyesni veten - si i mbani mend 800 pseudonime? Por nuk keni nevojë t'i mbani mend të gjitha, sepse ato janë ndërtuar sipas një skeme të thjeshtë, e cila është dhënë më poshtë:

Për shembull:

kgpooyaml - kubectl marr pods oyaml
ksysgsvcw — kubectl -n kube-system merrni svc w
ksysrmcm -kubectl -n kube-sistem rm cm
kgdepallsl - kubectl merrni vendosjen e të gjitha sl

Siç mund ta shihni, pseudonimet përbëhen nga komponentë, secili prej të cilëve përfaqëson një element specifik të komandës kubectl. Çdo pseudonim mund të ketë një komponent për komandën bazë, funksionimin dhe burimin, dhe komponentë të shumtë për parametrat. Ju thjesht "populloni" këta përbërës nga e majta në të djathtë sipas diagramit të mësipërm.

Diagrami aktual i detajuar është në GitHub. Aty mund të gjeni edhe lista e plotë e pseudonimeve.

Për shembull, pseudonimi kgpooyamlall është ekuivalent me komandën kubectl get pods -o yaml --all-namespaces.

Rendi relativ i opsioneve nuk është i rëndësishëm: komanda kgpooyamlall është ekuivalente me komandën kgpoalloyaml.

Ju nuk keni nevojë të përdorni të gjithë komponentët si pseudonime. Për shembull k, kg, klo, ksys, kgpo mund të përdoret gjithashtu. Për më tepër, ju mund të kombinoni pseudonimet dhe komandat ose opsionet e rregullta në vijën e komandës:

Për shembull:

Në vend të kubectl proxy ti mund te shkruash k proxy.
Në vend të kubectl get roles ti mund te shkruash kg roles (aktualisht nuk ka pseudonim për burimin Roles).
Për të marrë të dhëna për një pod specifik, mund të përdorni komandën kgpo my-pod — kubectl get pod my-pod.

Ju lutemi vini re se disa pseudonime kërkojnë një argument të linjës së komandës. Për shembull, pseudonimi kgpol mjete kubectl get pods -l. Opsioni -l kërkon një argument - një specifikim etiketë. Nëse përdorni një pseudonim, do të duket kështu kgpol app=ui.

Për shkak se disa pseudonime kërkojnë argumente, pseudonimet a, f dhe l duhet të përdoren të fundit.

Në përgjithësi, pasi të keni marrë parasysh këtë skemë, mund të nxirrni në mënyrë intuitive pseudonime nga komandat që dëshironi të ekzekutoni dhe të kurseni shumë kohë për të shkruar.

instalim

Për të instaluar kubectl-aliases, duhet të shkarkoni skedarin .kubectl_aliases nga GitHub dhe përfshijeni atë në skedar ~/.bashrc ose ~/.zshrc:

source ~/.kubectl_aliases

Përfundim automatik

Siç thamë më parë, shpesh shtoni fjalë shtesë në një pseudonim në vijën e komandës. Për shembull:

$ kgpooyaml test-pod-d4b77b989

Nëse përdorni kompletimin e komandës kubectl, me siguri keni përdorur plotësimin automatik për gjëra të tilla si emrat e burimeve. Por a mund të bëhet kjo kur përdoren pseudonime?

Kjo është një pyetje shumë e rëndësishme sepse nëse plotësimi automatik nuk funksionon, do të humbni disa nga përfitimet e pseudonimeve.

Përgjigja varet nga cila guaskë po përdorni:

Për Zsh, plotësimi i pseudonimit funksionon jashtë kutisë.
Për Bash, për fat të keq, kërkohet pak punë për të funksionuar plotësimi automatik.

Aktivizimi i plotësimit automatik për pseudonimet në Bash

Problemi me Bash është se ai përpiqet të plotësojë (sa herë që shtypni Tab) pseudonimin, jo komandën që i referohet pseudonimi (siç bën Zsh, për shembull). Meqenëse nuk keni skriptet e përfundimit për të gjitha 800 pseudonimet, plotësimi automatik nuk funksionon.

Projekt plotë-alias jep një zgjidhje të përgjithshme për këtë problem. Ai lidhet me mekanizmin e plotësimit për pseudonimet, zgjeron nga brenda pseudonimin në një komandë dhe kthen opsionet e përfundimit për komandën e përfunduar. Kjo do të thotë që mbushja për një pseudonim sillet saktësisht njësoj si për një komandë të plotë.

Në vijim, fillimisht do të shpjegoj se si të instaloni alias-in e plotë dhe më pas si ta konfiguroni atë për të mundësuar kompletimin për të gjitha pseudonimet kubectl.

Instalimi i pseudonimit të plotë

Para së gjithash, alias-i i plotë varet nga bash-përfundim. Prandaj, përpara se të instaloni alias-in e plotë, duhet të siguroheni që është instaluar bash-completion. Udhëzimet e instalimit janë dhënë më parë për Linux dhe MacOS.

Shënim i rëndësishëm për përdoruesit e MacOS: Ashtu si skripti i plotësimit automatik kubectl, alias-i i plotë nuk funksionon me Bash 3.2, i cili është parazgjedhja në MacOS. Në veçanti, pseudonimi i plotë varet nga plotësimi bash v2 (brew install bash-completion@2), i cili kërkon të paktën Bash 4.1. Kjo do të thotë që për të përdorur pseudonimin e plotë në MacOS, duhet të instaloni një version më të ri të Bash.

Duhet të shkarkoni skriptin bash_plotësim.sh nga Depoja e GitHub dhe përfshijeni atë në dosjen tuaj ~/.bashrc:

source ~/bash_completion.sh

Pas rindezjes së guaskës, alias-i i plotë do të instalohet plotësisht.

Aktivizimi i plotësimit automatik për pseudonimet kubectl

Teknikisht i plotë - pseudonimi ofron një funksion mbështjellës _complete_alias. Ky funksion kontrollon pseudonimin dhe kthen sugjerime për përfundimin e komandës alias.

Për të lidhur një funksion me një pseudonim specifik, duhet të përdorni mekanizmin e integruar Bash përfunduar, për të instaluar _complete_alias si një funksion i plotësimit të pseudonimit.

Si shembull, le të marrim pseudonimin k, i cili qëndron për komandën kubectl. për të instaluar _complete_alias Si funksion plotësues për këtë pseudonim, duhet të ekzekutoni komandën e mëposhtme:

$ complete -F _complete_alias k

Rezultati i kësaj është se sa herë që plotësoni automatikisht një pseudonim k, funksioni thirret _complete_alias, i cili kontrollon pseudonimin dhe kthen sugjerime për përfundimin e komandës kubectl.

Si shembull i dytë, le të marrim pseudonimin kgqë tregon kubectl get:

$ complete -F _complete_alias kg

Ashtu si në shembullin e mëparshëm, kur plotësoni automatikisht kg, ju merrni të njëjtat sugjerime plotësimi që do të merrnit për kubectl get.

Vini re se mund të përdorni alias të plotë për çdo pseudonim në sistemin tuaj.

Prandaj, për të aktivizuar plotësimin automatik për të gjitha pseudonimet kubectl, duhet të ekzekutoni komandën e mësipërme për secilën prej tyre. Fragmenti i mëposhtëm e bën pikërisht këtë, me kusht që të keni vendosur pseudonime kubectl ~/.kubectl-aliases:

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

Kjo pjesë e kodit duhet të vendoset në tuaj ~/.bashrc, rinisni guaskën e komandës dhe plotësimi automatik do të bëhet i disponueshëm për të gjitha 800 pseudonimet kubectl.

6. Zgjerimi i kubectl me shtojca

Duke filluar nga versioni 1.12, kubectl mbështet mekanizmi i shtojcave, të cilat ju lejojnë të zgjeroni funksionet e tij me komanda shtesë.

Nëse jeni të njohur me Mekanizmat e shtojcave Git, atëherë shtojcat kubectl janë ndërtuar mbi të njëjtin parim.

Në këtë kapitull, ne do të trajtojmë se si të instaloni shtojcat, ku t'i gjeni ato dhe si të krijoni shtojcat tuaja.

Instalimi i shtojcave

Shtojcat Kubectl shpërndahen si skedarë të thjeshtë të ekzekutueshëm me emrin si kubectl-x. Parashtesa kubectl- kërkohet, e ndjekur nga një nënkomandë e re kubectl që ju lejon të telefononi shtojcën.

Për shembull, shtojca hello do të shpërndahet si një skedar i quajtur kubectl-hello.

Për të instaluar shtojcën, duhet të kopjoni skedarin kubectl-x në çdo drejtori në PATH tuaj dhe bëjeni atë të ekzekutueshëm, për shembull me chmod +x. Menjëherë pas kësaj ju mund të telefononi shtojcën me kubectl x.

Ju mund të përdorni komandën e mëposhtme për të renditur të gjitha shtojcat që janë instaluar aktualisht në sistemin tuaj:

$ kubectl plugin list

Kjo komandë do të shfaqë gjithashtu paralajmërime nëse keni shumë shtojca me të njëjtin emër, ose nëse ka një skedar shtojcash që nuk është i ekzekutueshëm.

Gjetja dhe instalimi i shtojcave duke përdorur Krew

Shtojcat Kubectl mund të ndahen ose të ripërdoren si paketat softuerike. Por ku mund të gjeni shtojca që të tjerët kanë ndarë?

Projekti Krew synon të sigurojë një zgjidhje të unifikuar për ndarjen, kërkimin, instalimin dhe menaxhimin e shtojcave kubectl. Projekti e quan veten një "menaxher paketash për shtojcat kubectl" (Krew është i ngjashëm me krijoj).

Krew është një listë e shtojcave kubectl që mund të zgjidhni dhe instaloni. Në të njëjtën kohë, Krew është gjithashtu një shtojcë për kubectl.

Kjo do të thotë që instalimi i Krew funksionon në thelb si instalimi i çdo shtojce tjetër kubectl. Ju mund të gjeni udhëzime të hollësishme në Faqja e GitHub.

Komandat më të rëndësishme të Krew janë:

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

Ju lutemi vini re se instalimi i shtojcave duke përdorur Krew nuk ndërhyn në instalimin e shtojcave duke përdorur metodën standarde të përshkruar më sipër.

Ju lutemi vini re se komanda kubectl krew list shfaq vetëm shtojcat që janë instaluar duke përdorur Krew, ndërsa komanda kubectl plugin list liston të gjitha shtojcat, domethënë ato të instaluara duke përdorur Krew dhe ato të instaluara me metoda të tjera.

Gjetja e shtojcave diku tjetër

Krew është një projekt i ri, aktualisht në të Lista vetëm rreth 30 shtojca. Nëse nuk mund të gjeni atë që ju nevojitet, mund të gjeni shtojca diku tjetër, si për shembull GitHub.

Unë rekomandoj të shikoni seksionin GitHub kubectl-plugins. Aty do të gjeni dhjetëra shtojca të disponueshme që ia vlen t'i shikoni.

Shkrimi i shtojcave tuaja

mundesh vete krijoni shtojca - Nuk është e vështirë. Ju duhet të krijoni një ekzekutues që bën atë që ju nevojitet, emërtojeni si kubectl-x dhe instaloni siç përshkruhet më sipër.

Skedari mund të jetë një skrip bash, një skrip python ose një aplikacion i përpiluar GO - nuk ka rëndësi. Kushti i vetëm është që ai të mund të ekzekutohet drejtpërdrejt në sistemin operativ.

Le të krijojmë një shembull shtojce tani. Në seksionin e mëparshëm, keni përdorur komandën kubectl për të renditur kontejnerët për çdo pod. Është e lehtë ta kthesh këtë komandë në një shtojcë që mund ta telefonosh me p.sh. kubectl img.

Krijo një skedar kubectl-img përmbajtjen e mëposhtme:

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

Tani bëjeni skedarin të ekzekutueshëm me chmod +x kubectl-img dhe zhvendoseni atë në çdo drejtori në PATH tuaj. Menjëherë pas kësaj ju mund të përdorni shtojcën kubectl img.

Siç u përmend, shtojcat kubectl mund të shkruhen në çdo gjuhë programimi ose skriptimi. Nëse jeni duke përdorur skriptet shell, avantazhi i të qenit në gjendje të telefononi lehtësisht kubectl nga brenda shtojcës. Sidoqoftë, mund të shkruani shtojca më komplekse në gjuhë të vërteta programimi duke përdorur Biblioteka e klientëve Kubernetes. Nëse jeni duke përdorur Go, mund ta përdorni gjithashtu biblioteka cli-runtime, i cili ekziston posaçërisht për të shkruar shtojca kubectl.

Si të ndani shtojcat tuaja

Nëse mendoni se shtojcat tuaja mund të jenë të dobishme për të tjerët, mos ngurroni ta ndani atë në GitHub. Sigurohuni t'i shtoni ato në temë kubectl-plugins.

Ju gjithashtu mund të kërkoni që shtojca juaj të shtohet Lista e Krew. Udhëzimet se si ta bëni këtë janë në Depot e GitHub.

Përfundimi i komandës

Pluginat aktualisht nuk mbështesin plotësimin automatik. Kjo do të thotë, duhet të vendosni emrin e plotë të shtojcës dhe emrat e plotë të argumenteve.

Depoja e GitHub kubectl për këtë funksion ka kërkesë e hapur. Pra, është e mundur që kjo veçori të zbatohet diku në të ardhmen.

Fat i mirë!

Çfarë tjetër për të lexuar në këtë temë:

Burimi: www.habr.com

Si të përdorni kubectl në mënyrë më efektive: një udhëzues i detajuar