🥇Kaip efektyviau naudoti kubectl: išsamus vadovas

Jei dirbate su Kubernetes, kubectl tikriausiai yra viena iš dažniausiai naudojamų paslaugų. Ir kai praleidžiate daug laiko dirbdami su tam tikru įrankiu, verta gerai jį išstudijuoti ir išmokti efektyviai juo naudotis.

Komanda Kubernetes aaS iš Mail.ru išvertė Danielio Weibelio straipsnį, kuriame rasite patarimų ir gudrybių, kaip efektyviai dirbti su kubectl. Tai taip pat padės jums giliau suprasti „Kubernetes“.

Pasak autoriaus, straipsnio tikslas – kasdienį darbą su Kubernetes paversti ne tik efektyvesniu, bet ir malonesniu!

Įvadas: Kas yra kubectl

Prieš išmokdami veiksmingiau naudoti kubectl, turite įgyti pagrindinį supratimą apie tai, kas tai yra ir kaip jis veikia.

Žvelgiant iš vartotojo perspektyvos, kubectl yra valdymo skydelis, leidžiantis atlikti Kubernetes operacijas.

Techniškai kalbant, kubectl yra Kubernetes API klientas.

Kubernetes API yra HTTP REST API. Ši API yra tikroji Kubernetes vartotojo sąsaja, per kurią ji visiškai valdoma. Tai reiškia, kad kiekviena „Kubernetes“ operacija rodoma kaip API galutinis taškas ir gali būti pateikta HTTP užklausa į tą galinį tašką.

Todėl pagrindinis kubectl darbas yra pateikti HTTP užklausas Kubernetes API:

„Kubernetes“ yra visiškai į išteklius orientuota sistema. Tai reiškia, kad ji palaiko vidinę išteklių būseną, o visos Kubernetes operacijos yra CRUD operacijos.

Valdydami šiuos išteklius galite visiškai valdyti „Kubernetes“, o „Kubernetes“ sugalvoja, ką daryti pagal esamą išteklių būklę. Dėl šios priežasties Kubernetes API nuoroda yra sutvarkyta kaip išteklių tipų sąrašas su susijusiomis operacijomis.

Pažiūrėkime į pavyzdį.

Tarkime, kad norite sukurti „ReplicaSet“ išteklius. Norėdami tai padaryti, apibūdinkite „ReplicaSet“ faile pavadinimu replicaset.yaml, tada paleiskite komandą:

$ kubectl create -f replicaset.yaml

Taip bus sukurtas „ReplicaSet“ šaltinis. Bet kas vyksta užkulisiuose?

„Kubernetes“ turi „ReplicaSet“ kūrimo operaciją. Kaip ir bet kuri kita operacija, ji rodoma kaip API galutinis taškas. Konkretus šios operacijos API galutinis taškas atrodo taip:

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

API galinius taškus visoms Kubernetes operacijoms galite rasti adresu API nuoroda (įskaitant aukščiau nurodytas galutinis taškas). Norėdami pateikti faktinę užklausą galutiniam taškui, pirmiausia turite pridėti API serverio URL prie galutinio taško kelių, išvardytų API nuorodoje.

Taigi, kai vykdote aukščiau pateiktą komandą, kubectl siunčia HTTP POST užklausą į aukščiau nurodytą API galinį tašką. ReplicaSet apibrėžimas, kurį pateikėte faile replicaset.yaml, siunčiamas prašymo tekste.

Taip kubectl veikia visoms komandoms, kurios sąveikauja su Kubernetes grupe. Visais šiais atvejais kubectl tiesiog pateikia HTTP užklausas į atitinkamus Kubernetes API galutinius taškus.

Atminkite, kad galite visiškai valdyti „Kubernetes“ naudodami tokią priemonę kaip curlrankiniu būdu siųsdami HTTP užklausas į Kubernetes API. Kubectl paprasčiausiai palengvina Kubernetes API naudojimą.

Tai yra pagrindai, kas yra kubectl ir kaip jis veikia. Tačiau yra dar kai kas apie Kubernetes API, kurį turėtų žinoti kiekvienas kubectl vartotojas. Greitai pažvelkime į vidinį Kubernetes pasaulį.

Vidinis Kubernetes pasaulis

„Kubernetes“ susideda iš nepriklausomų komponentų rinkinio, kurie veikia kaip atskiri procesai klasterio mazguose. Kai kurie komponentai veikia pagrindiniuose mazguose, kiti – darbiniuose mazguose, kiekvienas komponentas atlieka savo konkrečią užduotį.

Čia pateikiami svarbiausi pagrindinių mazgų komponentai:

Skliautas - saugo išteklių apibrėžimus (paprastai tai ir tt).
API serveris – teikia API ir tvarko saugyklą.
Valdiklio vadovas — Užtikrina, kad išteklių būsenos atitiktų specifikacijas.
Tvarkaraštis - suplanuoja ankštis darbuotojų mazguose.

Ir čia yra vienas iš svarbiausių darbuotojų mazgų komponentų:

kubelet - valdo konteinerių paleidimą darbiniame mazge.

Norėdami suprasti, kaip šie komponentai veikia kartu, pažvelkime į pavyzdį.

Tarkime, kad ką tik baigėte kubectl create -f replicaset.yaml, po kurio kubectl pateikė HTTP POST užklausą ReplicaSet API galutinis taškas (pradėjus ReplicaSet išteklių apibrėžimą).

Kas vyksta klasteryje?

