🥇Paano gamitin ang kubectl nang mas epektibo: isang detalyadong gabay

Kung nagtatrabaho ka sa Kubernetes, malamang na ang kubectl ay isa sa mga utility na madalas mong ginagamit. At sa tuwing gumugugol ka ng maraming oras sa pagtatrabaho gamit ang isang partikular na tool, sulit na pag-aralan itong mabuti at matutunan kung paano gamitin ito nang epektibo.

Koponan Kubernetes aaS mula sa Mail.ru isinalin ang isang artikulo ni Daniel Weibel kung saan makakahanap ka ng mga tip at trick para sa epektibong pagtatrabaho sa kubectl. Makakatulong din ito sa iyo na magkaroon ng mas malalim na pag-unawa sa Kubernetes.

Ayon sa may-akda, ang layunin ng artikulo ay gawing hindi lamang mas mahusay ang iyong pang-araw-araw na gawain kasama ang Kubernetes, ngunit mas kasiya-siya din!

Panimula: Ano ang kubectl

Bago mo matutunang gamitin ang kubectl nang mas epektibo, kailangan mong magkaroon ng pangunahing pag-unawa sa kung ano ito at kung paano ito gumagana.

Mula sa pananaw ng isang user, ang kubectl ay isang control panel na nagbibigay-daan sa iyong magsagawa ng mga operasyon ng Kubernetes.

Sa teknikal na pagsasalita, ang kubectl ay isang kliyente ng Kubernetes API.

Ang Kubernetes API ay isang HTTP REST API. Ang API na ito ay ang tunay na user interface ng Kubernetes, kung saan ito ay ganap na kinokontrol. Nangangahulugan ito na ang bawat operasyon ng Kubernetes ay nakalantad bilang isang endpoint ng API at maaaring gawin gamit ang isang kahilingan sa HTTP sa endpoint na iyon.

Samakatuwid, ang pangunahing trabaho ng kubectl ay gumawa ng mga kahilingan sa HTTP sa Kubernetes API:

Ang Kubernetes ay isang ganap na resource-oriented system. Nangangahulugan ito na pinapanatili nito ang panloob na estado ng mga mapagkukunan at lahat ng pagpapatakbo ng Kubernetes ay mga pagpapatakbo ng CRUD.

Ikaw ay may kumpletong kontrol sa Kubernetes sa pamamagitan ng pamamahala sa mga mapagkukunang ito, at ang Kubernetes ay nag-iisip kung ano ang gagawin batay sa kasalukuyang estado ng mga mapagkukunan. Para sa kadahilanang ito, ang sanggunian ng Kubernetes API ay isinaayos bilang isang listahan ng mga uri ng mapagkukunan kasama ng kanilang mga nauugnay na operasyon.

Tingnan natin ang isang halimbawa.

Sabihin nating gusto mong lumikha ng mapagkukunan ng ReplicaSet. Upang gawin ito, ilarawan mo ang ReplicaSet sa isang file ayon sa pangalan replicaset.yaml, pagkatapos ay patakbuhin ang command:

$ kubectl create -f replicaset.yaml

Gagawa ito ng mapagkukunan ng ReplicaSet. Ngunit ano ang nangyayari sa likod ng mga eksena?

Ang Kubernetes ay may operasyon sa paggawa ng ReplicaSet. Tulad ng anumang iba pang operasyon, nakalantad ito bilang isang endpoint ng API. Ang partikular na endpoint ng API para sa operasyong ito ay ganito ang hitsura:

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

Ang mga endpoint ng API para sa lahat ng operasyon ng Kubernetes ay matatagpuan sa Sanggunian ng API (kabilang ang ang endpoint sa itaas). Upang gumawa ng aktwal na kahilingan sa isang endpoint, dapat mo munang idagdag ang URL ng server ng API sa mga endpoint path na nakalista sa reference ng API.

Kaya, kapag isinagawa mo ang utos sa itaas, nagpapadala ang kubectl ng kahilingan sa HTTP POST sa endpoint ng API sa itaas. Ang kahulugan ng ReplicaSet na ibinigay mo sa file replicaset.yaml, ay ipinadala sa katawan ng kahilingan.

Ganito gumagana ang kubectl para sa lahat ng command na nakikipag-ugnayan sa cluster ng Kubernetes. Sa lahat ng mga kasong ito, gumagawa lang ang kubectl ng mga kahilingan sa HTTP sa naaangkop na mga endpoint ng Kubernetes API.

Pakitandaan na maaari mong ganap na pamahalaan ang Kubernetes gamit ang isang utility gaya ng curlsa pamamagitan ng manu-manong pagpapadala ng mga kahilingan sa HTTP sa Kubernetes API. Pinapadali lang ng Kubectl na gamitin ang Kubernetes API.

Ito ang mga pangunahing kaalaman kung ano ang kubectl at kung paano ito gumagana. Ngunit may iba pa tungkol sa Kubernetes API na dapat malaman ng bawat gumagamit ng kubectl. Tingnan natin ang inner world ng Kubernetes.

Ang panloob na mundo ng Kubernetes

Ang Kubernetes ay binubuo ng isang set ng mga independiyenteng bahagi na tumatakbo bilang magkahiwalay na proseso sa mga cluster node. Ang ilang mga bahagi ay tumatakbo sa mga master node, ang iba sa mga node ng manggagawa, ang bawat bahagi ay gumaganap ng sarili nitong partikular na gawain.

Narito ang pinakamahalagang bahagi sa mga pangunahing node:

Imbakan - nag-iimbak ng mga kahulugan ng mapagkukunan (kadalasan ito ay etcd).
API server — nagbibigay ng API at namamahala ng storage.
Tagapamahala ng Controller — Tinitiyak na ang mga katayuan ng mapagkukunan ay sumusunod sa mga detalye.
Tagapag-iskedyul — nag-iskedyul ng mga pod sa mga node ng manggagawa.

At narito ang isang pinakamahalagang bahagi sa mga node ng manggagawa:

kubelet — namamahala sa paglulunsad ng mga lalagyan sa gumaganang node.

Upang maunawaan kung paano nagtutulungan ang mga bahaging ito, tingnan natin ang isang halimbawa.

