🥇Kiel uzi kubectl pli efike: detala gvidilo

Se vi laboras kun Kubernetes, tiam kubectl verŝajne estas unu el la utilecoj, kiujn vi plej uzas. Kaj kiam ajn vi pasigas multan tempon laborante kun aparta ilo, ĝi pagas bone studi ĝin kaj lerni kiel uzi ĝin efike.

teamo Kubernetes aaS de Mail.ru tradukis artikolon de Daniel Weibel, en kiu vi trovos konsiletojn kaj lertaĵojn por efike labori kun kubectl. Ĝi ankaŭ helpos vin akiri pli profundan komprenon pri Kubernetes.

Laŭ la aŭtoro, la celo de la artikolo estas fari vian ĉiutagan laboron kun Kubernetes ne nur pli efika, sed ankaŭ pli agrabla!

Enkonduko: Kio estas kubectl

Antaŭ ol vi povas lerni uzi kubectl pli efike, vi devas akiri bazan komprenon pri kio ĝi estas kaj kiel ĝi funkcias.

El la perspektivo de uzanto, kubectl estas kontrolpanelo, kiu ebligas al vi plenumi operaciojn de Kubernetes.

Teknike parolante, kubectl estas Kubernetes API-kliento.

Kubernetes API estas HTTP REST API. Ĉi tiu API estas la vera uzantinterfaco de Kubernetes, per kiu ĝi estas tute kontrolita. Ĉi tio signifas, ke ĉiu operacio de Kubernetes estas elmontrita kiel API-finpunkto kaj povas esti farita per HTTP-peto al tiu finpunkto.

Tial, la ĉefa laboro de kubectl estas fari HTTP-petojn al la Kubernetes API:

Kubernetes estas tute rimeda sistemo. Ĉi tio signifas, ke ĝi konservas la internan staton de rimedoj kaj ĉiuj operacioj de Kubernetes estas CRUD-operacioj.

Vi tute regas Kubernetes administrante ĉi tiujn rimedojn, kaj Kubernetes eltrovas kion fari surbaze de la nuna stato de la rimedoj. Tial, la Kubernetes API-referenco estas organizita kiel listo de rimedtipoj kun iliaj rilataj operacioj.

Ni rigardu ekzemplon.

Ni diru, ke vi volas krei ReplicaSet-rimedon. Por fari tion, vi priskribas la ReplicaSet en dosiero per nomo replicaset.yaml, tiam rulu la komandon:

$ kubectl create -f replicaset.yaml

Ĉi tio kreos ReplicaSet-rimedon. Sed kio okazas malantaŭ la kulisoj?

Kubernetes havas kreadoperacion de ReplicaSet. Kiel ajna alia operacio, ĝi estas elmontrita kiel API-finpunkto. La specifa API-finpunkto por ĉi tiu operacio aspektas jene:

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

API-finpunktoj por ĉiuj operacioj de Kubernetes troveblas ĉe API-referenco (inkluzive la supra finpunkto). Por fari realan peton al finpunkto, vi unue devas aldoni la API-servilan URL al la finpunktovojoj kiuj estas listigitaj en la API-referenco.

Tial, kiam vi plenumas la ĉi-supran komandon, kubectl sendas HTTP-POST-peton al la supra API-finpunkto. La ReplicaSet-difino, kiun vi disponigis en la dosiero replicaset.yaml, estas sendita en la korpo de la peto.

Jen kiel kubectl funkcias por ĉiuj komandoj, kiuj interagas kun la Kubernetes-grupo. En ĉiuj ĉi tiuj kazoj, kubectl simple faras HTTP-petojn al la konvenaj Kubernetes API-finpunktoj.

Bonvolu noti, ke vi povas plene administri Kubernetes uzante ilon kiel ekzemple curlpermane sendante HTTP-petojn al la Kubernetes API. Kubectl simple faciligas uzi la Kubernetes API.

Ĉi tio estas la bazoj pri tio, kio estas kubectl kaj kiel ĝi funkcias. Sed estas io alia pri la Kubernetes API, kiun ĉiu kubectl-uzanto devus scii. Ni rigardu rapide en la internan mondon de Kubernetes.

La interna mondo de Kubernetes

Kubernetes konsistas el aro de sendependaj komponantoj, kiuj funkcias kiel apartaj procezoj sur grapolnodoj. Kelkaj komponentoj funkcias per majstraj nodoj, aliaj sur labornodoj, ĉiu komponento plenumante sian propran specifan taskon.

Jen la plej gravaj komponantoj sur la ĉefaj nodoj:

dosieraro - konservas difinojn de rimedoj (kutime ĝi estas ktpd).
API-servilo — provizas API kaj administras stokadon.
Regilo-Manaĝero — Certigas, ke resursaj statusoj konformas al specifoj.
Planilo — planas podojn sur labornodoj.

Kaj jen unu plej grava komponanto sur la labornodoj:

kubelet — administras la lanĉon de ujoj sur la labornodo.

Por kompreni kiel ĉi tiuj komponantoj funkcias kune, ni rigardu ekzemplon.

Ni supozu, ke vi ĵus finis kubectl create -f replicaset.yaml, post kio kubectl faris HTTP-POST-peton al ReplicaSet API finpunkto (pasante la rimedan difinon de ReplicaSet).

Kio okazas en la areto?