Atlikę kubectl create -f replicaset.yaml API serveris saugo jūsų „ReplicaSet“ išteklių apibrėžimą saugykloje:
Tada valdiklio tvarkyklėje paleidžiamas „ReplicaSet“ valdiklis, kuris tvarko „ReplicaSet“ išteklių kūrimą, keitimą ir ištrynimą:
„ReplicaSet“ valdiklis sukuria kiekvienos „ReplicaSet“ kopijos pod apibrėžimą (pagal ReplicaSet apibrėžime pateiktą pod šabloną) ir išsaugo juos saugykloje:
Paleistas planuoklis, sekantis blokus, kurie dar nebuvo priskirti jokiam darbuotojo mazgui:
Planuoklis pasirenka tinkamą darbuotojo mazgą kiekvienam podeliui ir prideda šią informaciją prie grupės apibrėžimo parduotuvėje:
Darbuotojo mazge, kuriam priskirtas blokas, paleidžiamas „Kubelet“, jis seka šiam mazgui priskirtus blokus:
„Kubelet“ nuskaito talpyklos apibrėžimą iš saugyklos ir nurodo konteinerio vykdymo laikui, pvz., „Docker“, paleisti konteinerius mazge:

Žemiau pateikiama šio aprašymo tekstinė versija.

API užklausą į ReplicaSet kūrimo galutinį tašką apdoroja API serveris. API serveris autentifikuoja užklausą ir išsaugo ReplicaSet išteklių apibrėžimą saugykloje.

Šis įvykis paleidžia „ReplicaSet“ valdiklį, kuris yra valdiklio tvarkyklės antrinis procesas. „ReplicaSet“ valdiklis stebi „ReplicaSet“ išteklių kūrimą, atnaujinimą ir ištrynimą parduotuvėje ir gauna pranešimą apie įvykį, kai tai įvyksta.

„ReplicaSet“ valdiklio užduotis yra užtikrinti, kad būtų reikiamas „ReplicaSet“ blokų skaičius. Mūsų pavyzdyje dar nėra anketų, todėl ReplicaSet valdiklis sukuria šiuos pod apibrėžimus (pagal ReplicaSet apibrėžime pateiktą pod šabloną) ir išsaugo juos saugykloje.

Naujų grupių kūrimą suaktyvina planavimo priemonė, kuri seka grupės apibrėžimus, kurie dar nesuplanuoti darbuotojo mazguose. Planuoklis pasirenka tinkamą darbuotojo mazgą kiekvienam podeliui ir atnaujina pod apibrėžimus saugykloje.

Atminkite, kad iki šio taško joks darbo krūvio kodas neveikė niekur klasteryje. Viskas, kas buvo padaryta iki šiol - tai yra išteklių kūrimas ir atnaujinimas pagrindinio mazgo saugykloje.

Paskutinis įvykis suaktyvina „Kubelets“, kurie stebi jų darbuotojų mazguose suplanuotus blokus. Darbuotojo mazgo, kuriame įdiegtos jūsų „ReplicaSet“ grupės, Kubeletas turi nurodyti konteinerio vykdymo laikui, pvz., „Docker“, atsisiųsti reikiamus sudėtinio rodinio vaizdus ir juos paleisti.

Šiuo metu jūsų programa „ReplicaSet“ pagaliau veikia!

Kubernetes API vaidmuo

Kaip matėte ankstesniame pavyzdyje, Kubernetes komponentai (išskyrus API serverį ir saugyklą) stebi saugykloje esančių išteklių pakeitimus ir keičia informaciją apie saugykloje esančius išteklius.

Žinoma, šie komponentai tiesiogiai sąveikauja su saugykla, o tik per Kubernetes API.

Apsvarstykite šiuos pavyzdžius:

ReplicaSet valdiklis naudoja API galinį tašką sąrašą „ReplicaSets“. su parametru watch stebėti „ReplicaSet“ išteklių pakeitimus.
ReplicaSet valdiklis naudoja API galinį tašką sukurti Pod (sukurti ankštį), kad sukurtumėte ankštis.
Planuoklis naudoja API galinį tašką pataiso ankštis (redaguoti grupę), kad atnaujintumėte rinkinius su informacija apie pasirinktą darbuotojo mazgą.

Kaip matote, tai yra ta pati API, kurią pasiekia kubectl. Tos pačios API naudojimas vidiniams komponentams ir išoriniams vartotojams yra pagrindinė Kubernetes dizaino koncepcija.

Dabar galime apibendrinti, kaip veikia Kubernetes:

Saugojimo parduotuvėse nurodomi, tai yra, Kubernetes ištekliai.
API serveris suteikia sąsają su saugykla Kubernetes API forma.
Visi kiti Kubernetes komponentai ir vartotojai skaito, stebi ir manipuliuoja Kubernetes būsena (ištekliais) per API.

Šių sąvokų žinojimas padės geriau suprasti kubectl ir išnaudoti visas jo galimybes.

Dabar pažvelkime į keletą konkrečių patarimų ir gudrybių, kurie padės pagerinti jūsų produktyvumą naudojant kubectl.

1. Paspartinkite įvestį naudodami komandų užbaigimą

Vienas iš naudingiausių, bet dažnai nepastebimų būdų, kaip pagerinti našumą naudojant kubectl, yra komandų užbaigimas.

Komandų užbaigimas leidžia automatiškai užbaigti kubectl komandų dalis naudojant klavišą Tab. Tai tinka antrinėms komandoms, parinktims ir argumentams, įskaitant tokius sudėtingus dalykus kaip išteklių pavadinimai.

Sužinokite, kaip veikia kubectl komandos užbaigimas:

Bash ir Zsh apvalkalų komandų užbaigimo darbai.

Oficialus vadovas yra išsamios instrukcijos, kaip nustatyti automatinį užbaigimą, tačiau toliau pateiksime trumpą ištrauką.

Kaip veikia komandų užbaigimas