Ipagpalagay natin na katatapos mo lang kubectl create -f replicaset.yaml, pagkatapos ay gumawa ng HTTP POST na kahilingan ang kubectl sa Endpoint ng ReplicaSet API (pagpapasa sa kahulugan ng mapagkukunan ng ReplicaSet).

Ano ang nangyayari sa kumpol?

Pagkatapos gawin kubectl create -f replicaset.yaml Iniimbak ng API server ang iyong ReplicaSet resource definition sa storage:
Susunod, ang ReplicaSet controller ay inilunsad sa controller manager, na humahawak sa paglikha, pagbabago at pagtanggal ng mga mapagkukunan ng ReplicaSet:
Ang ReplicaSet controller ay gumagawa ng pod definition para sa bawat ReplicaSet replica (ayon sa pod template sa ReplicaSet definition) at iniimbak ang mga ito sa storage:
Inilunsad ang scheduler, sinusubaybayan ang mga pod na hindi pa nakatalaga sa anumang worker node:
Ang scheduler ay pumipili ng angkop na worker node para sa bawat pod at idinaragdag ang impormasyong ito sa pod definition sa store:
Sa worker node kung saan nakatalaga ang pod, inilunsad ang Kubelet, sinusubaybayan nito ang mga pod na nakatalaga sa node na ito:
Ang Kubelet ay nagbabasa ng pod definition mula sa storage at nagtuturo sa isang container runtime, gaya ng Docker, na maglunsad ng mga container sa node:

Nasa ibaba ang isang tekstong bersyon ng paglalarawang ito.

Ang kahilingan ng API sa endpoint ng paglikha ng ReplicaSet ay pinoproseso ng API server. Ang API server ay nagpapatotoo sa kahilingan at nag-iimbak ng ReplicaSet resource definition sa storage.

Sinisimulan ng kaganapang ito ang ReplicaSet controller, na isang subprocess ng controller manager. Sinusubaybayan ng controller ng ReplicaSet ang paggawa, pag-update, at pagtanggal ng mga mapagkukunan ng ReplicaSet sa store at tumatanggap ng notification ng kaganapan kapag nangyari ito.

Ang trabaho ng ReplicaSet controller ay tiyakin na ang kinakailangang bilang ng mga ReplicaSet pod ay umiiral. Sa aming halimbawa, wala pang mga pod, kaya ang ReplicaSet controller ay gumagawa ng mga pod definition na ito (ayon sa pod template sa ReplicaSet definition) at iniimbak ang mga ito sa storage.

Ang paglikha ng mga bagong pod ay na-trigger ng isang scheduler na sumusubaybay sa mga kahulugan ng pod na hindi pa nakaiskedyul para sa mga worker node. Ang scheduler ay pumipili ng angkop na worker node para sa bawat pod at ina-update ang mga kahulugan ng pod sa repository.

Tandaan na hanggang sa puntong ito, walang workload code na tumatakbo saanman sa cluster. Lahat ng nagawa hanggang ngayon - ito ang paglikha at pag-update ng mga mapagkukunan sa repository sa master node.

Ang huling kaganapan ay nagti-trigger sa Kubelets, na sumusubaybay sa mga pod na naka-iskedyul para sa kanilang mga worker node. Ang Kubelet ng worker node kung saan naka-install ang iyong ReplicaSet pods ay dapat magturo sa container runtime, gaya ng Docker, na i-download ang mga kinakailangang larawan ng container at patakbuhin ang mga ito.

Sa puntong ito, sa wakas ay tumatakbo na ang iyong ReplicaSet application!

Tungkulin ng Kubernetes API

Gaya ng nakita mo sa nakaraang halimbawa, ang mga bahagi ng Kubernetes (maliban sa API server at storage) ay nagbabantay ng mga pagbabago sa mga mapagkukunan sa storage at nagbabago ng impormasyon tungkol sa mga mapagkukunan sa storage.

Siyempre, hindi direktang nakikipag-ugnayan ang mga bahaging ito sa storage, ngunit sa pamamagitan lamang ng Kubernetes API.

Isaalang-alang ang sumusunod na mga halimbawa:

Ang ReplicaSet controller ay gumagamit ng API endpoint ilista ang ReplicaSets may parameter watch upang subaybayan ang mga pagbabago sa mga mapagkukunan ng ReplicaSet.
Ang ReplicaSet controller ay gumagamit ng API endpoint lumikha ng Pod (lumikha ng pod) upang lumikha ng mga pod.
Gumagamit ang scheduler ng API endpoint patch pod (edit pod) para i-update ang mga pod na may impormasyon tungkol sa napiling worker node.

Gaya ng nakikita mo, ito ang parehong API na ina-access ng kubectl. Ang paggamit ng parehong API para sa mga panloob na bahagi at panlabas na mga user ay isang pangunahing konsepto sa disenyo ng Kubernetes.

Ngayon ay maaari nating ibuod kung paano gumagana ang Kubernetes:

Ang mga tindahan ng imbakan ay nagsasaad, iyon ay, mga mapagkukunan ng Kubernetes.
Nagbibigay ang API server ng interface sa storage sa anyo ng Kubernetes API.
Ang lahat ng iba pang bahagi at user ng Kubernetes ay nagbabasa, nagmamasid, at nagmamanipula ng estado ng Kubernetes (mga mapagkukunan) sa pamamagitan ng API.

Ang pag-alam sa mga konseptong ito ay makakatulong sa iyong mas maunawaan ang kubectl at masulit ito.

Ngayon tingnan natin ang ilang partikular na tip at trick na makakatulong na mapabuti ang iyong pagiging produktibo sa kubectl.

1. Pabilisin ang pag-input gamit ang pagkumpleto ng command

Ang isa sa mga pinakakapaki-pakinabang, ngunit madalas na hindi pinapansin, mga diskarte para sa pagpapabuti ng pagganap sa kubectl ay ang pagkumpleto ng command.

Binibigyang-daan ka ng pagkumpleto ng command na awtomatikong kumpletuhin ang mga bahagi ng kubectl command gamit ang Tab key. Gumagana ito para sa mga subcommand, opsyon, at argumento, kabilang ang isang bagay na kasing kumplikado ng mga pangalan ng mapagkukunan.

Tingnan kung paano gumagana ang kubectl command completion:

Gumagana ang pagkumpleto ng command para sa Bash at Zsh shell.

