🥇Hoe kinne jo kubectl effektiver brûke: in detaillearre hantlieding

As jo wurkje mei Kubernetes, dan is kubectl wierskynlik ien fan 'e nutsbedriuwen dy't jo it meast brûke. En as jo in protte tiid besteegje oan it wurkjen mei in bepaald ark, betellet it om it goed te studearjen en te learen hoe jo it effektyf kinne brûke.

team Kubernetes aaS fan Mail.ru oerset in artikel fan Daniel Weibel wêryn jo tips en trúkjes fine om effektyf te wurkjen mei kubectl. It sil jo ek helpe om in djipper begryp fan Kubernetes te krijen.

Neffens de skriuwer is it doel fan it artikel om jo deistich wurk mei Kubernetes net allinich effisjinter te meitsjen, mar ek nofliker!

Yntroduksje: Wat is kubectl

Foardat jo kinne leare om kubectl effektiver te brûken, moatte jo in basisbegryp krije fan wat it is en hoe't it wurket.

Fanút it perspektyf fan in brûker is kubectl in kontrôlepaniel wêrmei jo Kubernetes-operaasjes kinne útfiere.

Technysk sjoen is kubectl in Kubernetes API-kliïnt.

Kubernetes API is in HTTP REST API. Dizze API is de wiere Kubernetes brûkersynterface, wêrtroch it folslein kontrolearre wurdt. Dit betsjut dat elke Kubernetes-operaasje bleatsteld wurdt as in API-einpunt en kin makke wurde mei in HTTP-fersyk nei dat einpunt.

Dêrom is de wichtichste taak fan kubectl om HTTP-oanfragen te meitsjen oan de Kubernetes API:

Kubernetes is in folslein boarne-rjochte systeem. Dit betsjut dat it de ynterne steat fan boarnen behâldt en alle Kubernetes-operaasjes binne CRUD-operaasjes.

Jo binne yn folsleine kontrôle fan Kubernetes troch it behearen fan dizze boarnen, en Kubernetes fynt út wat te dwaan op basis fan 'e hjoeddeistige steat fan' e boarnen. Om dizze reden wurdt de Kubernetes API-referinsje organisearre as in list mei boarnetypen mei har assosjearre operaasjes.

Litte wy nei in foarbyld sjen.

Litte wy sizze dat jo in ReplicaSet-boarne wolle oanmeitsje. Om dit te dwaan, beskriuwe jo de ReplicaSet yn in bestân by namme replicaset.yaml, fier dan it kommando út:

$ kubectl create -f replicaset.yaml

Dit sil in ReplicaSet-boarne oanmeitsje. Mar wat bart der efter de skermen?

Kubernetes hat in ReplicaSet oanmeitsjen operaasje. Lykas elke oare operaasje is it bleatsteld as in API-einpunt. It spesifike API-einpunt foar dizze operaasje sjocht der sa út:

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

API-einpunten foar alle Kubernetes-operaasjes kinne fûn wurde op API referinsje (ynklusyf boppesteande einpunt). Om in feitlik fersyk oan in einpunt te meitsjen, moatte jo earst de API-tsjinner URL tafoegje oan de einpuntpaden dy't yn 'e API-referinsje steane.

Dêrom, as jo it boppesteande kommando útfiere, stjoert kubectl in HTTP POST-fersyk nei it boppesteande API-einpunt. De ReplicaSet-definysje dy't jo yn it bestân hawwe levere replicaset.yaml, wurdt ferstjoerd yn it lichem fan it fersyk.

Dit is hoe't kubectl wurket foar alle kommando's dy't ynteraksje mei it Kubernetes-kluster. Yn al dizze gefallen makket kubectl gewoan HTTP-oanfragen nei de passende Kubernetes API-einpunten.

Tink derom dat jo Kubernetes folslein kinne beheare mei in helpprogramma lykas curltroch HTTP-fersiken manuell te ferstjoeren nei de Kubernetes API. Kubectl makket it gewoan makliker om de Kubernetes API te brûken.

Dit is de basis fan wat kubectl is en hoe't it wurket. Mar d'r is wat oars oer de Kubernetes API dat elke kubectl-brûker moat witte. Litte wy efkes sjen yn 'e ynderlike wrâld fan Kubernetes.

De ynderlike wrâld fan Kubernetes

Kubernetes bestiet út in set fan ûnôfhinklike komponinten dy't rinne as aparte prosessen op klusterknooppunten. Guon komponinten rinne op masterknooppunten, oaren op wurkknooppunten, elke komponint docht syn eigen spesifike taak.

Hjir binne de wichtichste komponinten op 'e haadknoppen:

Vault - bewarret boarne definysjes (meastal is it ensfh).
API-tsjinner - biedt in API en beheart opslach.
Controller Manager - Soarget derfoar dat boarne statusen foldogge oan spesifikaasjes.
Planner - skema pods op arbeidersknooppunten.

En hjir is ien wichtichste komponint op 'e arbeidersknooppunten:

kubelet - beheart de lansearring fan konteners op it wurkknooppunt.

Om te begripen hoe't dizze komponinten gearwurkje, litte wy nei in foarbyld sjen.

Litte wy oannimme dat jo krekt foltôge hawwe kubectl create -f replicaset.yaml, wêrnei't kubectl in HTTP POST-fersyk dien hat oan ReplicaSet API einpunt (de ReplicaSet-boarne-definysje trochjaan).

Wat bart der yn it kluster?