Komandos užbaigimas yra apvalkalo funkcija, kuri veikia naudojant užbaigimo scenarijų. Plėtinio scenarijus yra apvalkalo scenarijus, apibrėžiantis konkrečios komandos plėtinio elgesį.

Kubectl automatiškai generuoja ir išveda Bash ir Zsh plėtinių scenarijus naudodamas šias komandas:

$ kubectl completion bash

Или:

$ kubectl completion zsh

Teoriškai pakanka šių komandų išvestį prijungti prie atitinkamo komandų apvalkalo, kad kubectl galėtų papildyti komandas.

Praktiškai Bash (įskaitant skirtumus tarp Linux ir MacOS) ir Zsh ryšio metodas skiriasi. Žemiau apžvelgsime visas šias parinktis.

Bash ant Linux

„Bash“ užbaigimo scenarijus priklauso nuo „bash-completion“ paketo, todėl pirmiausia turite jį įdiegti:

$ sudo apt-get install bash-completion

Или:

$ yum install bash-completion

Galite patikrinti, ar paketas sėkmingai įdiegtas, naudodami šią komandą:

$ type _init_completion

Jei tai išveda apvalkalo funkcijos kodą, tada bash-completion įdiegta teisingai. Jei komanda pateikia klaidą „Nerasta“, prie failo turite pridėti šią eilutę ~ / .bashrc:

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

Ar būtina šią eilutę įtraukti į failą ~ / .bashrc ar ne, priklauso nuo paketų tvarkyklės, kurią naudojote įdiegdami bash-completion. Tai būtina APT, bet ne YUM.

Įdiegę bash-completion, turite viską sukonfigūruoti taip, kad kubectl užbaigimo scenarijus būtų įjungtas visose apvalkalo sesijose.

Vienas iš būdų tai padaryti – prie failo pridėti šią eilutę ~ / .bashrc:

source <(kubectl completion bash)

Kitas būdas yra pridėti kubectl plėtinio scenarijų į katalogą /etc/bash_completion.d (sukurkite, jei jo nėra):

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

Visi priedų scenarijai kataloge /etc/bash_completion.d automatiškai įtraukiami į bash užbaigimą.

Abi parinktys vienodai taikomos.

Iš naujo paleidus apvalkalą, veiks kubectl komandos užbaigimas.

Bash „MacOS“.

„MacOS“ sąranka yra šiek tiek sudėtingesnė. Faktas yra tas, kad pagal numatytuosius nustatymus „MacOS“ naudoja „Bash“ 3.2 versiją, o „kubectl“ automatinio užbaigimo scenarijui reikalinga bent 4.1 „Bash“ versija ir jis neveikia „Bash 3.2“.

Yra licencijavimo problemų, susijusių su pasenusios „Bash“ versijos naudojimu „MacOS“. „Bash“ 4 versija yra licencijuota pagal GPLv3, kurios „Apple“ nepalaiko.

Norėdami sukonfigūruoti kubectl automatinį užbaigimą „MacOS“, turite įdiegti naujesnę „Bash“ versiją. Taip pat galite nustatyti atnaujintą „Bash“ kaip numatytąjį apvalkalą, todėl ateityje išvengsite daug problemų. Tai nėra sunku, išsami informacija pateikta straipsnyje "„Bash“ atnaujinimas „MacOS“.".

Prieš tęsdami įsitikinkite, kad naudojate naujausią „Bash“ versiją (patikrinkite išvestį bash --version).

„Bash“ užbaigimo scenarijus skiriasi priklausomai nuo projekto bash-užbaigimas, todėl pirmiausia turite jį įdiegti.

Galite įdiegti „bash-completion“ naudodami Namųburnas:

$ brew install bash-completion@2

Čia @2 reiškia bash-completion 2 versiją. kubectl automatiniam užbaigimui reikalingas bash-completion v2, o bash-completion v2 reikalauja mažiausiai 4.1 Bash versijos.

Komandos išvestis brew-install yra įspėjimų skyrius, kuriame nurodoma, ką reikia pridėti prie failo ~/.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"

Tačiau aš rekomenduoju nepridėti šių eilučių ~/.bash_profileIr ~/.bashrc. Tokiu atveju automatinis užbaigimas bus prieinamas ne tik pagrindinėse, bet ir antrinėse komandose.

Iš naujo paleidę komandų apvalkalą, galite patikrinti, ar diegimas teisingas, naudodami šią komandą:

$ type _init_completion

Jei išvestyje matote apvalkalo funkciją, tada viskas sukonfigūruota teisingai.

Dabar turime užtikrinti, kad kubectl automatinis užbaigimas būtų įjungtas visuose seansuose.

Vienas iš būdų yra pridėti šią eilutę prie savo ~/.bashrc:

source <(kubectl completion bash)

Antrasis būdas yra pridėti automatinio užbaigimo scenarijų į aplanką /usr/local/etc/bash_completion.d:

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

Šis metodas veiks tik tuo atveju, jei įdiegėte „bash-completion“ naudodami „Homebrew“. Šiuo atveju bash-completion įkelia visus scenarijus iš šio katalogo.

Jei įdiegėte kubectl naudojant Homebrew, tada nereikia atlikti ankstesnio veiksmo, nes automatinio užbaigimo scenarijus bus automatiškai patalpintas į aplanką /usr/local/etc/bash_completion.d montavimo metu. Tokiu atveju kubectl automatinis užbaigimas pradės veikti iškart, kai tik įdiegsite bash-completion.

Dėl to visos šios parinktys yra lygiavertės.

Zsh

„Zsh“ automatinio užbaigimo scenarijus nereikalauja jokių priklausomybių. Viskas, ką jums reikia padaryti, tai įjungti juos, kai įkeliate komandų apvalkalą.

Tai galite padaryti pridėdami eilutę prie savo ~/.zshrc failas:

source <(kubectl completion zsh)

Jei gausite klaidą not found: compdef iš naujo paleidę apvalkalą, turite įjungti įmontuotą funkciją compdef. Galite jį įjungti pridėdami jį prie failo pradžios ~/.zshrc taip:

autoload -Uz compinit
compinit

2. Greitai peržiūrėkite išteklių specifikacijas

Kai kuriate YAML išteklių apibrėžimus, turite žinoti laukus ir jų reikšmę tiems ištekliams. Viena vieta, kur galima ieškoti šios informacijos, yra API nuoroda, kurioje yra išsamios visų išteklių specifikacijos.

Tačiau perjungti į interneto naršyklę kiekvieną kartą, kai reikia ko nors ieškoti, yra nepatogu. Todėl kubectl pateikia komandą kubectl explain, kuriame rodomos visų išteklių specifikacijos jūsų terminale.

Komandos formatas yra toks:

$ kubectl explain resource[.field]...

Komanda išves prašomo šaltinio arba lauko specifikaciją. Rodoma informacija yra tokia pati kaip API vadove.

Pagal nutylėjimą kubectl explain rodo tik pirmąjį laukų lizdo lygį.

Pažiūrėkite, kaip tai atrodo Tada galite.

Pridėję parinktį galite rodyti visą medį --recursive:

$ kubectl explain deployment.spec --recursive

Jei tiksliai nežinote, kokių išteklių reikia, galite juos visus parodyti naudodami šią komandą:

$ kubectl api-resources

Ši komanda rodo išteklių pavadinimus daugiskaitos forma, pvz. deployments vietoj deployment. Taip pat rodomas, pavyzdžiui, trumpasis pavadinimas deploy, tiems ištekliams, kurie jį turi. Nesijaudinkite dėl šių skirtumų. Visos šios pavadinimo parinktys yra lygiavertės kubectl. Tai yra, galite naudoti bet kurį iš jų kubectl explain.

Visos šios komandos yra lygiavertės:

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

3. Naudokite pasirinktinį stulpelio išvesties formatą

Numatytasis komandos išvesties formatas 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

Šis formatas yra patogus, tačiau jame yra ribotas informacijos kiekis. Palyginti su visu išteklių apibrėžimo formatu, čia rodomi tik keli laukai.

Tokiu atveju galite naudoti pasirinktinį stulpelio išvesties formatą. Tai leidžia nustatyti, kokius duomenis išvesti. Galite rodyti bet kurį išteklių lauką kaip atskirą stulpelį.

Pasirinktinio formato naudojimas nustatomas naudojant parinktis:

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

Kiekvieną išvesties stulpelį galite apibrėžti kaip porą <header>:<jsonpath>Kur <header> yra stulpelio pavadinimas ir <jsonpath> — išraiška, apibrėžianti išteklių lauką.

Pažvelkime į paprastą pavyzdį:

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

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

Išvestyje yra vienas stulpelis su ankščių pavadinimais.

Parinkties išraiška iš lauko parenka pogrupių pavadinimus metadata.name. Taip yra todėl, kad grupės pavadinimas yra apibrėžtas antrinio pavadinimo lauke metadata ankšties šaltinio aprašyme. Daugiau informacijos galite rasti API vadovas arba įveskite komandą kubectl explain pod.metadata.name.

Dabar tarkime, kad norite pridėti papildomą stulpelį prie išvesties, pavyzdžiui, parodyti mazgą, kuriame veikia kiekvienas podas. Norėdami tai padaryti, galite tiesiog pridėti atitinkamą stulpelio specifikaciją prie pasirinktinių stulpelių parinkties:

$ 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

Išraiška pasirenka mazgo pavadinimą iš spec.nodeName — kai mazgui priskiriamas blokas, lauke įrašomas jo pavadinimas spec.nodeName pod išteklių specifikacija. Išsamesnę informaciją rasite išvestyje kubectl explain pod.spec.nodeName.

Atminkite, kad „Kubernetes“ išteklių laukuose skiriamos didžiosios ir mažosios raidės.

Galite peržiūrėti bet kurį išteklių lauką kaip stulpelį. Tiesiog peržiūrėkite išteklių specifikaciją ir išbandykite su bet kuriais jums patinkančiais laukais.

Tačiau pirmiausia atidžiau pažvelkime į lauko pasirinkimo išraiškas.

JSONPath išraiškos

Resursų laukų pasirinkimo išraiškos yra pagrįstos JSONPath.

JSONPath yra kalba, skirta gauti duomenis iš JSON dokumentų. Vieno lauko pasirinkimas yra paprasčiausias JSONPath naudojimo atvejis. Jis turi daug daugiau galimybių, įskaitant selektorius, filtrus ir pan.

Kubectl paaiškinti palaiko ribotą skaičių JSONPath funkcijų. Galimybės ir jų panaudojimo pavyzdžiai aprašyti žemiau:

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

Operatorius [] yra ypač svarbus. Daugelis „Kubernetes“ išteklių laukų yra sąrašai, ir šis operatorius leidžia pasirinkti tų sąrašų narius. Jis dažnai naudojamas su pakaitos simboliu, pvz., [*], norint pasirinkti visus sąrašo elementus.

Taikymo pavyzdžiai

Galimybės naudoti pasirinktinį stulpelio išvesties formatą yra neribotos, nes išvestyje galite rodyti bet kokį lauką arba išteklių laukų derinį. Štai keletas programų pavyzdžių, bet drąsiai išbandykite jas patys ir raskite jums tinkamų programų.

Rodomi ankšties konteinerių vaizdai:

$ 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

Ši komanda rodo kiekvienos grupės konteinerio vaizdo pavadinimus.