Opisyal na gabay naglalaman ng mga detalyadong tagubilin para sa pag-set up ng autocompletion, ngunit sa ibaba ay magbibigay kami ng maikling sipi.

Paano gumagana ang pagkumpleto ng command

Ang pagkumpleto ng command ay isang tampok na shell na gumagana gamit ang isang script ng pagkumpleto. Ang extension script ay isang shell script na tumutukoy sa gawi ng isang extension para sa isang partikular na command.

Ang Kubectl ay awtomatikong bumubuo at naglalabas ng mga script ng extension para sa Bash at Zsh gamit ang mga sumusunod na command:

$ kubectl completion bash

Или:

$ kubectl completion zsh

Sa teorya, sapat na upang ikonekta ang output ng mga command na ito sa naaangkop na command shell upang ang kubectl ay makadagdag sa mga command.

Sa pagsasagawa, iba ang paraan ng koneksyon para sa Bash (kabilang ang mga pagkakaiba sa pagitan ng Linux at MacOS) at Zsh. Sa ibaba ay titingnan natin ang lahat ng mga pagpipiliang ito.

Bash sa Linux

Ang script ng Bash completion ay nakasalalay sa bash-completion package, kaya kailangan mo muna itong i-install:

$ sudo apt-get install bash-completion

Или:

$ yum install bash-completion

Maaari mong subukan na matagumpay na na-install ang package gamit ang sumusunod na command:

$ type _init_completion

Kung nag-output ito ng shell function code, pagkatapos ay mai-install nang tama ang bash-completion. Kung ang command ay nagbibigay ng error na "Not Found", kailangan mong idagdag ang sumusunod na linya sa iyong file ~ / .bashrc:

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

Kailangan bang idagdag ang linyang ito sa file ~ / .bashrc o hindi ay depende sa package manager na ginamit mo sa pag-install ng bash-completion. Ito ay kinakailangan para sa APT, ngunit hindi para sa YUM.

Pagkatapos i-install ang bash-completion, kailangan mong i-configure ang lahat para ma-enable ang kubectl completion script sa lahat ng shell session.

Ang isang paraan upang gawin ito ay idagdag ang sumusunod na linya sa file ~ / .bashrc:

source <(kubectl completion bash)

Ang isa pang paraan ay ang pagdaragdag ng kubectl extension script sa direktoryo /etc/bash_completion.d (lumikha ito kung wala ito):

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

Lahat ng mga add-on na script sa catalog /etc/bash_completion.d ay awtomatikong kasama sa bash-completion.

Parehong naaangkop ang parehong mga opsyon.

Pagkatapos i-restart ang shell, gagana ang kubectl command completion.

Bash sa MacOS

Sa MacOS ang setup ay medyo mas kumplikado. Ang katotohanan ay bilang default, ang MacOS ay gumagamit ng Bash na bersyon 3.2, at ang kubectl autocompletion script ay nangangailangan ng isang Bash na bersyon ng hindi bababa sa 4.1 at hindi gumagana sa Bash 3.2.

May mga isyu sa paglilisensya na nauugnay sa paggamit ng lumang bersyon ng Bash sa MacOS. Ang Bash version 4 ay lisensyado sa ilalim ng GPLv3, na hindi sinusuportahan ng Apple.

Upang i-configure ang kubectl autocompletion sa MacOS, kailangan mong mag-install ng mas bagong bersyon ng Bash. Maaari mo ring itakda ang na-update na Bash bilang iyong default na shell, na magliligtas sa iyo ng maraming problema sa hinaharap. Hindi ito mahirap, ang mga detalye ay ibinigay sa artikulo "Ina-update ang Bash sa MacOS'.

Bago magpatuloy, tiyaking gumagamit ka ng kamakailang bersyon ng Bash (tingnan ang output bash --version).

Ang script ng pagkumpleto ng Bash ay nag-iiba ayon sa proyekto bash-completion, kaya kailangan mo muna itong i-install.

Maaari kang mag-install ng bash-completion gamit ang homebrew:

$ brew install bash-completion@2

Dito @2 ibig sabihin ay bash-completion na bersyon 2. ang kubectl autocompletion ay nangangailangan ng bash-completion v2, at ang bash-completion v2 ay nangangailangan ng isang minimum na Bash na bersyon 4.1.

Output ng command brew-install naglalaman ng seksyon ng Caveats, na tumutukoy kung ano ang kailangang idagdag sa file ~/.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"

Gayunpaman, inirerekumenda kong huwag idagdag ang mga linyang ito ~/.bash_profileat sa ~/.bashrc. Sa kasong ito, ang autocompletion ay magagamit hindi lamang sa pangunahing, kundi pati na rin sa mga shell ng command ng bata.

Pagkatapos i-restart ang command shell, maaari mong i-verify na tama ang pag-install gamit ang sumusunod na command:

$ type _init_completion

Kung nakakita ka ng isang function ng shell sa output, kung gayon ang lahat ay na-configure nang tama.

Ngayon ay kailangan nating tiyakin na ang kubectl autocompletion ay pinagana sa lahat ng session.

Ang isang paraan ay idagdag ang sumusunod na linya sa iyong ~/.bashrc:

source <(kubectl completion bash)

Ang pangalawang paraan ay ang magdagdag ng autocomplete na script sa folder /usr/local/etc/bash_completion.d:

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

Gagana lang ang paraang ito kung nag-install ka ng bash-completion gamit ang Homebrew. Sa kasong ito, nilo-load ng bash-completion ang lahat ng script mula sa direktoryong ito.

Kung nag-install ka kubectl gamit ang Homebrew, pagkatapos ay hindi na kailangang gawin ang nakaraang hakbang, dahil ang autocompletion script ay awtomatikong ilalagay sa folder /usr/local/etc/bash_completion.d sa panahon ng pag-install. Sa kasong ito, magsisimulang gumana ang kubectl autocompletion sa sandaling mag-install ka ng bash-completion.

Bilang resulta, ang lahat ng mga pagpipiliang ito ay katumbas.

zsh

Ang mga autocompletion script para sa Zsh ay hindi nangangailangan ng anumang dependencies. Ang kailangan mo lang gawin ay paganahin ang mga ito kapag na-load mo ang command shell.