Post fari kubectl create -f replicaset.yaml La API-servilo konservas vian rimedan difinon de ReplicaSet en stokado:
Poste, la regilo ReplicaSet estas lanĉita en la regilo-administranto, kiu pritraktas la kreadon, modifon kaj forigon de ReplicaSet-resursoj:
La regilo de ReplicaSet kreas poddifinon por ĉiu kopio de ReplicaSet (laŭ la podŝablono en la difino de ReplicaSet) kaj konservas ilin en stokado:
La planilo estas lanĉita, spurante podojn kiuj ankoraŭ ne estis asignitaj al iuj labornodoj:
La planisto elektas taŭgan labornodon por ĉiu pod kaj aldonas ĉi tiujn informojn al la poddifino en la vendejo:
Sur la labornodo al kiu la pod estas asignita, Kubelet estas lanĉita, ĝi spuras la podojn asignitajn al ĉi tiu nodo:
La Kubelet legas la poddifinon de stokado kaj instrukcias ujran rultempon, kiel Docker, lanĉi ujojn sur la nodo:

Malsupre estas teksta versio de ĉi tiu priskribo.

La API-peto al la krea finpunkto de ReplicaSet estas prilaborita de la API-servilo. La API-servilo aŭtentikigas la peton kaj konservas la rimedan difinon de ReplicaSet en stokado.

Ĉi tiu evento komencas la regilon ReplicaSet, kiu estas subprocezo de la regilo-manaĝero. La ReplicaSet-regilo kontrolas la kreadon, ĝisdatigon kaj forigon de ReplicaSet-resursoj en la vendejo kaj ricevas okazaĵan sciigon kiam tio okazas.

La tasko de la regilo de ReplicaSet estas certigi, ke ekzistas la bezonata nombro da podoj de ReplicaSet. En nia ekzemplo, neniuj podoj ankoraŭ ekzistas, do la regilo de ReplicaSet kreas ĉi tiujn poddifinojn (laŭ la podŝablono en la difino de ReplicaSet) kaj konservas ilin en stokado.

La kreado de novaj podoj estas ekigita de planilo, kiu konservas trakon de poddifinoj, kiuj ankoraŭ ne estas planitaj por labornodoj. La planisto elektas taŭgan labornodon por ĉiu pod kaj ĝisdatigas la poddifinojn en la deponejo.

Notu, ke ĝis ĉi tiu punkto, neniu laborŝarĝa kodo funkciis ie ajn en la areto. Ĉio, kio estis farita ĝis nun - ĉi tio estas la kreado kaj ĝisdatigo de rimedoj en la deponejo sur la majstra nodo.

La lasta evento ekigas Kubelets, kiuj kontrolas la podojn planitajn por siaj labornodoj. La Kubelet de la labornodo, sur kiu viaj ReplicaSet-podoj estas instalitaj, devas instrukcii la ujan rultempon, kiel Docker, elŝuti la postulatajn ujajn bildojn kaj ruli ilin.

Je ĉi tiu punkto, via ReplicaSet-aplikaĵo finfine funkcias!

Rolo de la Kubernetes API

Kiel vi vidis en la antaŭa ekzemplo, Kubernetes-komponentoj (krom la API-servilo kaj stokado) rigardas por ŝanĝoj al resursoj en stokado kaj ŝanĝas informojn pri rimedoj en stokado.

Kompreneble, ĉi tiuj komponantoj ne interagas kun la stokado rekte, sed nur per la Kubernetes API.

Konsideru la sekvajn ekzemplojn:

La ReplicaSet-regilo uzas la API-finpunkton listigu ReplicaSets kun parametro watch por kontroli ŝanĝojn al ReplicaSet-resursoj.
La ReplicaSet-regilo uzas la API-finpunkton krei Pod (create pod) krei podojn.
Planilo uzas API-finpunkton flikilo pod (redakti pod) por ĝisdatigi podojn kun informoj pri la elektita labornodo.

Kiel vi povas vidi, ĉi tio estas la sama API, kiun kubectl aliras. Uzi la saman API por internaj komponantoj kaj eksteraj uzantoj estas fundamenta koncepto en Kubernetes-dezajno.

Nun ni povas resumi kiel Kubernetes funkcias:

La stokaj vendejoj deklaras, tio estas, rimedoj de Kubernetes.
La API-servilo disponigas interfacon al la stokado en la formo de la Kubernetes API.
Ĉiuj aliaj komponantoj kaj uzantoj de Kubernetes legas, observas kaj manipulas staton (rimedojn) de Kubernetes per la API.

Koni ĉi tiujn konceptojn helpos vin kompreni kubectl pli bone kaj akiri la plej grandan parton de ĝi.

Nun ni rigardu kelkajn specifajn konsiletojn kaj lertaĵojn, kiuj helpos plibonigi vian produktivecon kun kubectl.

1. Akcelu enigon per komanda kompletigo

Unu el la plej utilaj, sed ofte preteratentitaj, teknikoj por plibonigi rendimenton kun kubectl estas komandokompletigo.

Komanda kompletigo permesas vin aŭtomate kompletigi partojn de kubectl-komandoj per la Tab-klavo. Ĉi tio funkcias por subkomandoj, opcioj kaj argumentoj, inkluzive de io tiel kompleksa kiel nomoj de rimedoj.

Vidu kiel funkcias kubectl komandkompletigo:

Komandkompletigo funkcias por Bash kaj Zsh-ŝeloj.

Oficiala Gvidilo enhavas detalajn instrukciojn por agordi aŭtomatan kompleton, sed ĉi-sube ni provizos mallongan eltiraĵon.

Kiel komanda kompletigo funkcias

Komanda kompletigo estas ŝeltrajto, kiu funkcias per kompletiga skripto. Etenda skripto estas ŝel-skripto, kiu difinas la konduton de etendaĵo por specifa komando.

Kubectl aŭtomate generas kaj eligas etendajn skriptojn por Bash kaj Zsh uzante la jenajn komandojn:

$ kubectl completion bash

Aŭ:

$ kubectl completion zsh

En teorio, sufiĉas konekti la eligon de ĉi tiuj komandoj al la taŭga komanda ŝelo por ke kubectl povu kompletigi la komandojn.

En praktiko, la konektometodo estas malsama por Bash (inkluzive de diferencoj inter Linukso kaj MacOS) kaj Zsh. Malsupre ni rigardos ĉiujn ĉi tiujn eblojn.

Batu pri Linukso

La kompletiga skripto de Bash dependas de la pakaĵo bash-completion, do vi devas unue instali ĝin:

$ sudo apt-get install bash-completion

Aŭ:

$ yum install bash-completion

Vi povas provi, ke la pako estas instalita sukcese uzante la jenan komandon:

$ type _init_completion

Se ĉi tio eligas ŝelan funkciokodon, tiam bash-kompletigo estas instalita ĝuste. Se la komando donas eraron "Ne Trovita", vi devas aldoni la sekvan linion al via dosiero ~ / .bashrc:

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

Ĉu necesas aldoni ĉi tiun linion al la dosiero ~ / .bashrc aŭ ne dependas de la pakaĵadministrilo, kiun vi uzis por instali bash-completion. Ĉi tio estas necesa por APT, sed ne por YUM.

Post instalo de bash-completion, vi devas agordi ĉion tiel ke la kubectl-kompletiga skripto estas ebligita en ĉiuj ŝelkunsioj.

Unu maniero fari tion estas aldoni la sekvan linion al la dosiero ~ / .bashrc:

source <(kubectl completion bash)

Alia maniero estas aldoni la kubectl-etendan skripton al la dosierujo /etc/bash_completion.d (kreu ĝin se ĝi ne ekzistas):

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

Ĉiuj aldonaj skriptoj en la katalogo /etc/bash_completion.d estas aŭtomate inkluzivitaj en bash-completion.

Ambaŭ opcioj estas egale aplikeblaj.

Post rekomenco de la ŝelo, kompletigo de la komando kubectl funkcios.

Batu sur MacOS

En MacOS la agordo estas iom pli komplika. La fakto estas, ke defaŭlte, MacOS uzas Bash-version 3.2, kaj la kubectl aŭtokompleta skripto postulas Bash-version de almenaŭ 4.1 kaj ne funkcias en Bash 3.2.

Estas licencaj problemoj asociitaj kun uzado de malmoderna versio de Bash sur MacOS. Bash-versio 4 estas licencita sub GPLv3, kiu ne estas subtenata de Apple.

Por agordi kubectl-aŭtomatkompleton ĉe MacOS, vi devas instali pli freŝan version de Bash. Vi ankaŭ povas agordi la ĝisdatigitan Bash kiel vian defaŭltan ŝelon, kio ŝparos al vi multajn problemojn en la estonteco. Ne estas malfacila, detaloj estas donitaj en la artikolo "Ĝisdatigante Bash sur MacOS".

Antaŭ ol daŭrigi, certigu, ke vi uzas lastatempan version de Bash (kontrolu la eligon bash --version).

Bash-kompletiga skripto varias laŭ projekto bash-kompletigo, do vi devas unue instali ĝin.

Vi povas instali bash-completion uzante homebrew:

$ brew install bash-completion@2

estas @2 signifas bash-completion versio 2. kubectl aŭtokompletigo postulas bash-completion v2, kaj bash-completion v2 postulas minimumon de Bash-versio 4.1.

Komanda eligo brew-install enhavas sekcion Avertoj, kiu precizigas tion, kion oni devas aldoni al la dosiero ~/.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"

Tamen mi rekomendas aldoni ĉi tiujn liniojn ne al ~/.bash_profilekaj en ~/.bashrc. En ĉi tiu kazo, aŭtomata kompletigo estos disponebla ne nur en la ĉefa, sed ankaŭ en infanaj komandŝeloj.

Post rekomenco de la komanda ŝelo, vi povas kontroli, ke la instalado estas ĝusta per la sekva komando:

$ type _init_completion

Se vi vidas ŝelan funkcion en la eligo, tiam ĉio estas agordita ĝuste.

Nun ni devas certigi, ke kubectl aŭtomata kompletigo estas ebligita en ĉiuj sesioj.

Unu maniero estas aldoni la sekvan linion al via ~/.bashrc:

source <(kubectl completion bash)

La dua maniero estas aldoni aŭtomatan skripton al la dosierujo /usr/local/etc/bash_completion.d:

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

Ĉi tiu metodo nur funkcios se vi instalis bash-completion uzante Homebrew. En ĉi tiu kazo, bash-completion ŝarĝas ĉiujn skriptojn de ĉi tiu dosierujo.

Se vi instalis kubectl uzante Homebrew, tiam ne necesas plenumi la antaŭan paŝon, ĉar la aŭtokompleta skripto estos aŭtomate metita en la dosierujon /usr/local/etc/bash_completion.d dum instalado. En ĉi tiu kazo, kubectl aŭtomata kompletigo komencos funkcii tuj kiam vi instalos bash-completion.

Kiel rezulto, ĉiuj ĉi tiuj opcioj estas ekvivalentaj.

Zsh

Zsh-kompletigskriptoj ne postulas ajnajn dependecojn. Vi nur devas ebligi ilin kiam vi ŝargas la komandan ŝelon.

Vi povas fari tion aldonante linion al via ~/.zshrc dosiero:

source <(kubectl completion zsh)

Se vi ricevas eraron not found: compdef post rekomenco de via ŝelo, vi devas ebligi la enkonstruitan funkcion compdef. Vi povas ebligi ĝin aldonante ĝin al la komenco de via dosiero ~/.zshrc jeno:

autoload -Uz compinit
compinit

2. Rapide vidu rimedajn specifojn

Kiam vi kreas difinojn de YAML-rimedoj, vi devas scii la kampojn kaj ilian signifon por tiuj rimedoj. Unu loko por serĉi ĉi tiun informon estas en la API-referenco, kiu enhavas kompletajn specifojn por ĉiuj rimedoj.

Tamen ŝanĝi al la retumilo ĉiufoje kiam vi bezonas serĉi ion estas maloportuna. Tial kubectl disponigas la komandon kubectl explain, kiu montras la specifojn de ĉiuj rimedoj ĝuste en via terminalo.

La komandformato estas kiel sekvas:

$ kubectl explain resource[.field]...

La komando eligos la specifon de la petita rimedo aŭ kampo. La informo montrita estas identa al tiu enhavita en la API-manlibro.

defaŭlte kubectl explain montras nur la unuan nivelon de nestado de kampoj.

Vidu kiel ĝi aspektas povas esti ĉi tie.

Vi povas montri la tutan arbon se vi aldonas la opcion --recursive:

$ kubectl explain deployment.spec --recursive

Se vi ne scias precize kiuj rimedoj estas bezonataj, vi povas montri ilin ĉiujn per la sekva komando:

$ kubectl api-resources

Ĉi tiu komando montras nomojn de rimedoj en plurala formo, ekz. deployments anstataŭ deployment. Ĝi ankaŭ montras la mallongan nomon, ekzemple deploy, por tiuj rimedoj, kiuj havas ĝin. Ne zorgu pri ĉi tiuj diferencoj. Ĉiuj ĉi tiuj nomopcioj estas ekvivalentaj por kubectl. Tio estas, vi povas uzi iun ajn el ili por kubectl explain.

Ĉiuj jenaj komandoj estas ekvivalentaj:

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

3. Uzu laŭmendan kolumnan eligformaton

Defaŭlta komanda eligo-formato 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

Ĉi tiu formato estas oportuna, sed ĝi enhavas limigitan kvanton da informoj. Kompare kun la plena rimeda difinformato, nur kelkaj kampoj estas montrataj ĉi tie.

En ĉi tiu kazo, vi povas uzi laŭmendan kolumnan eligformaton. Ĝi permesas vin determini kiajn datumojn eligi. Vi povas montri ajnan rimedan kampon kiel apartan kolumnon.

La uzo de kutima formato estas determinita per la elektoj:

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

Vi povas difini ĉiun eligan kolumnon kiel paron <header>:<jsonpath>kie <header> estas la kolumnonomo, kaj <jsonpath> — esprimo difinanta rimedkampon.

Ni rigardu simplan ekzemplon:

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

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

La eligo enhavas unu kolumnon kun la nomoj de la balgoj.

La opcioesprimo elektas la podnomojn el la kampo metadata.name. Ĉi tio estas ĉar la nomo de la pod estas difinita en la infana nomo kampo metadata en la rimedpriskribo de la balgo. Pliaj detaloj troveblas en Gvidilo pri API aŭ tajpu la komandon kubectl explain pod.metadata.name.

Nun ni diru, ke vi volas aldoni kroman kolumnon al la eligo, ekzemple montrante la nodon, sur kiu funkcias ĉiu pod. Por fari tion, vi povas simple aldoni la taŭgan kolumnan specifon al la kutima kolumna opcio:

$ 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

La esprimo elektas la nodnomon el spec.nodeName — kiam pod estas asignita al nodo, ĝia nomo estas skribita en la kampo spec.nodeName pod rimeda specifo. Pli detalaj informoj troveblas en la eligo kubectl explain pod.spec.nodeName.

Bonvolu noti, ke Kubernetes-rimedaj kampoj distingas minusklecojn.

Vi povas vidi ajnan rimedan kampon kiel kolumnon. Nur reviziu la rimedan specifon kaj provu ĝin per iuj kampoj, kiujn vi ŝatas.

Sed unue, ni rigardu pli detale ĉe kampo-elekto-esprimoj.

JSONPath Esprimoj

Esprimoj por elekti rimedkampojn baziĝas sur JSONPath.

JSONPath estas lingvo por retrovi datumojn de JSON-dokumentoj. Elekti ununuran kampon estas la plej simpla uzkazo por JSONPath. Li havas multon pli da eblecoj, inkluzive de elektiloj, filtriloj ktp.

Kubectl-klarigado subtenas limigitan nombron da funkcioj de JSONPath. La eblecoj kaj ekzemploj de ilia uzo estas priskribitaj malsupre:

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

La [] operatoro estas precipe grava. Multaj rimedkampoj de Kubernetes estas listoj, kaj ĉi tiu operatoro permesas vin elekti membrojn de tiuj listoj. Ĝi estas ofte uzata kun ĵokero kiel [*] por elekti ĉiujn elementojn de listo.

Ekzemploj de aplikaĵo

La eblecoj por uzi laŭmendan kolumnan eligformaton estas senfinaj, ĉar vi povas montri ajnan kampon aŭ kombinaĵon de rimedkampoj en la eligo. Jen kelkaj ekzemplaj apoj, sed bonvolu esplori ilin mem kaj trovi aplikaĵojn kiuj funkcias por vi.

Montrante ujajn bildojn por podoj:

$ 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 tiu komando montras la ujajn bildnomojn por ĉiu pod.

Memoru, ke pod povas enhavi plurajn ujojn, tiam la bildnomoj estos montrataj sur unu linio, apartigitaj per komoj.