Atminkite, kad pogrupyje gali būti keli konteineriai, tada vaizdų pavadinimai bus rodomi vienoje eilutėje, atskirti kableliais.

Rodomos mazgo pasiekiamumo zonos:
```
$ 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
```
Ši komanda naudinga, jei jūsų klasteris yra viešajame debesyje. Jame rodoma kiekvieno mazgo prieinamumo zona.

Pasiekiamumo zona yra debesų koncepcija, apribojanti replikacijos zoną iki geografinio regiono.

Kiekvieno mazgo prieinamumo zonos gaunamos naudojant specialią etiketę - failure-domain.beta.kubernetes.io/zone. Jei klasteris veikia viešajame debesyje, ši etiketė sukuriama automatiškai ir užpildoma kiekvieno mazgo pasiekiamumo zonų pavadinimais.

Etiketės nėra Kubernetes išteklių specifikacijos dalis, todėl informacijos apie jas nerasite API vadovas. Tačiau jie gali būti matomi (kaip ir bet kuri kita etiketė), jei prašote informacijos apie mazgus YAML arba JSON formatu:
```
$ kubectl get nodes -o yaml
# или
$ kubectl get nodes -o json
```
Tai puikus būdas sužinoti daugiau apie išteklius, be mokymosi išteklių specifikacijų.

4. Lengvai perjunkite tarp grupių ir vardų erdvių

Kai kubectl pateikia užklausą Kubernetes API, ji pirmiausia nuskaito kubeconfig failą, kad gautų visus reikalingus ryšio parametrus.

Pagal numatytuosius nustatymus kubeconfig failas yra ~/.kube/config. Paprastai šis failas sukuriamas arba atnaujinamas specialia komanda.

Kai dirbate su keliais klasteriais, jūsų kubeconfig faile yra prisijungimo prie visų tų grupių parametrai. Jums reikia būdo, kaip pasakyti kubectl komandai, su kuria klasteriu dirbate.

Klasteryje galite sukurti kelias vardų erdves – virtualaus klasterio tipą fiziniame klasteryje. Kubectl taip pat nustato, kurią vardų erdvę naudoti pagal kubeconfig failą. Tai reiškia, kad jums taip pat reikia būdo, kaip nurodyti komandai kubectl, su kokia vardų erdve dirbti.

Šiame skyriuje paaiškinsime, kaip tai veikia ir kaip tai padaryti efektyviai.

Atminkite, kad KUBECONFIG aplinkos kintamajame gali būti keli kubeconfig failai. Tokiu atveju visi šie failai bus sujungti į vieną bendrą konfigūraciją vykdymo metu. Taip pat galite pakeisti numatytąjį kubeconfig failą paleisdami kubectl su parametru --kubeconfig. Pamatyti oficialius dokumentus.

kubeconfig failus

Pažiūrėkime, kas tiksliai yra kubeconfig faile:

Kaip matote, kubeconfig faile yra kontekstų rinkinys. Kontekstas susideda iš trijų elementų:

Klasteris – klasterio serverio API URL.
Vartotojas – naudotojo autentifikavimo kredencialai klasteryje.
Vardų erdvė – vardų erdvė, naudojama prisijungiant prie klasterio.

Praktiškai jie dažnai naudoja vieną kontekstą vienai klasteriui savo kubeconfig. Tačiau vienoje grupėje galite turėti kelis kontekstus, atskirtus pagal vartotoją arba vardų sritį. Tačiau ši kelių kontekstų konfigūracija yra neįprasta, todėl paprastai yra vienas su vienu susiejimas tarp grupių ir kontekstų.

Bet kuriuo metu vienas iš kontekstų yra aktualus:

Kai kubectl nuskaito konfigūracijos failą, jis visada paima informaciją iš esamo konteksto. Aukščiau pateiktame pavyzdyje kubectl prisijungs prie Hare klasterio.

Atitinkamai, norėdami pereiti į kitą klasterį, turite pakeisti dabartinį kontekstą kubeconfig faile:

Dabar kubectl prisijungs prie Fox klasterio.

Norėdami perjungti į kitą vardų sritį tame pačiame klasteryje, turite pakeisti dabartinio konteksto vardų erdvės elemento reikšmę:

Aukščiau pateiktame pavyzdyje kubectl naudos „Fox“ klasterio „Prod“ vardų sritį (anksčiau buvo nustatyta „Test“ vardų sritis).

Atkreipkite dėmesį, kad kubectl taip pat siūlo parinktis --cluster, --user, --namespace и --context, kurios leidžia perrašyti atskirus elementus ir patį dabartinį kontekstą, neatsižvelgiant į tai, kas nustatyta kubeconfig. Žiūrėk kubectl options.

Teoriškai kubeconfig nustatymus galite keisti rankiniu būdu. Bet tai nepatogu. Siekiant supaprastinti šias operacijas, yra įvairių paslaugų, kurios leidžia automatiškai keisti parametrus.

Naudokite kubectx

Labai populiari priemonė, skirta perjungti tarp grupių ir vardų erdvių.

Naudingumas teikia komandas kubectx и kubens kad pakeistumėte atitinkamai esamą kontekstą ir vardų sritį.

Kaip minėta, dabartinio konteksto pakeitimas reiškia klasterio keitimą, jei vienoje grupėje turite tik vieną kontekstą.

Štai šių komandų vykdymo pavyzdys:

Iš esmės šios komandos tiesiog redaguoja kubeconfig failą, kaip aprašyta aukščiau.

instaliuoti kubectx, vadovaukitės instrukcijomis Githubas.

Abi komandos palaiko automatinį konteksto ir vardų erdvės pavadinimų užbaigimą, todėl nereikia jų įvesti iki galo. Automatinio užbaigimo nustatymo instrukcijos čia.