Magagawa mo ito sa pamamagitan ng pagdaragdag ng linya sa iyong ~/.zshrc file:

source <(kubectl completion zsh)

Kung nakatanggap ka ng error not found: compdef pagkatapos i-restart ang iyong shell, kailangan mong paganahin ang builtin function compdef. Maaari mo itong paganahin sa pamamagitan ng pagdaragdag nito sa simula ng iyong file ~/.zshrc ang mga sumusunod:

autoload -Uz compinit
compinit

2. Mabilis na tingnan ang mga pagtutukoy ng mapagkukunan

Kapag gumawa ka ng mga kahulugan ng mapagkukunan ng YAML, kailangan mong malaman ang mga field at ang kahulugan ng mga ito para sa mga mapagkukunang iyon. Ang isang lugar upang hanapin ang impormasyong ito ay nasa sanggunian ng API, na naglalaman ng mga kumpletong detalye para sa lahat ng mapagkukunan.

Gayunpaman, ang paglipat sa web browser sa tuwing kailangan mong maghanap ng isang bagay ay hindi maginhawa. Samakatuwid ang kubectl ay nagbibigay ng utos kubectl explain, na nagpapakita ng mga detalye ng lahat ng mapagkukunan sa mismong terminal mo.

Ang format ng command ay ang mga sumusunod:

$ kubectl explain resource[.field]...

Ilalabas ng command ang detalye ng hiniling na mapagkukunan o field. Ang impormasyong ipinapakita ay kapareho ng nasa manwal ng API.

По умолчанию kubectl explain ipinapakita lamang ang unang antas ng nesting ng mga patlang.

Tingnan kung ano ang hitsura nito Pagkatapos ay maaari mong.

Maaari mong ipakita ang buong puno kung idaragdag mo ang opsyon --recursive:

$ kubectl explain deployment.spec --recursive

Kung hindi mo alam kung aling mga mapagkukunan ang kailangan, maaari mong ipakita ang lahat ng ito gamit ang sumusunod na command:

$ kubectl api-resources

Ang command na ito ay nagpapakita ng mga pangalan ng mapagkukunan sa plural na anyo, hal. deployments sa halip ng deployment. Ipinapakita rin nito ang maikling pangalan, halimbawa deploy, para sa mga mapagkukunang mayroon nito. Huwag mag-alala tungkol sa mga pagkakaibang ito. Ang lahat ng mga pagpipilian sa pagbibigay ng pangalan ay katumbas para sa kubectl. Iyon ay, maaari mong gamitin ang alinman sa mga ito para sa kubectl explain.

Ang lahat ng mga sumusunod na utos ay katumbas:

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

3. Gumamit ng custom na format ng output ng column

Default na format ng output ng command 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

Maginhawa ang format na ito, ngunit naglalaman ito ng limitadong halaga ng impormasyon. Kung ikukumpara sa buong format ng kahulugan ng mapagkukunan, iilan lang ang mga field na ipinapakita dito.

Sa kasong ito, maaari kang gumamit ng custom na format ng output ng column. Pinapayagan ka nitong matukoy kung anong data ang ilalabas. Maaari mong ipakita ang anumang field ng mapagkukunan bilang isang hiwalay na column.

Ang paggamit ng custom na format ay tinutukoy gamit ang mga opsyon:

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

Maaari mong tukuyin ang bawat column ng output bilang isang pares <header>:<jsonpath>Saan <header> ay ang pangalan ng hanay, at <jsonpath> — isang expression na tumutukoy sa isang larangan ng mapagkukunan.

Tingnan natin ang isang simpleng halimbawa:

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

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

Ang output ay naglalaman ng isang column na may mga pangalan ng mga pod.

Pinipili ng expression ng opsyon ang mga pangalan ng pod mula sa field metadata.name. Ito ay dahil ang pangalan ng pod ay tinukoy sa field ng pangalan ng bata metadata sa paglalarawan ng mapagkukunan ng pod. Higit pang mga detalye ay matatagpuan sa Gabay sa API o i-type ang utos kubectl explain pod.metadata.name.

Ngayon sabihin nating gusto mong magdagdag ng dagdag na column sa output, halimbawa na nagpapakita ng node kung saan tumatakbo ang bawat pod. Upang gawin ito, maaari mo lamang idagdag ang naaangkop na detalye ng column sa opsyong custom na column:

$ 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

Pinipili ng expression ang pangalan ng node mula sa spec.nodeName — kapag ang isang pod ay itinalaga sa isang node, ang pangalan nito ay nakasulat sa field spec.nodeName detalye ng mapagkukunan ng pod. Ang mas detalyadong impormasyon ay matatagpuan sa output kubectl explain pod.spec.nodeName.

Pakitandaan na ang mga field ng mapagkukunan ng Kubernetes ay case sensitive.

Maaari mong tingnan ang anumang field ng mapagkukunan bilang isang column. Suriin lamang ang detalye ng mapagkukunan at subukan ito sa anumang mga field na gusto mo.

Ngunit una, tingnan natin ang mga expression ng pagpili ng field.

Mga Ekspresyon ng JSONPath

Ang mga expression para sa pagpili ng mga field ng mapagkukunan ay batay sa JSONPath.

Ang JSONPath ay isang wika para sa pagkuha ng data mula sa mga dokumento ng JSON. Ang pagpili ng isang field ay ang pinakasimpleng use case para sa JSONPath. Marami siya mas maraming posibilidad, kabilang ang mga tagapili, mga filter at iba pa.

Sinusuportahan ng Kubectl explain ang limitadong bilang ng mga feature ng JSONPath. Ang mga posibilidad at halimbawa ng kanilang paggamit ay inilarawan sa ibaba:

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

Ang [] operator ay lalong mahalaga. Maraming mga field ng mapagkukunan ng Kubernetes ang mga listahan, at pinapayagan ka ng operator na ito na pumili ng mga miyembro ng mga listahang iyon. Madalas itong ginagamit kasama ng wildcard tulad ng [*] upang piliin ang lahat ng elemento ng isang listahan.

Mga halimbawa ng aplikasyon

Ang mga posibilidad para sa paggamit ng custom na format ng output ng column ay walang katapusan, dahil maaari mong ipakita ang anumang field o kumbinasyon ng mga field ng mapagkukunan sa output. Narito ang ilang sample na app, ngunit huwag mag-atubiling i-explore ang mga ito at maghanap ng mga application na gumagana para sa iyo.