Montrante nodajn havebleczonojn:
```
$ 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 tiu komando estas utila se via areto estas gastigita en publika nubo. Ĝi montras la havebleczonon por ĉiu nodo.

Disponeczono estas nuba koncepto, kiu limigas la reproduktadzonon al geografia regiono.

Disponeblaj zonoj por ĉiu nodo estas akiritaj per speciala etikedo - failure-domain.beta.kubernetes.io/zone. Se la areto funkcias en publika nubo, ĉi tiu etikedo estas kreita aŭtomate kaj plenigita kun la nomoj de la haveblecaj zonoj por ĉiu nodo.

Etikedoj ne estas parto de la rimeda specifo de Kubernetes, do vi ne trovos informojn pri ili Gvidilo pri API. Tamen, ili povas esti viditaj (kiel iuj aliaj etikedoj) se vi petas informojn pri la nodoj en formato YAML aŭ JSON:
```
$ kubectl get nodes -o yaml
# или
$ kubectl get nodes -o json
```
Ĉi tio estas bonega maniero lerni pli pri rimedoj, krom lerni specifojn pri rimedoj.

4. Facile ŝanĝi inter aretoj kaj nomspacoj

Kiam kubectl faras peton al la Kubernetes API, ĝi unue legas la kubeconfig-dosieron por akiri ĉiujn necesajn parametrojn por la konekto.

Defaŭlte la kubeconfig dosiero estas ~/.kube/config. Tipe ĉi tiu dosiero estas kreita aŭ ĝisdatigita per speciala komando.

Kiam vi laboras kun pluraj aretoj, via kubeconfig-dosiero enhavas agordojn por konekti al ĉiuj tiuj aretoj. Vi bezonas manieron diri al la komando kubectl, kun kiu aro vi laboras.

Ene de areto, vi povas krei plurajn nomspacojn—specon de virtuala areto ene de fizika areto. Kubectl ankaŭ determinas kiun nomspacon uzi surbaze de la kubeconfig-dosiero. Ĉi tio signifas, ke vi ankaŭ bezonas manieron diri al la komando kubectl kun kiu nomspaco labori.

En ĉi tiu ĉapitro ni klarigos kiel ĝi funkcias kaj kiel fari ĝin funkcii efike.

Notu, ke vi eble havas plurajn kubeconfig-dosierojn listigitajn en la mediovariablo KUBECONFIG. En ĉi tiu kazo, ĉiuj ĉi tiuj dosieroj estos kombinitaj en unu komunan agordon ĉe rultempo. Vi ankaŭ povas ŝanĝi la defaŭltan kubeconfig-dosieron rulante kubectl kun la parametro --kubeconfig. Rigardu oficiala dokumentaro.

kubeconfig dosieroj

Ni vidu, kion precize enhavas la kubeconfig-dosiero:

Kiel vi povas vidi, la kubeconfig-dosiero enhavas aron da kuntekstoj. Kunteksto konsistas el tri elementoj:

Areto — API URL de la clusterservilo.
Uzanto - akreditaĵoj de uzanto en la areto.
Nomspaco - la nomspaco uzata dum aliĝo al la areto.

En praktiko, ili ofte uzas unu kuntekston per areto en sia kubeconfig. Tamen, vi povas havi plurajn kuntekstojn per areto, diferencitaj laŭ uzanto aŭ nomspaco. Tamen, ĉi tiu plurkunteksta agordo estas nekutima, do kutime ekzistas unu-al-unu mapado inter aretoj kaj kuntekstoj.

En ajna momento, unu el la kuntekstoj estas aktuala:

Kiam kubectl legas agordan dosieron, ĝi ĉiam prenas informojn el la nuna kunteksto. En la supra ekzemplo, kubectl konektos al la Hare-grupo.

Sekve, por ŝanĝi al alia areto, vi devas ŝanĝi la nunan kuntekston en la kubeconfig-dosiero:

Nun kubectl konektos al la Fox-grupo.

Por ŝanĝi al malsama nomspaco en la sama areto, vi devas ŝanĝi la valoron de la nomspaca elemento por la nuna kunteksto:

En la supra ekzemplo, kubectl uzos la nomspacon Prod de la Fox-grupo (antaŭe la Test-nomspaco estis agordita).

Notu, ke kubectl ankaŭ provizas opciojn --cluster, --user, --namespace и --context, kiuj permesas vin anstataŭigi individuajn elementojn kaj la nunan kuntekston mem, sendepende de tio, kio estas agordita en la kubeconfig. Rigardu kubectl options.

En teorio, vi povas mane ŝanĝi la agordojn en la kubeconfig. Sed estas maloportune. Por simpligi ĉi tiujn operaciojn, ekzistas diversaj utilecoj, kiuj permesas vin aŭtomate ŝanĝi parametrojn.

Uzu kubectx

Tre populara ilo por ŝanĝi inter aretoj kaj nomspacoj.

La ilo disponigas komandojn kubectx и kubens ŝanĝi la nunan kuntekston kaj nomspacon respektive.

Kiel menciite, ŝanĝi la nunan kuntekston signifas ŝanĝi la areton se vi havas nur unu kuntekston per areto.

Jen ekzemplo pri rulado de ĉi tiuj komandoj:

Esence, ĉi tiuj komandoj simple redaktas la kubeconfig-dosieron kiel priskribite supre.

instali kubectx, sekvu la instrukciojn pri Github.

Ambaŭ komandoj subtenas aŭtomatan kompletigon de kuntekstaj kaj nomspacaj nomoj, kio forigas la bezonon tute tajpi ilin. Instrukcioj por agordo de aŭtomata kompletigo tie.

Alia utila trajto kubectx Estas interaga reĝimo. Ĝi funkcias kune kun la utileco fzf, kiu devas esti instalita aparte. Instali fzf aŭtomate disponigas interagan reĝimon en kubectx. Interage, vi povas elekti kuntekston kaj nomspacon per la interaga senpaga serĉinterfaco provizita de fzf.

Uzante ŝelajn kaŝnomojn

Vi ne bezonas apartajn ilojn por ŝanĝi la nunan kuntekston kaj nomspacon ĉar kubectl ankaŭ provizas komandojn por tio. Jes, teamo kubectl config provizas subkomandojn por redakti kubeconfig dosierojn.

Jen kelkaj el ili:

kubectl config get-contexts: montri ĉiujn kuntekstojn;
kubectl config current-context: akiri aktualan kuntekston;
kubectl config use-context: ŝanĝi nunan kuntekston;
kubectl config set-context: Ŝanĝi kuntekstan elementon.

Tamen uzi ĉi tiujn komandojn rekte ne estas tre oportuna ĉar ili estas longaj. Vi povas fari ŝelajn kaŝnomojn por ili, kiuj estas facile ekzekuteblaj.

Mi kreis aron da kaŝnomoj bazitaj sur ĉi tiuj komandoj, kiuj provizas funkciojn similajn al kubectx. Ĉi tie vi povas vidi ilin en ago:

Notu, ke kaŝnomoj uzas fzf por disponigi interagan liberan serĉinterfacon (kiel la interaga reĝimo de kubectx). Ĉi tio signifas, ke vi bezonas instali fzfuzi ĉi tiujn kaŝnomojn.

Jen la difinoj de kaŝnomoj mem:

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

Por agordi ĉi tiujn kaŝnomojn vi devas aldoni la suprajn difinojn al via dosiero ~/.bashrc aŭ ~/.zshrc kaj rekomencu vian ŝelon.

Uzante kromaĵojn

Kubectl permesas al vi ŝargi kromaĵojn, kiuj estas ekzekutitaj en la sama maniero kiel bazaj komandoj. Vi povas, ekzemple, instali la kromprogramon kubectl-foo kaj ruli ĝin per ekzekuto de la komando kubectl foo.

Estus oportune ŝanĝi la kuntekston kaj nomspacon tiamaniere, ekzemple per rulado kubectl ctx ŝanĝi kuntekston kaj kubectl ns por ŝanĝi la nomspacon.

Mi skribis du kromaĵojn kiuj faras ĉi tion:

La laboro de kromprogramoj baziĝas sur kaŝnomoj de la antaŭa sekcio.

Jen kiel ili funkcias:

Notu, ke la kromprogramoj uzas fzf por provizi interagan senpagan serĉinterfacon (kiel la interaga reĝimo de kubectx). Ĉi tio signifas, ke vi bezonas instali fzfuzi ĉi tiujn kaŝnomojn.

Por instali kromaĵojn, vi devas elŝuti ŝelajn skriptojn nomitajn kubectl-ctx и kubectl-ns al iu ajn dosierujo en via PATH-variablo kaj faru ilin plenumeblaj per ekz. chmod +x. Tuj post tio vi povos uzi kubectl ctx и kubectl ns.

5. Redukti enigon per aŭto-aliasoj

Ŝelaj kaŝnomoj estas bona maniero por akceli enigon. Projekto kubectl-aliases enhavas ĉirkaŭ 800 ŝparvojojn por bazaj kubectl-komandoj.

Vi eble scivolas - kiel vi memoras 800 kaŝnomojn? Sed vi ne bezonas memori ilin ĉiujn, ĉar ili estas konstruitaj laŭ simpla skemo, kiu estas donita sube:

Ekzemple:

kgpooyaml - kubectl get pods oyaml
ksysgsvcw — kubectl -n kube-sistemo get svc w
ksysrmcm -kubectl -n kube-sistemo rm cm
kgdepallsl - kubectl akiri deplojon ĉion sl

Kiel vi povas vidi, kaŝnomoj konsistas el komponantoj, ĉiu el kiuj reprezentas specifan elementon de la komando kubectl. Ĉiu kaŝnomo povas havi unu komponenton por la baza komando, operacio kaj rimedo, kaj plurajn komponentojn por parametroj. Vi simple "populu" ĉi tiujn komponantojn de maldekstre dekstren laŭ la supra diagramo.

La nuna detala diagramo estas ĉe GitHub. Tie vi ankaŭ povas trovi plena listo de kaŝnomoj.

Ekzemple, la kaŝnomo kgpooyamlall estas ekvivalenta al la komando kubectl get pods -o yaml --all-namespaces.

La relativa ordo de la opcioj ne gravas: komando kgpooyamlall estas ekvivalenta al la komando kgpoalloyaml.

Vi ne devas uzi ĉiujn komponantojn kiel kaŝnomojn. Ekzemple k, kg, klo, ksys, kgpo ankaŭ povas esti uzata. Plie, vi povas kombini kaŝnomojn kaj regulajn komandojn aŭ opciojn sur la komandlinio:

Ekzemple:

Anstataŭe kubectl proxy vi povas skribi k proxy.
Anstataŭe kubectl get roles vi povas skribi kg roles (aktuale ne ekzistas kaŝnomo por la rimedo Roloj).
Por akiri datumojn por specifa pod, vi povas uzi la komandon kgpo my-pod — kubectl get pod my-pod.

Bonvolu noti, ke iuj kaŝnomoj postulas komandlinian argumenton. Ekzemple, kaŝnomo kgpol signifas kubectl get pods -l. Opcio -l postulas argumenton - etikedspecifon. Se vi uzas kaŝnomon, ĝi aspektos kiel kgpol app=ui.

Ĉar iuj kaŝnomoj postulas argumentojn, kaŝnomoj a, f, kaj l devas esti uzataj laste.

Ĝenerale, post kiam vi ekkomprenas ĉi tiun skemon, vi povas intuicie derivi kaŝnomojn de la komandoj, kiujn vi volas plenumi, kaj ŝpari multe da tajpado.

Instalado

Por instali kubectl-aliases, vi devas elŝuti la dosieron .kubectl_aliases de GitHub kaj inkluzivu ĝin en la dosieron ~/.bashrc aŭ ~/.zshrc:

source ~/.kubectl_aliases

Aŭtomata kompletigo

Kiel ni diris antaŭe, vi ofte aldonas pliajn vortojn al kaŝnomo sur la komandlinio. Ekzemple:

$ kgpooyaml test-pod-d4b77b989

Se vi uzas kubectl-koman kompletigon, vi verŝajne uzis aŭtomatan kompletigon por aferoj kiel nomoj de rimedoj. Sed ĉu oni povas tion fari kiam oni uzas kaŝnomojn?

Ĉi tio estas tre grava demando ĉar se aŭtomata kompletigo ne funkcias, vi perdos kelkajn el la avantaĝoj de kaŝnomoj.

La respondo dependas de kiu ŝelo vi uzas:

Por Zsh, kaŝnomo-kompletigo funkcias el la skatolo.
Por Bash, bedaŭrinde, necesas iom da laboro por ke aŭtomata kompletigo funkciu.

Ebligante aŭtomatan kompletigo por kaŝnomoj en Bash

La problemo kun Bash estas ke ĝi provas kompletigi (ĉiufoje kiam vi premas Tab) la kaŝnomon, ne la komandon al kiu la kaŝnomo rilatas (kiel Zsh faras, ekzemple). Ĉar vi ne havas kompletigskriptojn por ĉiuj 800 kaŝnomoj, aŭtomata kompletigo ne funkcias.

La projekto kompleta-alias donas ĝeneralan solvon al ĉi tiu problemo. Ĝi konektas al la kompletigmekanismo por kaŝnomoj, interne vastigas la kaŝnomon al komando, kaj resendas kompletigopciojn por la finita komando. Ĉi tio signifas, ke la kompletigo por kaŝnomo kondutas ĝuste same kiel por plena komando.

En la sekvanta, mi unue klarigos kiel instali complete-alias kaj poste kiel agordi ĝin por ebligi kompletigo por ĉiuj kubectl-kaŝnomoj.

Instalante complete-alias

Antaŭ ĉio, kompleta-alias dependas de bash-kompletigo. Tial antaŭ ol instali complete-alias, vi devas certigi, ke bash-completion estas instalita. Instalaj instrukcioj estis disponigitaj antaŭe por Linukso kaj MacOS.

Grava Noto por MacOS-Uzantoj: Kiel la kubectl-aŭtomatkompleta skripto, complete-alias ne funkcias kun Bash 3.2, kiu estas la defaŭlta en MacOS. Aparte, kompleta-kaŝnomo dependas de bash-completion v2 (brew install bash-completion@2), kiu postulas almenaŭ Bash 4.1. Ĉi tio signifas, ke por uzi kompletan kaŝnomon en MacOS, vi devas instali pli novan version de Bash.

Vi devas elŝuti la skripton bash_completion.sh el GitHub-deponejo kaj inkluzivu ĝin en vian dosieron ~/.bashrc:

source ~/bash_completion.sh

Post rekomenco de la ŝelo, kompleta-alias estos plene instalita.

Ebligante aŭtomatan kompletigo por kubectl-kaŝnomoj

Teknike kompleta-kaŝnomo disponigas envolvaĵfunkcion _complete_alias. Ĉi tiu funkcio kontrolas la kaŝnomon kaj resendas kompletigajn sugestojn por la kaŝnomo-komando.

Por asocii funkcion kun specifa kaŝnomo, vi devas uzi la enkonstruitan Bash-mekanismon kompletan, instali _complete_alias kiel kaŝnomo-kompletiga funkcio.

Kiel ekzemplo, ni prenu la kaŝnomon k, kiu signifas la komandon kubectl. instali _complete_alias Kiel komplementa funkcio por ĉi tiu kaŝnomo, vi devus ruli la sekvan komandon:

$ complete -F _complete_alias k

La rezulto de tio estas ke kiam ajn vi aŭtomate kompletigas kaŝnomon k, la funkcio estas vokita _complete_alias, kiu kontrolas la kaŝnomon kaj resendas kompletigajn sugestojn por la komando kubectl.

Kiel dua ekzemplo, ni prenu la kaŝnomon kg, kiu indikas kubectl get:

$ complete -F _complete_alias kg

Same kiel en la antaŭa ekzemplo, kiam vi aŭtomate kompletigas kg, vi ricevas la samajn kompletigajn sugestojn, kiujn vi ricevus por kubectl get.

Notu, ke vi povas uzi complete-alias por iu ajn kaŝnomo en via sistemo.

Tial, por ebligi aŭtomatan kompletigon por ĉiuj kubectl-kaŝnomoj, vi devas ruli la supran komandon por ĉiu el ili. La sekva fragmento faras ĝuste tion, kondiĉe ke vi agordis kubectl-aliases al ~/.kubectl-aliases:

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

Ĉi tiu kodo devas esti metita en vian ~/.bashrc, rekomencu la komandan ŝelon kaj aŭtomata kompletigo estos disponebla por ĉiuj 800 kubectl-kaŝnomo.

6. Etendante kubectl kun kromaĵojn

Komencante de versio 1.12, kubectl subtenas kromaĵo mekanismo, kiuj ebligas al vi vastigi ĝiajn funkciojn per pliaj komandoj.

Se vi konas Mekanismoj de Git-kromaĵo, tiam kubectl-aldonaĵoj estas konstruitaj laŭ la sama principo.

En ĉi tiu ĉapitro, ni kovros kiel instali kromaĵojn, kie trovi ilin kaj kiel krei viajn proprajn kromaĵojn.

Instalante kromaĵojn

Kubectl-kromaĵoj estas distribuitaj kiel simplaj ruleblaj dosieroj kun la nomo kiel kubectl-x. Prefikso kubectl- estas postulata, sekvata de nova kubectl-subkomando, kiu ebligas al vi voki la kromprogramon.

Ekzemple, la saluta kromaĵo estos distribuita kiel dosiero nomata kubectl-hello.

Por instali la kromprogramon, vi devas kopii la dosieron kubectl-x al iu ajn dosierujo en via PATH kaj faru ĝin efektivigebla, ekzemple per chmod +x. Tuj post tio vi povas voki la kromprogramon per kubectl x.

Vi povas uzi la jenan komandon por listigi ĉiujn kromaĵojn kiuj estas nuntempe instalitaj en via sistemo:

$ kubectl plugin list

Ĉi tiu komando ankaŭ montros avertojn se vi havas plurajn kromnomojn kun la sama nomo, aŭ se estas dosiero de aldonaĵoj ne plenumebla.

Trovi kaj instali kromaĵojn uzante Krew

Kubectl-kromaĵoj povas esti dividitaj aŭ reuzitaj kiel programarpakaĵoj. Sed kie vi povas trovi kromaĵojn, kiujn aliaj dividis?

Projekto Krew celas provizi unuigitan solvon por kunhavigi, serĉi, instali kaj administri kubectl-kromaĵojn. La projekto nomas sin "paka administranto por kubectl-aldonaĵoj" (Krew similas al Brew).

Krew estas listo de kubectl-kromaĵoj, kiujn vi povas elekti kaj instali. Samtempe, Krew ankaŭ estas kromaĵo por kubectl.

Ĉi tio signifas, ke instali Krew funkcias esence kiel instali ajnan alian kubectl-kromaĵon. Vi povas trovi detalajn instrukciojn ĉe Paĝo de GitHub.

La plej gravaj Krew-komandoj estas:

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

Bonvolu noti, ke instali kromaĵojn per Krew ne malhelpas instali kromaĵojn per la norma metodo priskribita supre.

Bonvolu noti, ke la komando kubectl krew list nur montras kromaĵojn kiuj estis instalitaj uzante Krew, dum la komando kubectl plugin list listigas ĉiujn kromaĵojn, tio estas, tiujn instalitajn per Krew kaj tiujn instalitajn per aliaj metodoj.

Trovi Kromaĵojn Aliloke

Krew estas juna projekto, nuntempe en sia la listo nur ĉirkaŭ 30 kromaĵojn. Se vi ne povas trovi tion, kion vi bezonas, vi povas trovi kromaĵojn aliloke, kiel GitHub.

Mi rekomendas rigardi la GitHub-sekcion kubectl-kromaĵoj. Tie vi trovos dekojn da disponeblaj kromprogramoj, kiujn indas kontroli.

Skribante viajn proprajn kromaĵojn

vi povas mem krei kromaĵojn - Ne estas malfacile. Vi devas krei plenumeblan, kiu faras tion, kion vi bezonas, nomu ĝin kiel kubectl-x kaj instalu kiel priskribite supre.

La dosiero povus esti bash-skripto, python-skripto aŭ kompilita GO-apliko - ne gravas. La sola kondiĉo estas, ke ĝi povas esti rekte ekzekutita en la operaciumo.

Ni kreu ekzemplan kromprogramon nun. En la antaŭa sekcio, vi uzis la komandon kubectl por listigi la ujojn por ĉiu pod. Estas facile turni ĉi tiun komandon en kromprogramon, kiun vi povas voki per ekz. kubectl img.

Kreu dosieron kubectl-img jena enhavo:

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

Nun faru la dosieron plenumebla per chmod +x kubectl-img kaj movu ĝin al iu ajn dosierujo en via PATH. Tuj post tio vi povas uzi la kromprogramon kubectl img.

Kiel menciite, kubectl-aldonaĵoj povas esti skribitaj en iu ajn programado aŭ skriptlingvo. Se vi uzas ŝelajn skriptojn, la avantaĝo de povi facile voki kubectl de ene de la kromaĵo. Tamen, vi povas skribi pli kompleksajn kromaĵojn en realaj programlingvoj uzante Kubernetes-klienta biblioteko. Se vi uzas Go, vi ankaŭ povas uzi cli-runtime biblioteko, kiu ekzistas specife por verki kubectl-kromaĵojn.

Kiel dividi viajn kromaĵojn

Se vi pensas, ke viaj kromprogramoj povus esti utilaj al aliaj, bonvolu dividi ĝin en GitHub. Nepre aldonu ilin al la temo kubectl-kromaĵoj.

Vi ankaŭ povas peti, ke via kromaĵo estu aldonita al Krew listo. Instrukcioj pri kiel fari tion estas en GitHub-deponejoj.

Kompletigo de komando

Kromaĵoj nuntempe ne subtenas aŭtomatan kompletigon. Tio estas, vi devas enigi la plenan nomon de la kromaĵo kaj la plenajn nomojn de la argumentoj.

La GitHub kubectl-deponejo por ĉi tiu funkcio havas malferma peto. Do eblas, ke ĉi tiu funkcio estos efektivigita iam en la estonteco.

Bonŝancon!!!

Kion alian legi pri la temo:

fonto: www.habr.com

Kiel uzi kubectl pli efike: detala gvidilo