Dar viena naudinga funkcija kubectx yra interaktyvus režimas. Jis veikia kartu su įrankiu fzf, kuris turi būti montuojamas atskirai. Įdiegus fzf automatiškai pasiekiamas interaktyvusis režimas kubectx. Interaktyviai galite pasirinkti kontekstą ir vardų erdvę naudodami interaktyvią nemokamos paieškos sąsają, kurią teikia fzf.

Naudojant apvalkalo slapyvardžius

Norint pakeisti esamą kontekstą ir vardų sritį, jums nereikia atskirų įrankių, nes kubectl taip pat teikia tam skirtas komandas. Taip, komanda kubectl config pateikia subkomandas kubeconfig failams redaguoti.

Štai keletas iš jų:

kubectl config get-contexts: rodyti visus kontekstus;
kubectl config current-context: gauti esamą kontekstą;
kubectl config use-context: pakeisti esamą kontekstą;
kubectl config set-context: pakeiskite konteksto elementą.

Tačiau tiesiogiai naudoti šias komandas nėra labai patogu, nes jos ilgos. Jiems galite sukurti apvalkalo slapyvardžius, kuriuos lengva vykdyti.

Remdamasis šiomis komandomis sukūriau slapyvardžių rinkinį, kuris teikia panašias į kubectx funkcijas. Čia galite pamatyti juos veikiant:

Atkreipkite dėmesį, kad slapyvardžiai naudoja fzf, kad pateiktų interaktyvią nemokamą paieškos sąsają (kaip kubectx interaktyvusis režimas). Tai reiškia, kad jums reikia įdiegti fzfnaudoti šiuos slapyvardžius.

Štai pačių slapyvardžių apibrėžimai:

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

Norėdami nustatyti šiuos slapyvardžius, prie failo turite pridėti aukščiau pateiktus apibrėžimus ~/.bashrc arba ~/.zshrc ir iš naujo paleiskite apvalkalą.

Naudojant papildinius

Kubectl leidžia įkelti papildinius, kurie vykdomi taip pat, kaip ir pagrindinės komandos. Pavyzdžiui, galite įdiegti kubectl-foo papildinį ir paleisti jį vykdydami komandą kubectl foo.

Būtų patogu taip pakeisti kontekstą ir vardų erdvę, pavyzdžiui, paleidžiant kubectl ctx pakeisti kontekstą ir kubectl ns norėdami pakeisti vardų sritį.

Aš parašiau du papildinius, kurie tai daro:

Papildinių darbas pagrįstas slapyvardžiais iš ankstesnės dalies.

Štai kaip jie veikia:

Atkreipkite dėmesį, kad įskiepiai naudoja fzf, kad pateiktų interaktyvią nemokamą paieškos sąsają (kaip kubectx interaktyvusis režimas). Tai reiškia, kad jums reikia įdiegti fzfnaudoti šiuos slapyvardžius.

Norėdami įdiegti papildinius, turite atsisiųsti apvalkalo scenarijus pavadinimu kubectl-ctx и kubectl-ns į bet kurį jūsų PATH kintamojo katalogą ir padarykite juos vykdomus su pvz. chmod +x. Iš karto po to galėsite naudoti kubectl ctx и kubectl ns.

5. Sumažinkite įvestį naudodami automatinius slapyvardžius

Shell slapyvardžiai yra geras būdas pagreitinti įvestį. Projektas kubectl-slapyvardžiai yra apie 800 pagrindinių kubectl komandų nuorodų.

Jums gali kilti klausimas – kaip atsimenate 800 slapyvardžių? Bet jums nereikia jų visų atsiminti, nes jie yra sukurti pagal paprastą schemą, kuri pateikta žemiau:

Pavyzdžiui:

kgpooyaml – kubectl get pods oyaml
ksysgsvcw – kubectl -n kube-system get svc w
ksysrmcm -kubectl -n kube-sistema rm cm
kgdepallsl - kubectl gauti diegimą visi sl

Kaip matote, slapyvardžiai yra sudaryti iš komponentų, kurių kiekvienas yra konkretus komandos kubectl elementas. Kiekvienas slapyvardis gali turėti vieną pagrindinės komandos, operacijos ir išteklių komponentą ir kelis parametrų komponentus. Jūs tiesiog „užpildykite“ šiuos komponentus iš kairės į dešinę pagal aukščiau pateiktą diagramą.

Dabartinė išsami diagrama yra adresu GitHub. Ten taip pat galite rasti visas slapyvardžių sąrašas.

Pavyzdžiui, slapyvardis kgpooyamlall yra lygiavertis komandai kubectl get pods -o yaml --all-namespaces.

Santykinė parinkčių tvarka nėra svarbi: komanda kgpooyamlall yra lygiavertis komandai kgpoalloyaml.

Nereikia naudoti visų komponentų kaip slapyvardžių. Pavyzdžiui k, kg, klo, ksys, kgpo taip pat galima naudoti. Be to, komandinėje eilutėje galite derinti slapyvardžius ir įprastas komandas ar parinktis:

Pavyzdžiui:

Vietoj to kubectl proxy tu gali rašyti k proxy.
Vietoj to kubectl get roles tu gali rašyti kg roles (šiuo metu Roles šaltinio slapyvardžio nėra).
Norėdami gauti konkrečios grupės duomenis, galite naudoti komandą kgpo my-pod — kubectl get pod my-pod.

Atminkite, kad kai kuriems slapyvardžiams reikalingas komandinės eilutės argumentas. Pavyzdžiui, slapyvardis kgpol reiškia, kubectl get pods -l. Variantas -l reikalauja argumento – etiketės specifikacijos. Jei naudosite slapyvardį, jis atrodys taip kgpol app=ui.