Ipinapakita ang mga larawan ng lalagyan para sa mga pod:

$ 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

Ipinapakita ng command na ito ang mga pangalan ng imahe ng lalagyan para sa bawat pod.

Tandaan na ang isang pod ay maaaring maglaman ng ilang lalagyan, pagkatapos ay ipapakita ang mga pangalan ng larawan sa isang linya, na pinaghihiwalay ng mga kuwit.

Ipinapakita ang mga node availability zone:
```
$ 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
```
Kapaki-pakinabang ang command na ito kung naka-host ang iyong cluster sa isang pampublikong cloud. Ipinapakita nito ang availability zone para sa bawat node.

Ang Availability zone ay isang cloud concept na naglilimita sa replication zone sa isang heyograpikong rehiyon.

Ang mga availability zone para sa bawat node ay nakuha sa pamamagitan ng isang espesyal na label - failure-domain.beta.kubernetes.io/zone. Kung ang cluster ay tumatakbo sa isang pampublikong ulap, ang label na ito ay awtomatikong nilikha at napupunan ng mga pangalan ng mga availability zone para sa bawat node.

Ang mga label ay hindi bahagi ng detalye ng mapagkukunan ng Kubernetes, kaya hindi ka makakahanap ng impormasyon tungkol sa mga ito Gabay sa API. Gayunpaman, makikita ang mga ito (tulad ng anumang iba pang mga label) kung humiling ka ng impormasyon tungkol sa mga node sa YAML o JSON na format:
```
$ kubectl get nodes -o yaml
# или
$ kubectl get nodes -o json
```
Ito ay isang mahusay na paraan upang matuto nang higit pa tungkol sa mga mapagkukunan, bilang karagdagan sa pag-aaral ng mga detalye ng mapagkukunan.

4. Madaling lumipat sa pagitan ng mga cluster at namespace

Kapag humiling ang kubectl sa Kubernetes API, babasahin muna nito ang kubeconfig file upang makuha ang lahat ng kinakailangang parameter para sa koneksyon.

Bilang default, ang kubeconfig file ay ~/.kube/config. Karaniwan ang file na ito ay nilikha o ina-update sa pamamagitan ng isang espesyal na utos.

Kapag nagtatrabaho ka sa maraming cluster, naglalaman ang iyong kubeconfig file ng mga setting para sa pagkonekta sa lahat ng cluster na iyon. Kailangan mo ng paraan para sabihin sa kubectl command kung saang cluster ka nagtatrabaho.

Sa loob ng isang cluster, maaari kang lumikha ng maraming namespace—isang uri ng virtual cluster sa loob ng isang pisikal na cluster. Tinutukoy din ng Kubectl kung aling namespace ang gagamitin batay sa kubeconfig file. Nangangahulugan ito na kailangan mo rin ng isang paraan upang sabihin sa kubectl command kung anong namespace ang gagana.

Sa kabanatang ito ay ipapaliwanag namin kung paano ito gumagana at kung paano ito gagawing epektibo.

Tandaan na maaaring marami kang kubeconfig file na nakalista sa variable na kapaligiran ng KUBECONFIG. Sa kasong ito, ang lahat ng mga file na ito ay pagsasama-samahin sa isang karaniwang configuration sa runtime. Maaari mo ring baguhin ang default na kubeconfig file sa pamamagitan ng pagpapatakbo ng kubectl kasama ang parameter --kubeconfig. Tingnan mo opisyal na dokumentasyon.

kubeconfig file

Tingnan natin kung ano ang eksaktong nilalaman ng kubeconfig file:

Tulad ng nakikita mo, ang kubeconfig file ay naglalaman ng isang hanay ng mga konteksto. Ang konteksto ay binubuo ng tatlong elemento:

Cluster — API URL ng cluster server.
User - mga kredensyal sa pagpapatunay ng user sa cluster.
Namespace - ang namespace na ginagamit kapag sumali sa cluster.

Sa pagsasagawa, madalas silang gumagamit ng isang konteksto bawat kumpol sa kanilang kubeconfig. Gayunpaman, maaari kang magkaroon ng maraming konteksto sa bawat cluster, na pinag-iba ayon sa user o namespace. Gayunpaman, ang pagsasaayos ng maraming konteksto na ito ay hindi pangkaraniwan, kaya karaniwang may isa-sa-isang pagmamapa sa pagitan ng mga kumpol at konteksto.

Sa anumang partikular na oras, ang isa sa mga konteksto ay kasalukuyang:

Kapag nagbabasa ang kubectl ng configuration file, palagi itong kumukuha ng impormasyon mula sa kasalukuyang konteksto. Sa halimbawa sa itaas, ang kubectl ay kumonekta sa kumpol ng Hare.

Alinsunod dito, upang lumipat sa isa pang kumpol, kailangan mong baguhin ang kasalukuyang konteksto sa kubeconfig file:

Ngayon kubectl ay kumonekta sa Fox cluster.

Upang lumipat sa ibang namespace sa parehong cluster, kailangan mong baguhin ang halaga ng elemento ng namespace para sa kasalukuyang konteksto:

Sa halimbawa sa itaas, gagamitin ng kubectl ang Prod namespace ng Fox cluster (dati itinakda ang Test namespace).

Tandaan na ang kubectl ay nagbibigay din ng mga opsyon --cluster, --user, --namespace и --context, na nagpapahintulot sa iyo na i-overwrite ang mga indibidwal na elemento at ang kasalukuyang konteksto mismo, anuman ang itinakda sa kubeconfig. Tingnan mo kubectl options.

Sa teorya, maaari mong manu-manong baguhin ang mga setting sa kubeconfig. Ngunit ito ay hindi komportable. Upang gawing simple ang mga pagpapatakbong ito, mayroong iba't ibang mga utility na nagbibigay-daan sa iyong awtomatikong baguhin ang mga parameter.

Gumamit ng kubectx

Isang napakasikat na utility para sa paglipat sa pagitan ng mga cluster at namespace.

Ang utility ay nagbibigay ng mga utos kubectx и kubens upang baguhin ang kasalukuyang konteksto at namespace ayon sa pagkakabanggit.