Nei it dwaan kubectl create -f replicaset.yaml De API-tsjinner bewarret jo ReplicaSet-boarne-definysje yn opslach:
Dêrnei wurdt de ReplicaSet-controller lansearre yn 'e controllerbehearder, dy't it oanmeitsjen, wizigjen en wiskjen fan ReplicaSet-boarnen behannelet:
De ReplicaSet-controller makket in pod-definysje foar elke ReplicaSet-replika (neffens it pod-sjabloan yn 'e ReplicaSet-definysje) en bewarret se yn opslach:
De planner wurdt lansearre, it folgjen fan pods dy't noch net binne tawiisd oan ien wurkknooppunt:
De planner selekteart in geskikt wurkknooppunt foar elke pod en foeget dizze ynformaasje ta oan de pod-definysje yn 'e winkel:
Op it wurkknooppunt dêr't de pod oan is tawiisd, wurdt Kubelet lansearre, it folget de pods dy't oan dizze node binne tawiisd:
De Kubelet lêst de pod-definysje fan opslach en ynstruearret in kontener-runtime, lykas Docker, om konteners op it knooppunt te starten:

Hjirûnder is in tekstferzje fan dizze beskriuwing.

It API-fersyk nei it ReplicaSet-oanmeitsjen einpunt wurdt ferwurke troch de API-tsjinner. De API-tsjinner autentisearret it fersyk en bewarret de ReplicaSet-boarne-definysje yn opslach.

Dit evenemint begjint de ReplicaSet-controller, dy't in subproses is fan 'e controllermanager. De ReplicaSet-controller kontrolearret it oanmeitsjen, bywurkjen en wiskjen fan ReplicaSet-boarnen yn 'e winkel en ûntfangt in evenemint-notifikaasje as dit bart.

De taak fan de ReplicaSet-controller is om te soargjen dat it fereaske oantal ReplicaSet-pods bestiet. Yn ús foarbyld besteane noch gjin pods, dus de ReplicaSet-controller makket dizze pod-definysjes (neffens it pod-sjabloan yn 'e ReplicaSet-definysje) en bewarret se yn opslach.

It oanmeitsjen fan nije pods wurdt trigger troch in planner dy't byhâldt fan pod-definysjes dy't noch net pland binne foar wurkknooppunten. De planner selekteart in geskikt wurkknooppunt foar elke pod en fernijt de pod-definysjes yn it repository.

Tink derom dat oant dit punt gjin wurkloadkoade oeral yn it kluster rûn. Alles wat oant no ta dien is - dit is it oanmeitsjen en bywurkjen fan boarnen yn it repository op it masterknooppunt.

It lêste evenemint triggert Kubelets, dy't de pods kontrolearje dy't pland binne foar har wurkknooppunten. De Kubelet fan 'e arbeidersknooppunt wêrop jo ReplicaSet-pods binne ynstalleare moat de kontener-runtime ynstruearje, lykas Docker, om de fereaske kontenerôfbyldings te downloaden en út te fieren.

Op dit punt rint jo ReplicaSet-applikaasje einlings!

Rol fan de Kubernetes API

Lykas jo yn it foarige foarbyld seagen, sjogge Kubernetes-komponinten (útsein de API-tsjinner en opslach) nei feroaringen oan boarnen yn opslach en feroarje ynformaasje oer boarnen yn opslach.

Fansels ynteraksje dizze komponinten net direkt mei de opslach, mar allinich fia de Kubernetes API.

Beskôgje de folgjende foarbylden:

De ReplicaSet-controller brûkt it API-einpunt list ReplicaSets mei parameter watch om feroarings oan ReplicaSet-boarnen te kontrolearjen.
De ReplicaSet-controller brûkt it API-einpunt meitsje Pod (pod oanmeitsje) om pods te meitsjen.
Scheduler brûkt API einpunt patch pod (pod bewurkje) om pods te aktualisearjen mei ynformaasje oer de selektearre arbeidersknooppunt.

Sa't jo sjen kinne, is dit deselde API dy't kubectl tagong hat. It brûken fan deselde API foar ynterne komponinten en eksterne brûkers is in fûnemintele konsept yn Kubernetes-ûntwerp.

No kinne wy gearfetsje hoe't Kubernetes wurket:

De opslach winkels steat, dat is Kubernetes boarnen.
De API-tsjinner biedt in ynterface foar de opslach yn 'e foarm fan de Kubernetes API.
Alle oare Kubernetes-komponinten en brûkers lêze, observearje en manipulearje Kubernetes-status (boarnen) fia de API.

Troch dizze begripen te kennen sil jo helpe om kubectl better te begripen en it measte út te heljen.

Litte wy no wat spesifike tips en trúkjes sjen dy't jo sille helpe om jo produktiviteit te ferbetterjen mei kubectl.

1. Fersnelle ynfier mei help fan kommando foltôging

Ien fan 'e nuttichste, mar faak oersjoen, techniken foar it ferbetterjen fan prestaasjes mei kubectl is kommando foltôging.

Kommando-foltôging kinne dielen fan kubectl-kommando's automatysk foltôge wurde mei de Tab-kaai. Dit wurket foar subkommando's, opsjes en arguminten, ynklusyf wat sa kompleks as boarnenammen.

Sjoch hoe't kubectl kommando foltôging wurket:

Kommandofoltôging wurket foar Bash- en Zsh-skelpen.

Offisjele Gids befettet detaillearre ynstruksjes foar it ynstellen fan autofolling, mar hjirûnder sille wy in koart úttreksel jaan.

Hoe kommando foltôging wurket

Kommando foltôging is in shell-funksje dy't wurket mei in foltôgingsskript. In útwreidingsskript is in shellskript dat it gedrach fan in útwreiding foar in spesifyk kommando definiearret.

Kubectl genereart en útfiert automatysk útwreidingsskripts foar Bash en Zsh mei de folgjende kommando's:

$ kubectl completion bash

Of:

$ kubectl completion zsh

Yn teory is it genôch om de útfier fan dizze kommando's te ferbinen mei de passende kommando-shell, sadat kubectl de kommando's oanfolje kin.

Yn 'e praktyk is de ferbiningsmetoade oars foar Bash (ynklusyf ferskillen tusken Linux en MacOS) en Zsh. Hjirûnder sille wy nei al dizze opsjes sjen.

Bash op Linux

It Bash-foltôgingsskript hinget ôf fan it bash-foltôgingspakket, dus jo moatte it earst ynstallearje:

$ sudo apt-get install bash-completion

Of:

$ yum install bash-completion

Jo kinne testen dat it pakket mei súkses ynstallearre is mei it folgjende kommando:

$ type _init_completion

As dit shellfunksjekoade útfiert, dan is bash-foltôging goed ynstalleare. As it kommando in flater "Net fûn" jout, moatte jo de folgjende rigel tafoegje oan jo bestân ~ / .bashrc:

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

Is it nedich om dizze rigel ta te foegjen oan it bestân ~ / .bashrc of net hinget ôf fan de pakketbehearder dy't jo brûkt hawwe om bash-foltôging te ynstallearjen. Dit is nedich foar APT, mar net foar YUM.

Nei it ynstallearjen fan bash-foltôging, moatte jo alles konfigurearje sadat it kubectl-foltôgingsskript yn alle shell-sesjes ynskeakele is.

Ien manier om dit te dwaan is de folgjende rigel ta te foegjen oan it bestân ~ / .bashrc:

source <(kubectl completion bash)

In oare manier is om it kubectl-útwreidingsskript ta te foegjen oan 'e map /etc/bash_completion.d (meitsje it oan as it net bestiet):

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

Alle add-on skripts yn 'e katalogus /etc/bash_completion.d wurde automatysk opnommen yn bash-foltôging.

Beide opsjes binne like fan tapassing.

Nei it opnij starte fan 'e shell, sil foltôging fan kubectl-kommando wurkje.

Bash op MacOS

Op MacOS is de opset in bytsje komplisearre. It feit is dat MacOS standert Bash ferzje 3.2 brûkt, en it kubectl-autofoltôgingsskript fereasket in Bash-ferzje fan op syn minst 4.1 en wurket net yn Bash 3.2.

D'r binne lisinsjeproblemen ferbûn mei it brûken fan in ferâldere ferzje fan Bash op MacOS. Bash ferzje 4 is lisinsje ûnder GPLv3, dat wurdt net stipe troch Apple.

Om kubectl-autofoltôging op MacOS te konfigurearjen, moatte jo in resinte ferzje fan Bash ynstallearje. Jo kinne ek de bywurke Bash ynstelle as jo standert shell, dy't jo yn 'e takomst in protte problemen besparje sil. It is net dreech, details wurde jûn yn it artikel "Bash bywurkje op MacOS".

Foardat jo trochgean, soargje derfoar dat jo in resinte ferzje fan Bash brûke (kontrolearje de útfier bash --version).

Bash-foltôgingsskript ferskilt per projekt bash-foltôging, dus jo moatte it earst ynstallearje.

Jo kinne bash-foltôging ynstallearje mei Homebrew:

$ brew install bash-completion@2

it is @2 stiet foar bash-foltôging ferzje 2. kubectl-autofoltôging fereasket bash-foltôging v2, en bash-foltôging v2 fereasket in minimum fan Bash-ferzje 4.1.

Kommando útfier brew-install befettet in Caveats seksje, dy't spesifisearret wat moat wurde tafoege oan de triem ~/.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"

Ik advisearje lykwols om dizze rigels net ta te foegjen ~/.bash_profile, en yn ~/.bashrc. Yn dit gefal sil automatyske foltôging net allinich yn 't haad, mar ek yn bern kommando-shells beskikber wêze.

Nei it opnij starte fan de kommando-shell, kinne jo kontrolearje dat de ynstallaasje korrekt is mei it folgjende kommando:

$ type _init_completion

As jo in shellfunksje yn 'e útfier sjogge, dan is alles goed konfigureare.

No moatte wy derfoar soargje dat kubectl autocompletion is ynskeakele yn alle sesjes.

Ien manier is om de folgjende rigel ta te foegjen oan jo ~/.bashrc:

source <(kubectl completion bash)

De twadde manier is om in autocomplete-skript ta te foegjen oan 'e map /usr/local/etc/bash_completion.d:

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

Dizze metoade sil allinich wurkje as jo bash-foltôging ynstalleare mei Homebrew. Yn dit gefal laadt bash-foltôging alle skripts út dizze map.

As jo ynstallearre kubectl mei help fan Homebrew, dan is it net nedich om de foarige stap út te fieren, om't it skript foar autofoltôging automatysk yn 'e map pleatst wurdt /usr/local/etc/bash_completion.d tidens ynstallaasje. Yn dit gefal sil kubectl autocompletion begjinne te wurkjen sa gau as jo bash-completion ynstallearje.

As gefolch binne al dizze opsjes lykweardich.

zsh

Autocompletion-skripts foar Zsh hawwe gjin ôfhinklikens nedich. Alles wat jo hoege te dwaan is se ynskeakelje as jo de kommando-shell lade.

Jo kinne dit dwaan troch in rigel ta te foegjen oan jo ~/.zshrc map:

source <(kubectl completion zsh)

As jo ûntfange in flater not found: compdef nei't jo jo shell opnij starte, moatte jo de ynboude funksje ynskeakelje compdef. Jo kinne it ynskeakelje troch it ta te foegjen oan it begjin fan jo bestân ~/.zshrc it folgjende:

autoload -Uz compinit
compinit

2. Fluch besjoch boarne spesifikaasjes

As jo definysjes fan YAML-boarnen meitsje, moatte jo de fjilden en har betsjutting witte foar dy boarnen. Ien plak om nei dizze ynformaasje te sykjen is yn 'e API-referinsje, dy't folsleine spesifikaasjes foar alle boarnen befettet.

It wikseljen nei de webblêder elke kear as jo wat sykje moatte is lykwols ûngemaklik. Dêrom leveret kubectl it kommando kubectl explain, dy't de spesifikaasjes fan alle boarnen direkt yn jo terminal toant.

It kommando-formaat is as folget:

$ kubectl explain resource[.field]...

It kommando sil de spesifikaasje fan 'e frege boarne of fjild útfiere. De werjûn ynformaasje is identyk oan dy yn 'e API-hantlieding.

standert kubectl explain toant allinich it earste nivo fan nêst fan fjilden.

Sjoch hoe't it liket kin hjir wêze.

Jo kinne de hiele beam werjaan as jo de opsje tafoegje --recursive:

$ kubectl explain deployment.spec --recursive

As jo net krekt witte hokker boarnen nedich binne, kinne jo se allegear werjaan mei it folgjende kommando:

$ kubectl api-resources

Dit kommando toant boarnenammen yn meartalsfoarm, bgl. deployments вместо deployment. It toant ek de koarte namme, bygelyks deploy, foar dy middels dy't it hawwe. Meitsje jo gjin soargen oer dizze ferskillen. Al dizze nammenopsjes binne lykweardich foar kubectl. Dat is, jo kinne elk fan har brûke foar kubectl explain.

Alle folgjende kommando's binne lykweardich:

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

3. Brûk in oanpaste kolom útfier opmaak

Standert kommando útfier opmaak 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

Dit formaat is handich, mar it befettet in beheinde hoemannichte ynformaasje. Yn ferliking mei de folsleine boarne definysje opmaak, mar in pear fjilden wurde werjûn hjir.

Yn dit gefal kinne jo in oanpaste kolomútfierformaat brûke. It lit jo bepale hokker gegevens jo moatte útfiere. Jo kinne elk boarnefjild werjaan as in aparte kolom.

It gebrûk fan in oanpast formaat wurdt bepaald mei de opsjes:

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

Jo kinne elke útfierkolom definiearje as in pear <header>:<jsonpath>wêr <header> is de kolom namme, en <jsonpath> - in útdrukking dy't in boarnefjild definiearret.

Litte wy nei in ienfâldich foarbyld sjen:

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

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

De útfier befettet ien kolom mei de nammen fan de pods.

De opsje-ekspresje selekteart de podnammen út it fjild metadata.name. Dit komt om't de namme fan 'e pod is definiearre yn it fjild foar bernnamme metadata yn 'e boarne beskriuwing fan' e pod. Mear details kinne fûn wurde yn API Guide of typ it kommando kubectl explain pod.metadata.name.

Litte wy no sizze dat jo in ekstra kolom taheakje wolle oan 'e útfier, bygelyks it knooppunt sjen litte wêrop elke pod rint. Om dit te dwaan kinne jo gewoan de passende kolomspesifikaasje tafoegje oan 'e opsje foar oanpaste kolommen:

$ 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

De útdrukking selektearret de node namme út spec.nodeName - as in pod wurdt tawiisd oan in knooppunt, wurdt syn namme yn it fjild skreaun spec.nodeName pod resource spesifikaasje. Mear detaillearre ynformaasje is te finen yn 'e útfier kubectl explain pod.spec.nodeName.

Tink derom dat Kubernetes-boarnefjilden hoofdlettergefoelich binne.

Jo kinne elk boarnefjild as kolom sjen. Kontrolearje gewoan de spesifikaasje fan 'e boarne en besykje it mei alle fjilden dy't jo wolle.

Mar earst litte wy in tichterby besjen op fjildseleksje-útdrukkingen.

JSONPath-ekspresjes

Utdrukkingen foar it selektearjen fan boarnefjilden binne basearre op JSONPath.

JSONPath is in taal foar it opheljen fan gegevens út JSON-dokuminten. It selektearjen fan in inkeld fjild is it ienfâldichste gebrûk foar JSONPath. Hy hat in protte mear mooglikheden, ynklusyf selectors, filters ensafuorthinne.

Kubectl ferklearje stipet in beheind oantal JSONPath-funksjes. De mooglikheden en foarbylden fan har gebrûk wurde hjirûnder beskreaun:

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

De [] operator is benammen wichtich. In protte Kubernetes-boarnefjilden binne listen, en dizze operator lit jo leden fan dy listen selektearje. It wurdt faak brûkt mei in jokerteken lykas [*] om alle eleminten fan in list te selektearjen.

Applikaasje foarbylden

De mooglikheden foar it brûken fan in oanpaste kolomútfierformaat binne einleaze, om't jo elk fjild of kombinaasje fan boarnefjilden yn 'e útfier kinne werjaan. Hjir binne wat foarbyldapps, mar fiel jo frij om se sels te ferkennen en applikaasjes te finen dy't foar jo wurkje.

Containerôfbyldings foar pods sjen litte:

$ 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

Dit kommando toant de kontenerôfbyldingsnammen foar elke pod.

Unthâld dat in pod ferskate konteners befetsje kin, dan wurde de ôfbyldingsnammen op ien rigel werjûn, skieden troch komma's.

Knooppunt beskikberensônes werjaan:
```
$ 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
```
Dit kommando is handich as jo kluster wurdt host yn in iepenbiere wolk. It toant de beskikberensône foar elke knooppunt.

Beskikberensône is in wolkkonsept dat de replikaasjesône beheint ta in geografyske regio.

Beskikberenssônes foar elke knooppunt wurde krigen fia in spesjaal label - failure-domain.beta.kubernetes.io/zone. As it kluster yn in iepenbiere wolk rint, wurdt dit label automatysk oanmakke en fol mei de nammen fan 'e beskikberensônes foar elke knooppunt.

Labels binne gjin diel fan 'e Kubernetes-boarnespesifikaasje, dus jo sille gjin ynformaasje oer har fine yn API Guide. Se kinne lykwols sjoen wurde (lykas alle oare labels) as jo ynformaasje freegje oer de knopen yn YAML- as JSON-formaat:
```
$ kubectl get nodes -o yaml
# или
$ kubectl get nodes -o json
```
Dit is in geweldige manier om mear te learen oer boarnen, neist it learen fan boarnespesifikaasjes.

4. Maklik wikselje tusken klusters en nammeromten

As kubectl in fersyk docht oan de Kubernetes API, lêst it earst it kubeconfig-bestân om alle nedige parameters foar de ferbining te krijen.

Standert is it kubeconfig-bestân ~/.kube/config. Typysk wurdt dit bestân makke of bywurke troch in spesjaal kommando.

As jo mei meardere klusters wurkje, befettet jo kubeconfig-bestân ynstellings foar ferbining mei al dy klusters. Jo hawwe in manier nedich om it kommando kubectl te fertellen mei hokker kluster jo wurkje.

Binnen in kluster kinne jo meardere nammeromten oanmeitsje - in soarte fan firtuele kluster binnen in fysyk kluster. Kubectl bepaalt ek hokker nammeromte te brûken basearre op it kubeconfig-bestân. Dit betsjut dat jo ek in manier nedich hawwe om it kommando kubectl te fertellen hokker nammeromte om mei te wurkjen.

Yn dit haadstik sille wy útlizze hoe't it wurket en hoe't jo it effektyf meitsje kinne.

Tink derom dat jo meardere kubeconfig-bestannen kinne hawwe neamd yn 'e KUBECONFIG-omjouwingsfariabele. Yn dit gefal sille al dizze bestannen wurde kombineare yn ien mienskiplike konfiguraasje by runtime. Jo kinne ek de standert kubeconfig-bestân feroarje troch kubectl út te fieren mei de parameter --kubeconfig. Sjen offisjele dokumintaasje.

kubeconfig triemmen

Litte wy sjen wat krekt it kubeconfig-bestân befettet:

Sa't jo sjen kinne, befettet it kubeconfig-bestân in set fan konteksten. Kontekst bestiet út trije eleminten:

Cluster - API-URL fan 'e klustertsjinner.
Brûker - brûker autentikaasje bewiisbrieven yn it kluster.
Nammeromte - de nammeromte dy't brûkt wurdt by it oansluten fan it kluster.

Yn 'e praktyk brûke se faak ien kontekst per kluster yn har kubeconfig. Jo kinne lykwols meardere konteksten per kluster hawwe, differinsjearre troch brûker of nammeromte. Dizze multi-kontekstkonfiguraasje is lykwols ûngewoan, dus is d'r normaal ien-op-ien mapping tusken klusters en konteksten.

Op elk momint is ien fan 'e konteksten aktueel:

As kubectl in konfiguraasjetriem lêst, nimt it altyd ynformaasje út 'e hjoeddeistige kontekst. Yn it foarbyld hjirboppe sil kubectl ferbine mei it Hare-kluster.

Dêrom, om te wikseljen nei in oar kluster, moatte jo de aktuele kontekst feroarje yn it kubeconfig-bestân:

No sil kubectl ferbine mei it Fox-kluster.

Om te wikseljen nei in oare nammeromte yn itselde kluster, moatte jo de wearde fan it nammeromte-elemint feroarje foar de aktuele kontekst:

Yn it boppesteande foarbyld sil kubectl de Prod-nammeromte fan it Fox-kluster brûke (earder waard de nammeromte Test ynsteld).

Tink derom dat kubectl ek opsjes biedt --cluster, --user, --namespace и --context, wêrmei jo yndividuele eleminten en de aktuele kontekst sels kinne oerskriuwe, nettsjinsteande wat yn 'e kubeconfig is ynsteld. Sjen kubectl options.

Yn teory kinne jo de ynstellings manuell feroarje yn 'e kubeconfig. Mar it is ûngemaklik. Om dizze operaasjes te ferienfâldigjen, binne d'r ferskate nutsbedriuwen wêrmei jo parameters automatysk kinne feroarje.

Brûk kubectx

In heul populêr hulpprogramma om te wikseljen tusken klusters en nammeromten.

It hulpprogramma jout kommando's kubectx и kubens om respektivelik de hjoeddeistige kontekst en nammeromte te feroarjen.

Lykas sein, it feroarjen fan de hjoeddeistige kontekst betsjut it feroarjen fan it kluster as jo mar ien kontekst per kluster hawwe.

Hjir is in foarbyld fan it útfieren fan dizze kommando's:

Yn essinsje bewurkje dizze kommando's gewoan it kubeconfig-bestân lykas hjirboppe beskreaun.

ynstallearje kubectx, folgje de ynstruksjes op Github.

Beide kommando's stypje autofolling fan kontekst- en nammeromte-nammen, wat de needsaak elimineert om se folslein te typen. Ynstruksjes foar it ynstellen fan autofolling hjir.

In oare nuttige funksje kubectx it is ynteraktive modus. It wurket yn gearhing mei it nut fzf, dy't apart moatte wurde ynstalleare. It ynstallearjen fan fzf makket automatysk ynteraktive modus beskikber yn kubectx. Ynteraktyf kinne jo kontekst en nammeromte selektearje fia de ynteraktive fergese sykynterface levere troch fzf.

Mei help fan shell alias

Jo hawwe gjin aparte ark nedich om de hjoeddeistige kontekst en nammeromte te feroarjen, om't kubectl hjir ek kommando's foar leveret. Ja, team kubectl config jout subkommando's foar it bewurkjen fan kubeconfig-bestannen.

Hjir binne guon fan harren:

kubectl config get-contexts: alle konteksten sjen litte;
kubectl config current-context: krije aktuele kontekst;
kubectl config use-context: aktuele kontekst feroarje;
kubectl config set-context: Feroarje it kontekst elemint.

It gebrûk fan dizze kommando's direkt is lykwols net heul handich, om't se lang binne. Jo kinne shell-aliassen foar har meitsje dy't maklik út te fieren binne.

Ik makke in set fan aliassen basearre op dizze kommando's dy't funksjonaliteit leverje lykas kubectx. Hjir kinne jo se yn aksje sjen:

Tink derom dat aliassen fzf brûke om in ynteraktive frije opsykynterface te leverjen (lykas de ynteraktive modus fan kubectx). Dit betsjut dat jo nedich binne ynstallearje fzfom dizze aliassen te brûken.

Hjir binne de definysjes fan aliasen sels:

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

Om dizze aliassen yn te stellen moatte jo de boppesteande definysjes tafoegje oan jo bestân ~/.bashrc of ~/.zshrc en herstart jo shell.

It brûken fan plugins

Kubectl lit jo plugins laden dy't op deselde manier wurde útfierd as basiskommando's. Jo kinne bygelyks de plugin kubectl-foo ynstallearje en it útfiere troch it kommando út te fieren kubectl foo.

It soe handich wêze om de kontekst en nammeromte op dizze manier te feroarjen, bygelyks troch te rinnen kubectl ctx te feroarjen kontekst en kubectl ns om de nammeromte te feroarjen.

Ik haw twa plugins skreaun dy't dit dogge:

It wurk fan plugins is basearre op aliassen út 'e foarige seksje.

Hjir is hoe't se wurkje:

Tink derom dat de plugins fzf brûke om in ynteraktive frije sykynterface te leverjen (lykas de ynteraktive modus fan kubectx). Dit betsjut dat jo nedich hawwe ynstallearje fzfom dizze aliassen te brûken.

Om plugins te ynstallearjen, moatte jo shell-skripts downloade neamd kubectl-ctx и kubectl-ns nei elke map yn jo PATH-fariabele en meitsje se útfierber mei bgl. chmod +x. Fuort nei dit kinne jo brûke kubectl ctx и kubectl ns.

5. Ferminderje ynfier mei autoaliases

Shell-aliassen binne in goede manier om ynput te fersnellen. Projekt kubectl-aliases befettet sawat 800 fluchtoetsen foar basis kubectl-kommando's.

Jo kinne jo ôffreegje - hoe ûnthâlde jo 800 aliassen? Mar jo hoege se net allegear te ûnthâlden, om't se binne boud neffens in ienfâldich skema, dat hjirûnder wurdt jûn:

Bygelyks:

kgpooyaml - kubectl krije pods oyaml
ksysgsvcw - kubectl -n kube-systeem krije svc w
ksysrmcm -kubectl -n kube-systeem rm cm
kgdepallsl - kubectl krije ynset alle sl

Sa't jo sjen kinne, binne aliassen opboud út komponinten, elk fan dy fertsjintwurdiget in spesifyk elemint fan it kommando kubectl. Elke alias kin ien komponint hawwe foar it basiskommando, operaasje en boarne, en meardere komponinten foar parameters. Jo "befolkje" dizze komponinten gewoan fan links nei rjochts neffens it diagram hjirboppe.

De hjoeddeistige detaillearre diagram is by GitHub. Dêr kinne jo ek fine folsleine list fan aliassen.

Bygelyks, de alias kgpooyamlall is lykweardich oan it kommando kubectl get pods -o yaml --all-namespaces.

De relative folchoarder fan de opsjes is net wichtich: kommando kgpooyamlall is lykweardich oan it kommando kgpoalloyaml.

Jo hoege net alle komponinten as alias te brûken. Bygelyks k, kg, klo, ksys, kgpo kin ek brûkt wurde. Boppedat kinne jo aliassen en reguliere kommando's of opsjes kombinearje op 'e kommandorigel:

Bygelyks:

Ynstee kubectl proxy do kinst skriuwe k proxy.
Ynstee kubectl get roles do kinst skriuwe kg roles (d'r is op it stuit gjin alias foar de Roles-boarne).
Om gegevens te krijen foar in spesifike pod, kinne jo it kommando brûke kgpo my-pod — kubectl get pod my-pod.

Tink derom dat guon aliassen in kommandorigelargumint fereaskje. Bygelyks, alias kgpol betsjut kubectl get pods -l. Opsje -l fereasket in argumint - in label spesifikaasje. As jo in alias brûke, sil it der útsjen kgpol app=ui.

Om't guon aliassen arguminten nedich binne, moatte aliassen a, f en l as lêste brûkt wurde.

Yn 't algemien kinne jo, as jo dit skema ienris ûnder de hân hawwe, yntuïtyf aliassen ôfliede fan' e kommando's dy't jo wolle útfiere en in protte tiid besparje.

Ynstallaasje

Om kubectl-aliases te ynstallearjen, moatte jo it bestân downloade .kubectl_aliases fan GitHub en befetsje it yn it bestân ~/.bashrc of ~/.zshrc:

source ~/.kubectl_aliases

Autofoltôging

Lykas wy earder sein hawwe, foegje jo faak ekstra wurden ta oan in alias op 'e kommandorigel. Bygelyks:

$ kgpooyaml test-pod-d4b77b989

As jo kubectl-kommandofoltôging brûke, hawwe jo wierskynlik autofoltôging brûkt foar dingen lykas boarnenammen. Mar kin dit dien wurde as aliasen wurde brûkt?

Dit is in heul wichtige fraach, om't as autofoltôging net wurket, sille jo guon fan 'e foardielen fan aliassen ferlieze.

It antwurd hinget ôf fan hokker shell jo brûke:

Foar Zsh wurket alias foltôging bûten it fak.
Foar Bash is spitigernôch wat wurk nedich om autofoltôging oan it wurk te krijen.

Automatysk oanfolling ynskeakelje foar alias yn Bash

It probleem mei Bash is dat it besiket te foltôgjen (elke kear as jo op Tab drukke) de alias, net it kommando dat de alias ferwiist nei (lykas bygelyks Zsh docht). Om't jo gjin foltôgingsskripts hawwe foar alle 800 aliassen, wurket autofoltôging net.

It projekt folsleine-alias jout in algemiene oplossing foar dit probleem. It slút oan by de alias foltôging meganisme, yntern wreidet de alias nei in kommando, en jout foltôging opsjes foar it foltôge kommando. Dit betsjut dat de padding foar in alias krekt itselde gedraacht as foar in folslein kommando.

Yn it folgjende sil ik earst útlizze hoe't jo complete-alias kinne ynstallearje en dan hoe't jo it ynstelle om foltôging yn te skeakeljen foar alle kubectl-aliasen.

Ynstallaasje fan folsleine-alias

Earst fan alles, folsleine-alias hinget ôf fan bash-foltôging. Dêrom, foardat jo folsleine-alias ynstallearje, moatte jo der wis fan wêze dat bash-foltôging is ynstalleare. Ynstallaasje-ynstruksjes binne earder levere foar Linux en MacOS.

Wichtige opmerking foar MacOS-brûkers: Lykas it kubectl-autofoltôgingsskript, wurket complete-alias net mei Bash 3.2, dat is de standert op MacOS. Benammen folslein-alias hinget ôf fan bash-foltôging v2 (brew install bash-completion@2), dy't op syn minst Bash 4.1 fereasket. Dit betsjut dat om folsleine-alias te brûken op MacOS jo in nijere ferzje fan Bash moatte ynstallearje.

Jo moatte it skript downloade bash_completion.sh fan GitHub repository en befetsje it yn jo bestân ~/.bashrc:

source ~/bash_completion.sh

Nei it opnij opstarten fan 'e shell sil complete-alias folslein ynstalleare wurde.

Automatysk oanfolling ynskeakelje foar kubectl-aliasen

Technysk kompleet-alias biedt in wrapperfunksje _complete_alias. Dizze funksje kontrolearret de alias en jout oanwizings foar foltôging werom foar it aliaskommando.

Om in funksje te assosjearjen mei in spesifike alias, moatte jo it ynboude Bash-meganisme brûke kompleet, ynstallearje _complete_alias as in alias foltôgingsfunksje.

Litte wy as foarbyld de alias k nimme, dy't stiet foar it kommando kubectl. ynstallearje _complete_alias As komplementfunksje foar dizze alias moatte jo it folgjende kommando útfiere:

$ complete -F _complete_alias k

It resultaat hjirfan is dat as jo in alias k autofolje, de funksje wurdt oanroppen _complete_alias, dy't de alias kontrolearret en oanwizings foar foltôging jout foar it kommando kubectl.

As twadde foarbyld, litte wy de alias nimme kg, wat oanjout kubectl get:

$ complete -F _complete_alias kg

Krekt as yn it foarige foarbyld, as jo kg autofolje, krije jo deselde oanwizings foar foltôging dy't jo krije foar kubectl get.

Tink derom dat jo folsleine-alias brûke kinne foar elke alias op jo systeem.

Dêrom moatte jo it boppesteande kommando foar elk fan har útfiere om autofoltôging foar alle kubectl-aliassen yn te skeakeljen. It folgjende snippet docht dit krekt, op betingst dat jo kubectl-aliasen ynsteld hawwe ~/.kubectl-aliases:

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

Dit stikje koade moat wurde pleatst yn jo ~/.bashrc, start de kommando-shell op 'e nij en autofoltôging sil beskikber wurde foar alle 800 kubectl-aliassen.

6. It útwreidzjen fan kubectl mei plugins

Begjin mei ferzje 1.12, kubectl stipet plugin meganisme, wêrtroch jo syn funksjes útwreidzje kinne mei ekstra kommando's.

As jo binne bekend mei Git plugin meganismen, dan binne kubectl-plugins boud op itselde prinsipe.

Yn dit haadstik sille wy dekke hoe't jo plugins kinne ynstallearje, wêr't se kinne fine, en hoe jo jo eigen plugins kinne oanmeitsje.

Ynstallearje plugins

Kubectl-plugins wurde ferspraat as ienfâldige útfierbere bestannen mei de namme lykas kubectl-x. Foarheaksel kubectl- is fereaske, folge troch in nij kubectl-subkommando wêrmei jo de plugin kinne skilje.

Bygelyks, de hello plugin wurdt ferspraat as in triem neamd kubectl-hello.

Om it plugin te ynstallearjen, moatte jo it bestân kopiearje kubectl-x nei elke map yn jo PATH en meitsje it útfierber, bygelyks mei chmod +x. Fuort nei dit kinne jo skilje de plugin mei kubectl x.

Jo kinne it folgjende kommando brûke om alle plugins te listjen dy't op it stuit ynstalleare binne op jo systeem:

$ kubectl plugin list

Dit kommando sil ek warskôgings werjaan as jo meardere plugins hawwe mei deselde namme, of as d'r in plugins-bestân is dat net útfierber is.

It finen en ynstallearjen fan plugins mei Krew

Kubectl-plugins kinne wurde dield of opnij brûkt as softwarepakketten. Mar wêr kinne jo plugins fine dy't oaren hawwe dield?

Projekt Krew is fan doel in unifoarme oplossing te leverjen foar dielen, sykjen, ynstallearjen en behearen fan kubectl-plugins. It projekt neamt himsels in "pakketbehearder foar kubectl-plugins" (Krew is gelyk oan Brew).

Krew is in list mei kubectl-plugins dy't jo kinne selektearje en ynstallearje. Tagelyk is Krew ek in plugin foar kubectl.

Dit betsjut dat it ynstallearjen fan Krew yn essinsje wurket lykas it ynstallearjen fan in oare kubectl-plugin. Jo kinne fine detaillearre ynstruksjes op GitHub side.

De wichtichste Krew-kommando's binne:

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

Tink derom dat it ynstallearjen fan plugins mei Krew net bemuoit mei it ynstallearjen fan plugins mei de hjirboppe beskreaune standertmetoade.

Tink derom dat it kommando kubectl krew list toant allinich plugins dy't waarden ynstalleare mei Krew, wylst it kommando kubectl plugin list listet alle plugins, dat is, dy ynstalleare mei Krew en dy ynstalleare troch oare metoaden.

Ynstekkers op oare plakken fine

Krew is in jong projekt, op it stuit yn syn de list allinnich oer 30 plugins. As jo net fine wat jo nedich binne, kinne jo plugins earne oars fine, lykas GitHub.

Ik advisearje te sjen nei de GitHub-seksje kubectl-plugins. Dêr sille jo tsientallen beskikbere plugins fine dy't it wurdich binne om te kontrolearjen.

Skriuw jo eigen plugins

do kinst sels meitsje plugins - It is net dreech. Jo moatte in útfierber meitsje dat docht wat jo nedich hawwe, neam it as kubectl-x en ynstallearje lykas hjirboppe beskreaun.

It bestân kin in bash-skript, in python-skript, of in kompilearre GO-applikaasje wêze - it makket neat út. De ienige betingst is dat it direkt kin wurde útfierd yn it bestjoeringssysteem.

Litte wy no in foarbyld plugin meitsje. Yn 'e foarige seksje hawwe jo it kommando kubectl brûkt om de konteners foar elke pod te listjen. It is maklik om fan dit kommando in plugin te meitsjen dy't jo kinne skilje mei bgl. kubectl img.

Meitsje in triem kubectl-img de folgjende ynhâld:

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

No meitsje de triem útfierber mei chmod +x kubectl-img en ferpleatse it nei elke map yn jo PATH. Fuort dêrnei kinne jo de plugin brûke kubectl img.

Lykas neamd, kinne kubectl-plugins skreaun wurde yn elke programmear- of skripttaal. As jo shell-skripts brûke, is it foardiel dat jo kubectl maklik kinne skilje fanút it plugin. Jo kinne lykwols kompleksere plugins skriuwe yn echte programmeartalen mei help fan Kubernetes client bibleteek. As jo Go brûke, kinne jo ek brûke cli-runtime bibleteek, dy't spesifyk bestiet foar it skriuwen fan kubectl-plugins.

Hoe kinne jo jo plugins diele

As jo tinke dat jo plugins nuttich wêze kinne foar oaren, fiel jo frij om it te dielen op GitHub. Wês wis dat jo se tafoegje oan it ûnderwerp kubectl-plugins.

Jo kinne ek freegje dat jo plugin wurdt tafoege oan Krew list. Ynstruksjes oer hoe't jo dit dwaan binne yn GitHub repositories.

Kommando foltôging

Plugins stypje op it stuit gjin autofolling. Dat is, jo moatte de folsleine namme fan it plugin en de folsleine nammen fan 'e arguminten ynfiere.

De GitHub kubectl repository foar dizze funksje hat iepen fersyk. Dat it is mooglik dat dizze funksje ienris yn 'e takomst sil wurde ymplementearre.

Súkses!!!

Wat oars te lêzen oer it ûnderwerp:

Boarne: www.habr.com

Hoe kinne jo kubectl effektiver brûke: in detaillearre hantlieding