Kadangi kai kuriems slapyvardžiams reikia argumentų, slapyvardžiai a, f ir l turi būti naudojami paskutiniai.

Apskritai, kai tik įsisavinate šią schemą, galite intuityviai gauti slapyvardžius iš komandų, kurias norite vykdyti, ir sutaupysite daug laiko spausdinimui.

Diegimas

Norėdami įdiegti kubectl-aliases, turite atsisiųsti failą .kubectl_aliases iš GitHub ir įtraukite jį į failą ~/.bashrc arba ~/.zshrc:

source ~/.kubectl_aliases

Automatinis užbaigimas

Kaip minėjome anksčiau, dažnai prie slapyvardžio komandinėje eilutėje pridedate papildomų žodžių. Pavyzdžiui:

$ kgpooyaml test-pod-d4b77b989

Jei naudojate kubectl komandos užbaigimą, tikriausiai naudojote automatinį užbaigimą tokiems dalykams kaip išteklių pavadinimai. Bet ar tai galima padaryti, kai naudojami slapyvardžiai?

Tai labai svarbus klausimas, nes jei automatinis užbaigimas neveiks, prarasite kai kuriuos slapyvardžių pranašumus.

Atsakymas priklauso nuo to, kokį apvalkalą naudojate:

Zsh slapyvardžio užbaigimas veikia iš karto.
Deja, Bash'ui reikia šiek tiek padirbėti, kad automatinis užbaigimas veiktų.

Įgalinamas automatinis slapyvardžių užbaigimas Bash

„Bash“ problema yra ta, kad jis bando užbaigti (kiekvieną kartą paspaudus Tab) slapyvardį, o ne komandą, į kurią nurodo slapyvardis (kaip, pavyzdžiui, daro Zsh). Kadangi neturite visų 800 slapyvardžių užbaigimo scenarijų, automatinis užbaigimas neveikia.

Projektas pilnas slapyvardis pateikia bendrą šios problemos sprendimą. Jis prisijungia prie slapyvardžio užbaigimo mechanizmo, viduje išplečia slapyvardį į komandą ir grąžina užbaigtos komandos užbaigimo parinktis. Tai reiškia, kad slapyvardžio užpildymas veikia lygiai taip pat, kaip ir visos komandos.

Toliau pirmiausia paaiškinsiu, kaip įdiegti pilną slapyvardį, o tada kaip jį sukonfigūruoti, kad būtų galima užbaigti visus kubectl slapyvardžius.

Diegimas pilnas slapyvardis

Visų pirma, pilnas slapyvardis priklauso nuo bash-užbaigimas. Todėl prieš diegdami užbaigtą slapyvardį turite įsitikinti, kad įdiegtas bash-completion. „Linux“ ir „MacOS“ diegimo instrukcijos buvo pateiktos anksčiau.

Svarbi pastaba MacOS vartotojams: Kaip ir kubectl automatinio užbaigimo scenarijus, užbaigtas slapyvardis neveikia naudojant „Bash 3.2“, kuris yra numatytasis „MacOS“. Visų pirma, pilnas pseudonimas priklauso nuo bash-completion v2 (brew install bash-completion@2), kuriai reikalinga bent „Bash 4.1“. Tai reiškia, kad norėdami naudoti pilną slapyvardį „MacOS“, turite įdiegti naujesnę „Bash“ versiją.

Jums reikia atsisiųsti scenarijų bash_completion.sh iš GitHub saugykla ir įtraukite jį į savo failą ~/.bashrc:

source ~/bash_completion.sh

Iš naujo paleidus apvalkalą, pilnas slapyvardis bus visiškai įdiegtas.

Įgalinamas kubectl slapyvardžių automatinis užbaigimas

Techniškai užbaigtas slapyvardis suteikia įvyniojimo funkciją _complete_alias. Ši funkcija patikrina slapyvardį ir pateikia slapyvardžio komandos užbaigimo užuominas.

Norėdami susieti funkciją su konkrečiu slapyvardžiu, turite naudoti integruotą „Bash“ mechanizmą užbaigti, instaliuoti _complete_alias kaip slapyvardžio užbaigimo funkcija.

Kaip pavyzdį paimkime slapyvardį k, kuris reiškia kubectl komandą. instaliuoti _complete_alias Kaip šio slapyvardžio papildymo funkciją, turėtumėte paleisti šią komandą:

$ complete -F _complete_alias k

To rezultatas yra tas, kad kai automatiškai užbaigiate slapyvardį k, funkcija iškviečiama _complete_alias, kuris patikrina slapyvardį ir pateikia komandos užbaigimo užuominas kubectl.

Kaip antrą pavyzdį paimkime slapyvardį kg, kuris reiškia kubectl get:

$ complete -F _complete_alias kg

Kaip ir ankstesniame pavyzdyje, kai automatiškai užpildote kg, gaunate tas pačias užbaigimo užuominas, kurias gautumėte kubectl get.

Atminkite, kad galite naudoti pilną slapyvardį bet kuriam jūsų sistemos slapyvardžiui.

Todėl, norėdami įgalinti visų kubectl slapyvardžių automatinį užbaigimą, kiekvienam iš jų turite paleisti aukščiau pateiktą komandą. Šis fragmentas tiksliai tai daro, jei nustatėte kubectl-aliases ~/.kubectl-aliases:

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

Šią kodo dalį reikia įdėti į savo ~/.bashrc, iš naujo paleiskite komandų apvalkalą ir automatinis užbaigimas bus pasiekiamas visiems 800 kubectl slapyvardžiams.

6. Kubectl išplėtimas su priedais

Nuo 1.12 versija, kubectl palaiko įskiepio mechanizmas, kurios leidžia išplėsti jo funkcijas papildomomis komandomis.