Gaya ng nabanggit, ang pagpapalit ng kasalukuyang konteksto ay nangangahulugan ng pagbabago ng kumpol kung mayroon ka lamang isang konteksto sa bawat kumpol.

Narito ang isang halimbawa ng pagpapatakbo ng mga utos na ito:

Sa esensya, ang mga utos na ito ay i-edit lamang ang kubeconfig file tulad ng inilarawan sa itaas.

upang i-install kubectx, sundin ang mga tagubilin sa Github.

Sinusuportahan ng parehong command ang autocompletion ng mga pangalan ng konteksto at namespace, na nag-aalis ng pangangailangang ganap na i-type ang mga ito. Mga tagubilin para sa pag-set up ng autocompletion dito.

Isa pang kapaki-pakinabang na tampok kubectx ay interactive na mode. Gumagana ito kasabay ng utility fzf, na dapat na naka-install nang hiwalay. Ang pag-install ng fzf ay awtomatikong ginagawang magagamit ang interactive na mode kubectx. Sa interactive, maaari kang pumili ng konteksto at namespace sa pamamagitan ng interactive na libreng interface ng paghahanap na ibinigay ng fzf.

Paggamit ng mga shell alias

Hindi mo kailangan ng hiwalay na mga tool upang baguhin ang kasalukuyang konteksto at namespace dahil nagbibigay din ang kubectl ng mga utos para dito. Oo, koponan kubectl config nagbibigay ng mga subcommand para sa pag-edit ng mga kubeconfig file.

Narito ang ilan sa mga ito:

kubectl config get-contexts: ipakita ang lahat ng konteksto;
kubectl config current-context: kumuha ng kasalukuyang konteksto;
kubectl config use-context: baguhin ang kasalukuyang konteksto;
kubectl config set-context: Baguhin ang elemento ng konteksto.

Gayunpaman, ang direktang paggamit ng mga utos na ito ay hindi masyadong maginhawa dahil mahaba ang mga ito. Maaari kang gumawa ng mga shell alias para sa kanila na madaling isagawa.

Gumawa ako ng set ng mga alias batay sa mga command na ito na nagbibigay ng functionality na katulad ng kubectx. Dito makikita mo sila sa pagkilos:

Tandaan na ang mga alias ay gumagamit ng fzf upang magbigay ng interactive na libreng lookup interface (tulad ng interactive mode ng kubectx). Nangangahulugan ito na kailangan mo i-install ang fzfpara gamitin ang mga alias na ito.

Narito ang mga kahulugan ng mga alias mismo:

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

Upang itakda ang mga alias na ito kailangan mong idagdag ang mga kahulugan sa itaas sa iyong file ~/.bashrc o ~/.zshrc at i-reboot ang iyong shell.

Paggamit ng mga plugin

Binibigyang-daan ka ng Kubectl na mag-load ng mga plugin na isinasagawa sa parehong paraan tulad ng mga pangunahing utos. Maaari mong, halimbawa, i-install ang kubectl-foo plugin at patakbuhin ito sa pamamagitan ng pagsasagawa ng command kubectl foo.

Magiging maginhawang baguhin ang konteksto at namespace sa ganitong paraan, halimbawa sa pamamagitan ng pagtakbo kubectl ctx upang baguhin ang konteksto at kubectl ns upang baguhin ang namespace.

Sumulat ako ng dalawang plugin na gumagawa nito:

Ang gawain ng mga plugin ay batay sa mga alias mula sa nakaraang seksyon.

Narito kung paano sila gumagana:

Tandaan na ang mga plugin ay gumagamit ng fzf upang magbigay ng interactive na libreng interface ng paghahanap (tulad ng interactive mode ng kubectx). Ibig sabihin kailangan mo i-install ang fzfpara gamitin ang mga alias na ito.

Upang mag-install ng mga plugin, kailangan mong mag-download ng mga script ng shell na pinangalanan kubectl-ctx и kubectl-ns sa anumang direktoryo sa iyong PATH variable at gawin silang executable kasama ang hal. chmod +x. Kaagad pagkatapos nito ay magagamit mo na kubectl ctx и kubectl ns.

5. Bawasan ang input gamit ang mga autoaliases

Ang mga Shell alias ay isang magandang paraan para mapabilis ang pag-type. Proyekto kubectl-aliases naglalaman ng humigit-kumulang 800 mga shortcut para sa mga pangunahing kubectl command.

Maaaring nagtataka ka - paano mo naaalala ang 800 alyas? Ngunit hindi mo kailangang tandaan ang lahat, dahil ang mga ito ay binuo ayon sa isang simpleng pamamaraan, na ibinigay sa ibaba:

Halimbawa:

kgpooyaml - kubectl makakuha ng mga pod oyaml
ksysgsvcw — kubectl -n kube-system makakuha ng svc w
ksysrmcm -kubectl -n kube-system rm cm
kgdepallsl - kubectl makakuha ng deployment lahat ng sl

Gaya ng nakikita mo, ang mga alias ay binubuo ng mga bahagi, ang bawat isa ay kumakatawan sa isang partikular na elemento ng kubectl command. Ang bawat alyas ay maaaring magkaroon ng isang bahagi para sa base command, pagpapatakbo, at mapagkukunan, at maraming bahagi para sa mga parameter. "I-populate" mo lang ang mga bahaging ito mula kaliwa hanggang kanan ayon sa diagram sa itaas.

Ang kasalukuyang detalyadong diagram ay nasa GitHub. Doon mo rin mahahanap buong listahan ng mga alias.

Halimbawa, ang alias kgpooyamlall ay katumbas ng utos kubectl get pods -o yaml --all-namespaces.

Ang kamag-anak na pagkakasunud-sunod ng mga pagpipilian ay hindi mahalaga: command kgpooyamlall ay katumbas ng utos kgpoalloyaml.

Hindi mo kailangang gamitin ang lahat ng bahagi bilang mga alias. Halimbawa k, kg, klo, ksys, kgpo pwede ding gamitin. Bukod dito, maaari mong pagsamahin ang mga alias at regular na command o opsyon sa command line:

Halimbawa:

Sa halip ng kubectl proxy maaari kang magsulat k proxy.
Sa halip ng kubectl get roles maaari kang magsulat kg roles (kasalukuyang walang alias para sa mapagkukunang Tungkulin).
Upang makakuha ng data para sa isang partikular na pod, maaari mong gamitin ang command kgpo my-pod — kubectl get pod my-pod.