Jei esate susipažinę su Git įskiepių mechanizmai, tada kubectl įskiepiai yra sukurti tuo pačiu principu.

Šiame skyriuje apžvelgsime, kaip įdiegti papildinius, kur juos rasti ir kaip sukurti savo papildinius.

Papildinių diegimas

„Kubectl“ papildiniai platinami kaip paprasti vykdomieji failai, kurių pavadinimas yra panašus kubectl-x. Priešdėlis kubectl- reikalinga, o po to pateikiama nauja kubectl antrinė komanda, leidžianti iškviesti papildinį.

Pavyzdžiui, įskiepis hello bus platinamas kaip failas, vadinamas kubectl-hello.

Norėdami įdiegti papildinį, turite nukopijuoti failą kubectl-x į bet kurį jūsų PATH katalogą ir padarykite jį vykdomąjį, pavyzdžiui, su chmod +x. Iš karto po to galite iškviesti papildinį su kubectl x.

Galite naudoti šią komandą, kad pateiktumėte visus šiuo metu jūsų sistemoje įdiegtus papildinius:

$ kubectl plugin list

Ši komanda taip pat parodys įspėjimus, jei turite kelis papildinius tuo pačiu pavadinimu arba jei yra papildinių failas, kurio negalima vykdyti.

Papildinių paieška ir įdiegimas naudojant Krew

Kubectl įskiepiai gali būti bendrinami arba naudojami pakartotinai kaip programinės įrangos paketai. Bet kur galite rasti papildinių, kuriuos bendrino kiti?

Projektas Krew siekia pateikti vieningą kubectl įskiepių bendrinimo, paieškos, diegimo ir valdymo sprendimą. Projektas save vadina „kubectl įskiepių paketų tvarkytuvu“ (Krew yra panašus į alus).

Krew yra kubectl papildinių, kuriuos galite pasirinkti ir įdiegti, sąrašas. Tuo pačiu metu „Krew“ taip pat yra „kubectl“ papildinys.

Tai reiškia, kad „Krew“ diegimas iš esmės veikia kaip bet kurio kito „kubectl“ papildinio įdiegimas. Išsamias instrukcijas galite rasti adresu GitHub puslapis.

Svarbiausios Krew komandos yra šios:

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

Atkreipkite dėmesį, kad įskiepių diegimas naudojant Krew netrukdo diegti papildinius naudojant standartinį aukščiau aprašytą metodą.

Atkreipkite dėmesį, kad komanda kubectl krew list rodo tik papildinius, kurie buvo įdiegti naudojant Krew, o komanda kubectl plugin list išvardija visus papildinius, ty tuos, kurie buvo įdiegti naudojant Krew, ir tuos, kurie buvo įdiegti kitais metodais.

Papildinių paieška kitur

„Krew“ yra jaunas projektas, šiuo metu jis vykdomas sąrašą tik apie 30 papildinių. Jei nerandate to, ko jums reikia, įskiepių galite rasti kitur, pvz., „GitHub“.

Rekomenduoju pažiūrėti GitHub skyrių kubectl-įskiepiai. Ten rasite daugybę galimų papildinių, kuriuos verta patikrinti.

Savo įskiepių rašymas

tu gali pats kurti papildinius – Nesunku. Turite sukurti vykdomąjį failą, kuris daro tai, ko jums reikia, pavadinkite jį taip kubectl-x ir įdiekite, kaip aprašyta aukščiau.

Failas gali būti bash scenarijus, python scenarijus arba sukompiliuota GO programa – tai nesvarbu. Vienintelė sąlyga yra tai, kad jis gali būti tiesiogiai vykdomas operacinėje sistemoje.

Dabar sukurkime pavyzdinį įskiepį. Ankstesniame skyriuje naudojote komandą kubectl, kad pateiktumėte kiekvienos grupės konteinerius. Šią komandą lengva paversti įskiepiu, kurį galite iškviesti pvz. kubectl img.

Sukurkite failą kubectl-img toks turinys:

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

Dabar padarykite failą vykdomąjį naudojant chmod +x kubectl-img ir perkelkite jį į bet kurį jūsų PATH katalogą. Iš karto po to galite naudoti papildinį kubectl img.

Kaip minėta, kubectl įskiepiai gali būti parašyti bet kuria programavimo ar scenarijų kalba. Jei naudojate apvalkalo scenarijus, privalumas yra galimybė lengvai iškviesti kubectl iš papildinio. Tačiau naudodamiesi realiomis programavimo kalbomis galite rašyti sudėtingesnius papildinius Kubernetes kliento biblioteka. Jei naudojate „Go“, taip pat galite naudoti cli-runtime biblioteka, kuris egzistuoja specialiai kubectl įskiepiams rašyti.

Kaip bendrinti savo papildinius

Jei manote, kad jūsų papildiniai gali būti naudingi kitiems, nedvejodami pasidalykite jais „GitHub“. Būtinai pridėkite juos prie temos kubectl-įskiepiai.

Taip pat galite prašyti, kad jūsų papildinys būtų įtrauktas į Krew sąrašas. Nurodymai, kaip tai padaryti, yra „GitHub“ saugyklos.

Komandos įvykdymas

Papildiniai šiuo metu nepalaiko automatinio užbaigimo. Tai reiškia, kad turite įvesti visą papildinio pavadinimą ir visus argumentų pavadinimus.

Šios funkcijos „GitHub kubectl“ saugykla turi atviras prašymas. Taigi gali būti, kad ši funkcija kada nors bus įdiegta ateityje.

Sėkmės!!!

Ką dar skaityti šia tema:

Šaltinis: www.habr.com

Kaip efektyviau naudoti kubectl: išsamus vadovas