Pakitandaan na ang ilang mga alias ay nangangailangan ng argumento ng command line. Halimbawa, alyas kgpol paraan kubectl get pods -l. Pagpipilian -l nangangailangan ng argumento - isang detalye ng label. Kung gumamit ka ng alyas ito ang magiging hitsura kgpol app=ui.

Dahil ang ilang mga alias ay nangangailangan ng mga argumento, ang mga alias a, f, at l ay dapat na huling gamitin.

Sa pangkalahatan, kapag nasanay ka na sa scheme na ito, maaari mong madaling makuha ang mga alias mula sa mga command na gusto mong isagawa at makatipid ng maraming oras sa pag-type.

Pag-install

Upang i-install ang kubectl-aliases, kailangan mong i-download ang file .kubectl_aliases mula sa GitHub at isama ito sa file ~/.bashrc o ~/.zshrc:

source ~/.kubectl_aliases

Autocompletion

Tulad ng sinabi namin dati, madalas kang magdagdag ng mga karagdagang salita sa isang alias sa command line. Halimbawa:

$ kgpooyaml test-pod-d4b77b989

Kung gumagamit ka ng kubectl command completion, malamang na gumamit ka ng autocompletion para sa mga bagay tulad ng mga pangalan ng mapagkukunan. Ngunit magagawa ba ito kapag ginamit ang mga alias?

Ito ay isang napakahalagang tanong dahil kung hindi gagana ang autocompletion, mawawala sa iyo ang ilan sa mga benepisyo ng mga alias.

Ang sagot ay depende sa kung aling shell ang iyong ginagamit:

Para kay Zsh, gumagana sa labas ng kahon ang pagkumpleto ng alias.
Para sa Bash, sa kasamaang-palad, kailangan ang ilang trabaho para gumana ang autocompletion.

Paganahin ang autocompletion para sa mga alias sa Bash

Ang problema sa Bash ay sinusubukan nitong kumpletuhin (sa tuwing pinindot mo ang Tab) ang alias, hindi ang utos na tinutukoy ng alias (tulad ng ginagawa ni Zsh, halimbawa). Dahil wala kang completion script para sa lahat ng 800 alias, hindi gumagana ang autocompletion.

Proyekto kumpletong-alias nagbibigay ng pangkalahatang solusyon sa problemang ito. Kumokonekta ito sa mekanismo ng pagkumpleto para sa mga alias, panloob na pagpapalawak ng alias sa isang command, at ibinabalik ang mga opsyon sa pagkumpleto para sa nakumpletong command. Nangangahulugan ito na ang padding para sa isang alias ay kumikilos nang eksakto katulad ng para sa isang buong command.

Sa mga sumusunod, ipapaliwanag ko muna kung paano mag-install ng kumpletong-alias at pagkatapos ay kung paano i-configure ito upang paganahin ang pagkumpleto para sa lahat ng kubectl alias.

Pag-install ng kumpletong-alias

Una sa lahat, ang kumpletong-alias ay nakasalalay sa bash-completion. Samakatuwid, bago mag-install ng kumpletong-alias, kailangan mong tiyakin na naka-install ang bash-completion. Ang mga tagubilin sa pag-install ay naibigay na dati para sa Linux at MacOS.

Mahalagang Paalala para sa Mga Gumagamit ng MacOS: Tulad ng kubectl autocompletion script, ang complete-alias ay hindi gumagana sa Bash 3.2, na siyang default sa MacOS. Sa partikular, ang kumpletong-alias ay nakasalalay sa bash-completion v2 (brew install bash-completion@2), na nangangailangan ng hindi bababa sa Bash 4.1. Nangangahulugan ito na para gumamit ng kumpletong-alias sa MacOS kailangan mong mag-install ng mas bagong bersyon ng Bash.

Kailangan mong i-download ang script bash_completion.sh ng GitHub repository at isama ito sa iyong file ~/.bashrc:

source ~/bash_completion.sh

Pagkatapos i-reboot ang shell, ganap na mai-install ang complete-alias.

Pinapagana ang autocompletion para sa mga kubectl alias

Ang technically complete-alias ay nagbibigay ng function ng wrapper _complete_alias. Sinusuri ng function na ito ang alias at nagbabalik ng mga pahiwatig sa pagkumpleto para sa utos ng alias.

Upang iugnay ang isang function sa isang partikular na alias, kailangan mong gamitin ang built-in na mekanismo ng Bash matapos, upang i-install _complete_alias bilang function ng pagkumpleto ng alias.

Bilang halimbawa, kunin natin ang alias k, na kumakatawan sa kubectl command. upang i-install _complete_alias Bilang pandagdag na function para sa alyas na ito, dapat mong patakbuhin ang sumusunod na command:

$ complete -F _complete_alias k

Ang resulta nito ay kapag nag-autocomplete ka ng isang alias k, tinatawag ang function _complete_alias, na sumusuri sa alias at nagbabalik ng mga pahiwatig ng pagkumpleto para sa utos kubectl.

Bilang pangalawang halimbawa, kunin natin ang alias kg, na nagsasaad kubectl get:

$ complete -F _complete_alias kg

Tulad ng sa nakaraang halimbawa, kapag nag-autocomplete ka ng kg, makakakuha ka ng parehong mga pahiwatig sa pagkumpleto na makukuha mo para sa kubectl get.

Tandaan na maaari kang gumamit ng kumpletong-alias para sa anumang alias sa iyong system.

Samakatuwid, upang paganahin ang autocompletion para sa lahat ng kubectl alias, kailangan mong patakbuhin ang command sa itaas para sa bawat isa sa kanila. Eksaktong ginagawa ito ng sumusunod na snippet, kung itinakda mo ang mga kubectl-aliases sa ~/.kubectl-aliases:

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

Ang piraso ng code na ito ay kailangang ilagay sa iyong ~/.bashrc, i-restart ang command shell at magiging available ang autocompletion para sa lahat ng 800 kubectl alias.

6. Pagpapalawak ng kubectl gamit ang mga plugin

Simula sa bersyon 1.12, sinusuportahan ng kubectl mekanismo ng plugin, na nagbibigay-daan sa iyong palawakin ang mga function nito gamit ang mga karagdagang command.

Kung pamilyar ka sa Mga mekanismo ng plugin ng Git, pagkatapos ay ang mga kubectl plugin ay binuo sa parehong prinsipyo.

Sa kabanatang ito, tatalakayin namin kung paano mag-install ng mga plugin, kung saan mahahanap ang mga ito, at kung paano gumawa ng sarili mong mga plugin.

Pag-install ng mga plugin

Ang mga plugin ng Kubectl ay ipinamamahagi bilang mga simpleng executable na file na may pangalang tulad kubectl-x. Prefix kubectl- ay kinakailangan, na sinusundan ng isang bagong kubectl subcommand na nagpapahintulot sa iyo na tawagan ang plugin.

Halimbawa, ang hello plugin ay ipapamahagi bilang isang file na tinatawag kubectl-hello.

Upang mai-install ang plugin, kailangan mong kopyahin ang file kubectl-x sa anumang direktoryo sa iyong PATH at gawin itong maipapatupad, halimbawa sa chmod +x. Kaagad pagkatapos nito maaari mong tawagan ang plugin na may kubectl x.

Maaari mong gamitin ang sumusunod na command upang ilista ang lahat ng mga plugin na kasalukuyang naka-install sa iyong system:

$ kubectl plugin list

Ang command na ito ay magpapakita din ng mga babala kung marami kang plugin na may parehong pangalan, o kung mayroong isang plugin na file na hindi maipapatupad.

Paghahanap at pag-install ng mga plugin gamit ang Krew

Maaaring ibahagi o muling gamitin ang mga plugin ng Kubectl tulad ng mga software package. Ngunit saan ka makakahanap ng mga plugin na ibinahagi ng iba?

Project Krew naglalayong magbigay ng pinag-isang solusyon para sa pagbabahagi, paghahanap, pag-install at pamamahala ng mga plugin ng kubectl. Tinatawag ng proyekto ang sarili nitong isang "package manager para sa kubectl plugins" (Krew ay katulad ng gumawa ng serbesa).

Ang Krew ay isang listahan ng mga kubectl plugin na maaari mong piliin at i-install. Kasabay nito, ang Krew ay isa ring plugin para sa kubectl.

Nangangahulugan ito na ang pag-install ng Krew ay gumagana tulad ng pag-install ng anumang iba pang kubectl plugin. Makakakita ka ng mga detalyadong tagubilin sa pahina ng GitHub.

Ang pinakamahalagang utos ng Krew ay:

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

Pakitandaan na ang pag-install ng mga plugin gamit ang Krew ay hindi nakakasagabal sa pag-install ng mga plugin gamit ang karaniwang paraan na inilarawan sa itaas.

Mangyaring tandaan na ang utos kubectl krew list nagpapakita lamang ng mga plugin na na-install gamit ang Krew, samantalang ang command kubectl plugin list naglilista ng lahat ng mga plugin, iyon ay, ang mga naka-install gamit ang Krew at ang mga naka-install sa pamamagitan ng iba pang mga pamamaraan.

Paghahanap ng Mga Plugin sa Ibang Lugar

Si Krew ay isang batang proyekto, kasalukuyang nasa nito ang listahan mga 30 plugin lang. Kung hindi mo mahanap ang kailangan mo, makakahanap ka ng mga plugin sa ibang lugar, gaya ng GitHub.

Inirerekomenda ko ang pagtingin sa seksyong GitHub kubectl-plugins. Doon ay makakahanap ka ng dose-dosenang magagamit na mga plugin na sulit na suriin.

Pagsusulat ng iyong sariling mga plugin

kaya mo sarili mo lumikha ng mga plugin - Ito ay hindi mahirap. Kailangan mong lumikha ng isang executable na ginagawa ang kailangan mo, pangalanan ito kubectl-x at i-install tulad ng inilarawan sa itaas.

Ang file ay maaaring isang bash script, isang python script, o isang pinagsama-samang GO application - hindi ito mahalaga. Ang tanging kundisyon ay maaari itong direktang isagawa sa operating system.

Gumawa tayo ng halimbawang plugin ngayon. Sa nakaraang seksyon, ginamit mo ang kubectl command para ilista ang mga container para sa bawat pod. Madaling gawing plugin ang command na ito na maaari mong tawagan hal. kubectl img.

Gumawa ng file kubectl-img sumusunod na nilalaman:

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

Ngayon gawin ang file na maipapatupad gamit ang chmod +x kubectl-img at ilipat ito sa anumang direktoryo sa iyong PATH. Kaagad pagkatapos nito maaari mong gamitin ang plugin kubectl img.

Tulad ng nabanggit, ang mga plugin ng kubectl ay maaaring isulat sa anumang programming o scripting language. Kung gumagamit ka ng mga script ng shell, ang bentahe ng pagiging madaling tumawag sa kubectl mula sa loob ng plugin. Gayunpaman, maaari kang magsulat ng mas kumplikadong mga plugin sa totoong mga wika ng programming gamit Kubernetes client library. Kung gumagamit ka ng Go, maaari mo ring gamitin cli-runtime library, na partikular na umiiral para sa pagsusulat ng mga plugin ng kubectl.

Paano ibahagi ang iyong mga plugin

Kung sa tingin mo ay maaaring maging kapaki-pakinabang ang iyong mga plugin sa iba, huwag mag-atubiling ibahagi ito sa GitHub. Tiyaking idagdag sila sa paksa kubectl-plugins.

Maaari mo ring hilingin na idagdag ang iyong plugin sa Listahan ng krew. Ang mga tagubilin kung paano gawin ito ay nasa Mga repositoryo ng GitHub.

Pagkumpleto ng utos

Kasalukuyang hindi sinusuportahan ng mga plugin ang autocompletion. Iyon ay, dapat mong ipasok ang buong pangalan ng plugin at ang buong pangalan ng mga argumento.

Ang GitHub kubectl repository para sa function na ito ay may bukas na kahilingan. Kaya posibleng maipatupad ang feature na ito sa hinaharap.

Good luck!!!

Ano pa ang mababasa sa paksa:

Pinagmulan: www.habr.com

Paano gamitin ang kubectl nang mas epektibo: isang detalyadong gabay