🥇Sådan bruger du kubectl mere effektivt: en detaljeret vejledning

Hvis du arbejder med Kubernetes, så er kubectl nok et af de værktøjer, du bruger mest. Og når du bruger meget tid på at arbejde med et bestemt værktøj, kan det betale sig at studere det godt og lære at bruge det effektivt.

Team Kubernetes aaS fra Mail.ru oversat en artikel af Daniel Weibel, hvor du finder tips og tricks til at arbejde effektivt med kubectl. Det vil også hjælpe dig med at få en dybere forståelse af Kubernetes.

Ifølge forfatteren er målet med artiklen at gøre dit daglige arbejde med Kubernetes ikke kun mere effektivt, men også sjovere!

Introduktion: Hvad er kubectl

Før du kan lære at bruge kubectl mere effektivt, skal du opnå en grundlæggende forståelse af, hvad det er, og hvordan det virker.

Fra en brugers perspektiv er kubectl et kontrolpanel, der giver dig mulighed for at udføre Kubernetes-handlinger.

Teknisk set er kubectl en Kubernetes API-klient.

Kubernetes API er en HTTP REST API. Denne API er den ægte Kubernetes-brugergrænseflade, hvorigennem den er fuldstændig styret. Dette betyder, at hver Kubernetes-handling er eksponeret som et API-slutpunkt og kan udføres med en HTTP-anmodning til det pågældende slutpunkt.

Derfor er kubectls hovedopgave at lave HTTP-anmodninger til Kubernetes API:

Kubernetes er et fuldstændigt ressourceorienteret system. Det betyder, at den opretholder den interne tilstand af ressourcer, og alle Kubernetes-operationer er CRUD-operationer.

Du har fuld kontrol over Kubernetes ved at administrere disse ressourcer, og Kubernetes finder ud af, hvad de skal gøre, baseret på ressourcernes aktuelle tilstand. Af denne grund er Kubernetes API-referencen organiseret som en liste over ressourcetyper med deres tilknyttede operationer.

Lad os se på et eksempel.

Lad os sige, at du vil oprette en ReplicaSet-ressource. For at gøre dette beskriver du ReplicaSet i en fil ved navn replicaset.yaml, kør derefter kommandoen:

$ kubectl create -f replicaset.yaml

Dette vil oprette en ReplicaSet-ressource. Men hvad sker der bag kulisserne?

Kubernetes har en ReplicaSet-oprettelseshandling. Som enhver anden operation er den eksponeret som et API-endepunkt. Det specifikke API-endepunkt for denne operation ser sådan ud:

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

API-slutpunkter for alle Kubernetes-operationer kan findes på API reference (herunder ovenstående endepunkt). For at foretage en faktisk anmodning til et slutpunkt skal du først tilføje API-serverens URL til de slutpunktstier, der er angivet i API-referencen.

Derfor, når du udfører ovenstående kommando, sender kubectl en HTTP POST-anmodning til ovenstående API-endepunkt. ReplicaSet-definitionen, du angav i filen replicaset.yaml, sendes i selve anmodningen.

Sådan fungerer kubectl for alle kommandoer, der interagerer med Kubernetes-klyngen. I alle disse tilfælde foretager kubectl simpelthen HTTP-anmodninger til de relevante Kubernetes API-slutpunkter.

Bemærk venligst, at du fuldt ud kan administrere Kubernetes ved hjælp af et hjælpeprogram som f.eks curlved manuelt at sende HTTP-anmodninger til Kubernetes API. Kubectl gør det simpelthen nemmere at bruge Kubernetes API.

Dette er det grundlæggende i, hvad kubectl er, og hvordan det virker. Men der er noget andet ved Kubernetes API, som enhver kubectl-bruger bør kende. Lad os tage et hurtigt kig ind i Kubernetes indre verden.

Kubernetes indre verden

Kubernetes består af et sæt uafhængige komponenter, der kører som separate processer på klynge noder. Nogle komponenter kører på masterknudepunkter, andre på arbejdernoder, hvor hver komponent udfører sin egen specifikke opgave.

Her er de vigtigste komponenter på hovedknuderne:

repository - gemmer ressourcedefinitioner (normalt er det osv).
API-server — leverer en API og administrerer lagring.
Controller Manager — Sikrer, at ressourcestatusser overholder specifikationerne.
Planlægger — planlægger pods på arbejderknudepunkter.

Og her er en vigtig komponent på arbejdernoderne:

kubelet — styrer lanceringen af containere på arbejdsknuden.

For at forstå, hvordan disse komponenter fungerer sammen, lad os se på et eksempel.

Lad os antage, at du lige har afsluttet kubectl create -f replicaset.yaml, hvorefter kubectl lavede en HTTP POST-anmodning til ReplicaSet API-slutpunkt (bestå ReplicaSet-ressourcedefinitionen).

Hvad sker der i klyngen?

Efter at have gjort kubectl create -f replicaset.yaml API-serveren gemmer din ReplicaSet-ressourcedefinition i lageret:
Dernæst lanceres ReplicaSet-controlleren i controllermanageren, som håndterer oprettelse, ændring og sletning af ReplicaSet-ressourcer:
ReplicaSet-controlleren opretter en pod-definition for hver ReplicaSet-replika (i henhold til pod-skabelonen i ReplicaSet-definitionen) og gemmer dem på lager:
Planlægningsprogrammet lanceres og sporer pods, der endnu ikke er blevet tildelt nogen arbejderknudepunkter:
Planlæggeren vælger en passende arbejderknude for hver pod og tilføjer denne information til poddefinitionen i butikken:
På den arbejderknude, som poden er tildelt, startes Kubelet, den sporer de pods, der er tildelt denne node:
Kubelet læser pod-definitionen fra lageret og instruerer en container-runtime, såsom Docker, til at starte containere på noden:

Nedenfor er en tekstversion af denne beskrivelse.

API-anmodningen til ReplicaSet-oprettelsesslutpunktet behandles af API-serveren. API-serveren godkender anmodningen og gemmer ReplicaSet-ressourcedefinitionen på lager.

Denne hændelse starter ReplicaSet-controlleren, som er en underproces af controller-manageren. ReplicaSet-controlleren overvåger oprettelse, opdatering og sletning af ReplicaSet-ressourcer i butikken og modtager en hændelsesmeddelelse, når dette sker.

ReplicaSet-controllerens opgave er at sikre, at det nødvendige antal ReplicaSet-pods findes. I vores eksempel eksisterer der endnu ingen pods, så ReplicaSet-controlleren opretter disse pod-definitioner (i henhold til pod-skabelonen i ReplicaSet-definitionen) og gemmer dem på lager.

Oprettelsen af nye pods udløses af en skemalægger, der holder styr på poddefinitioner, der endnu ikke er planlagt til arbejderknudepunkter. Planlæggeren vælger en passende arbejderknude for hver pod og opdaterer pod-definitionerne i lageret.

Bemærk, at indtil dette tidspunkt kørte ingen arbejdsbelastningskode nogen steder i klyngen. Alt hvad der er blevet gjort indtil videre — dette er oprettelse og opdatering af ressourcer i repository på masterknudepunktet.

Den sidste hændelse udløser Kubelets, som overvåger de pods, der er planlagt til deres arbejdernoder. Kubelet for den arbejderknude, som dine ReplicaSet-pods er installeret på, skal instruere container-runtime, såsom Docker, om at downloade de nødvendige containerbilleder og køre dem.

På dette tidspunkt kører din ReplicaSet-applikation endelig!

Rolle af Kubernetes API

Som du så i det foregående eksempel, holder Kubernetes-komponenter (undtagen API-serveren og lageret) øje med ændringer af ressourcer i lager og ændrer oplysninger om ressourcer i lager.

Disse komponenter interagerer naturligvis ikke med lageret direkte, men kun gennem Kubernetes API.

Overvej følgende eksempler:

ReplicaSet-controlleren bruger API-endepunktet liste ReplicaSets med parameter watch for at overvåge ændringer af ReplicaSet-ressourcer.
ReplicaSet-controlleren bruger API-endepunktet oprette Pod (create pod) for at oprette pods.
Scheduler bruger API-endepunkt patch pod (rediger pod) for at opdatere pods med information om den valgte arbejderknude.

Som du kan se, er dette den samme API, som kubectl får adgang til. Brug af den samme API til interne komponenter og eksterne brugere er et grundlæggende koncept i Kubernetes design.

Nu kan vi opsummere, hvordan Kubernetes fungerer:

Lagerlagrene angiver, det vil sige Kubernetes-ressourcer.
API-serveren giver en grænseflade til lageret i form af Kubernetes API.
Alle andre Kubernetes-komponenter og -brugere læser, observerer og manipulerer Kubernetes-tilstand (ressourcer) gennem API'en.

At kende disse begreber vil hjælpe dig med at forstå kubectl bedre og få mest muligt ud af det.

Lad os nu se på nogle specifikke tips og tricks, der hjælper med at forbedre din produktivitet med kubectl.

1. Fremskynd input ved hjælp af kommandofuldførelse

En af de mest nyttige, men ofte oversete, teknikker til at forbedre ydeevnen med kubectl er kommandofuldførelse.

Kommandofuldførelse tillader dele af kubectl-kommandoer at blive fuldført automatisk ved hjælp af Tab-tasten. Dette virker for underkommandoer, muligheder og argumenter, inklusive noget så komplekst som ressourcenavne.

Se, hvordan fuldførelse af kubectl-kommando fungerer:

Kommandoafslutning fungerer for Bash- og Zsh-skaller.

Officiel guide indeholder detaljerede instruktioner til opsætning af autofuldførelse, men nedenfor giver vi et kort uddrag.

Sådan fungerer fuldførelse af kommandoer

Kommandofuldførelse er en shell-funktion, der fungerer ved hjælp af et færdiggørelsesscript. Et udvidelsesscript er et shell-script, der definerer adfærden af en udvidelse for en specifik kommando.

Kubectl genererer og udsender automatisk udvidelsesscripts til Bash og Zsh ved hjælp af følgende kommandoer:

$ kubectl completion bash

Или:

$ kubectl completion zsh

I teorien er det nok at forbinde outputtet af disse kommandoer til den passende kommandoskal, så kubectl kan supplere kommandoerne.

I praksis er forbindelsesmetoden anderledes for Bash (inklusive forskelle mellem Linux og MacOS) og Zsh. Nedenfor vil vi se på alle disse muligheder.

Bash på Linux

Bash completion scriptet afhænger af bash-completion pakken, så du skal installere det først:

$ sudo apt-get install bash-completion

Или:

$ yum install bash-completion

Du kan teste, at pakken er installeret korrekt ved hjælp af følgende kommando:

$ type _init_completion

Hvis dette udsender skalfunktionskode, er bash-completion installeret korrekt. Hvis kommandoen giver en "Ikke fundet" fejl, skal du tilføje følgende linje til din fil ~ / .bashrc:

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

Er det nødvendigt at tilføje denne linje til filen ~ / .bashrc eller ej afhænger af den pakkehåndtering, du brugte til at installere bash-completion. Dette er nødvendigt for APT, men ikke for YUM.

Efter installation af bash-completion, skal du konfigurere alt, så kubectl-fuldførelsesscriptet er aktiveret i alle shell-sessioner.

En måde at gøre dette på er at tilføje følgende linje til filen ~ / .bashrc:

source <(kubectl completion bash)

En anden måde er at tilføje kubectl-udvidelsesscriptet til mappen /etc/bash_completion.d (opret det, hvis det ikke findes):

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

Alle tilføjelsesscripts i kataloget /etc/bash_completion.d er automatisk inkluderet i bash-afslutning.

Begge muligheder er lige anvendelige.

Efter genstart af skallen, vil fuldførelse af kubectl-kommando virke.

Bash på MacOS

På MacOS er opsætningen lidt mere kompliceret. Faktum er, at MacOS som standard bruger Bash version 3.2, og kubectl autofuldførelsesscriptet kræver en Bash version på mindst 4.1 og virker ikke i Bash 3.2.

Der er licensproblemer forbundet med at bruge en forældet version af Bash på MacOS. Bash version 4 er licenseret under GPLv3, som ikke understøttes af Apple.

For at konfigurere kubectl-autofuldførelse på MacOS skal du installere en nyere version af Bash. Du kan også indstille den opdaterede Bash som din standard shell, hvilket vil spare dig for mange problemer i fremtiden. Det er ikke svært, detaljer er givet i artiklen "Opdaterer Bash på MacOS'.

Før du fortsætter, skal du sikre dig, at du bruger en nyere version af Bash (tjek outputtet bash --version).

Bash-afslutningsscript varierer fra projekt til projekt bash-afslutning, så du skal installere det først.

Du kan installere bash-completion vha homebrew:

$ brew install bash-completion@2

Her @2 står for bash-completion version 2. kubectl autocompletion kræver bash-completion v2, og bash-completion v2 kræver minimum Bash version 4.1.

Kommando output brew-install indeholder en sektion med forbehold, som specificerer, hvad der skal tilføjes til filen ~/.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"

Jeg anbefaler dog, at du ikke tilføjer disse linjer ~/.bash_profile, og i ~/.bashrc. I dette tilfælde vil autofuldførelse ikke kun være tilgængelig i hovedet, men også i underordnede kommandoskaller.

Efter genstart af kommandoskallen kan du kontrollere, at installationen er korrekt ved at bruge følgende kommando:

$ type _init_completion

Hvis du ser en shell-funktion i outputtet, er alt konfigureret korrekt.

Nu skal vi sikre, at kubectl-autofuldførelse er aktiveret i alle sessioner.

En måde er at tilføje følgende linje til din ~/.bashrc:

source <(kubectl completion bash)

Den anden måde er at tilføje et autofuldførelsesscript til mappen /usr/local/etc/bash_completion.d:

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

Denne metode virker kun, hvis du har installeret bash-completion ved hjælp af Homebrew. I dette tilfælde indlæser bash-completion alle scripts fra denne mappe.

Hvis du har installeret kubectl ved hjælp af Homebrew, så er det ikke nødvendigt at udføre det forrige trin, da autofuldførelsesscriptet automatisk placeres i mappen /usr/local/etc/bash_completion.d under installationen. I dette tilfælde vil kubectl autofuldførelse begynde at virke, så snart du installerer bash-fuldførelse.

Som et resultat er alle disse muligheder ækvivalente.

zsh

Autofuldførelsesscripts til Zsh kræver ingen afhængigheder. Alt du skal gøre er at aktivere dem, når du indlæser kommandoskallen.

Du kan gøre dette ved at tilføje en linje til din ~/.zshrc fil:

source <(kubectl completion zsh)

Hvis du modtager en fejl not found: compdef efter at have genstartet din shell, skal du aktivere den indbyggede funktion compdef. Du kan aktivere det ved at tilføje det til begyndelsen af din fil ~/.zshrc følgende:

autoload -Uz compinit
compinit

2. Se hurtigt ressourcespecifikationer

Når du opretter YAML-ressourcedefinitioner, skal du kende felterne og deres betydning for disse ressourcer. Et sted at lede efter disse oplysninger er i API-referencen, som indeholder komplette specifikationer for alle ressourcer.

Det er dog ubelejligt at skifte til webbrowseren hver gang du skal søge efter noget. Derfor leverer kubectl kommandoen kubectl explain, som viser specifikationerne for alle ressourcer direkte i din terminal.

Kommandoformatet er som følger:

$ kubectl explain resource[.field]...

Kommandoen vil udlæse specifikationen for den anmodede ressource eller felt. De viste oplysninger er identiske med dem, der er indeholdt i API-manualen.

Som standard kubectl explain viser kun det første niveau af indlejring af marker.

Se hvordan det ser ud Du kan derefter.

Du kan få vist hele træet, hvis du tilføjer muligheden --recursive:

$ kubectl explain deployment.spec --recursive

Hvis du ikke ved præcis, hvilke ressourcer der er nødvendige, kan du vise dem alle med følgende kommando:

$ kubectl api-resources

Denne kommando viser ressourcenavne i flertalsform, f.eks. deployments i stedet for deployment. Den viser f.eks. også det korte navn deploy, for de ressourcer, der har det. Du skal ikke bekymre dig om disse forskelle. Alle disse navngivningsmuligheder svarer til kubectl. Det vil sige, du kan bruge enhver af dem til kubectl explain.

Alle følgende kommandoer er ækvivalente:

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

3. Brug et brugerdefineret kolonneoutputformat

Standard kommando output format 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

Dette format er praktisk, men det indeholder en begrænset mængde information. Sammenlignet med det fulde ressourcedefinitionsformat vises kun nogle få felter her.

I dette tilfælde kan du bruge et brugerdefineret kolonneoutputformat. Det giver dig mulighed for at bestemme, hvilke data der skal udsendes. Du kan vise ethvert ressourcefelt som en separat kolonne.

Brugen af et brugerdefineret format bestemmes ved hjælp af mulighederne:

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

Du kan definere hver outputkolonne som et par <header>:<jsonpath>Hvor <header> er kolonnenavnet, og <jsonpath> — et udtryk, der definerer et ressourcefelt.

Lad os se på et simpelt eksempel:

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

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

Outputtet indeholder en kolonne med navnene på pods.

Indstillingsudtrykket vælger podnavnene fra feltet metadata.name. Dette skyldes, at navnet på poden er defineret i undernavnsfeltet metadata i poddens ressourcebeskrivelse. Flere detaljer kan findes i API guide eller skriv kommandoen kubectl explain pod.metadata.name.

Lad os nu sige, at du vil tilføje en ekstra kolonne til outputtet, for eksempel at vise den node, hver pod kører på. For at gøre dette kan du blot tilføje den relevante kolonnespecifikation til indstillingen for brugerdefinerede kolonner:

$ 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

Udtrykket vælger nodenavnet fra spec.nodeName — når en pod er tildelt en node, skrives dens navn i feltet spec.nodeName pod ressourcespecifikation. Mere detaljeret information kan findes i outputtet kubectl explain pod.spec.nodeName.

Bemærk, at Kubernetes-ressourcefelter skelner mellem store og små bogstaver.

Du kan se ethvert ressourcefelt som en kolonne. Gennemgå blot ressourcespecifikationen og prøv den med de felter, du kan lide.

Men lad os først se nærmere på feltvalgsudtryk.

JSONPath udtryk

Udtryk for valg af ressourcefelter er baseret på JSONPath.

JSONPath er et sprog til at hente data fra JSON-dokumenter. At vælge et enkelt felt er den enkleste use case for JSONPath. Han har meget flere muligheder, herunder vælgere, filtre og så videre.

Kubectl explain understøtter et begrænset antal JSONPath-funktioner. Mulighederne og eksemplerne på deres anvendelse er beskrevet nedenfor:

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

Operatøren [] er særlig vigtig. Mange Kubernetes-ressourcefelter er lister, og denne operatør giver dig mulighed for at vælge medlemmer af disse lister. Det bruges ofte med et jokertegn som [*] til at vælge alle elementer på en liste.

Anvendelseseksempler

Mulighederne for at bruge et brugerdefineret kolonneoutputformat er uendelige, da du kan vise et hvilket som helst felt eller kombination af ressourcefelter i outputtet. Her er nogle eksempler på apps, men du er velkommen til at udforske dem selv og finde applikationer, der virker for dig.

Viser beholderbilleder til pods:

$ kubectl get pods 
  -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'

NAME                        IMAGES
engine-544b6b6467-22qr6     rabbitmq:3.7.8-management,nginx
engine-544b6b6467-lw5t8     rabbitmq:3.7.8-management,nginx
engine-544b6b6467-tvgmg     rabbitmq:3.7.8-management,nginx
web-ui-6db964458-8pdw4      wordpress

Denne kommando viser containerbilledets navne for hver pod.

Husk at en pod kan indeholde flere beholdere, så vil billednavnene blive vist på én linje adskilt af kommaer.

Viser nodes tilgængelighedszoner:
```
$ 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
```
Denne kommando er nyttig, hvis din klynge er hostet i en offentlig sky. Den viser tilgængelighedszonen for hver node.

Tilgængelighedszone er et skykoncept, der begrænser replikationszonen til et geografisk område.

Tilgængelighedszoner for hver node opnås gennem en speciel etiket - failure-domain.beta.kubernetes.io/zone. Hvis klyngen kører i en offentlig sky, oprettes denne etiket automatisk og udfyldes med navnene på tilgængelighedszonerne for hver node.

Etiketter er ikke en del af Kubernetes ressourcespecifikation, så du finder ikke information om dem i API guide. De kan dog ses (som alle andre etiketter), hvis du anmoder om information om noderne i YAML- eller JSON-format:
```
$ kubectl get nodes -o yaml
# или
$ kubectl get nodes -o json
```
Dette er en fantastisk måde at lære mere om ressourcer ud over at lære ressourcespecifikationer.

4. Skift nemt mellem klynger og navneområder

Når kubectl laver en anmodning til Kubernetes API, læser den først kubeconfig-filen for at få alle de nødvendige parametre til forbindelsen.

Som standard er kubeconfig-filen ~/.kube/config. Typisk oprettes eller opdateres denne fil med en speciel kommando.

Når du arbejder med flere klynger, indeholder din kubeconfig-fil indstillinger for tilslutning til alle disse klynger. Du har brug for en måde at fortælle kubectl-kommandoen, hvilken klynge du arbejder med.

Inden for en klynge kan du oprette flere navnerum - en type virtuel klynge i en fysisk klynge. Kubectl bestemmer også hvilket navneområde der skal bruges baseret på kubeconfig-filen. Dette betyder, at du også har brug for en måde at fortælle kubectl-kommandoen, hvilket navneområde der skal arbejdes med.

I dette kapitel vil vi forklare, hvordan det virker, og hvordan man får det til at fungere effektivt.

Bemærk, at du muligvis har flere kubeconfig-filer opført i KUBECONFIG-miljøvariablen. I dette tilfælde vil alle disse filer blive kombineret til én fælles konfiguration under kørsel. Du kan også ændre standard kubeconfig-filen ved at køre kubectl med parameteren --kubeconfig. Se officiel dokumentation.

kubeconfig filer

Lad os se, hvad kubeconfig-filen præcis indeholder:

Som du kan se, indeholder kubeconfig-filen et sæt kontekster. Kontekst består af tre elementer:

Cluster — API-URL for klyngeserveren.
Bruger - brugergodkendelsesoplysninger i klyngen.
Navneområde - det navneområde, der bruges, når du slutter dig til klyngen.

I praksis bruger de ofte én kontekst pr. klynge i deres kubeconfig. Du kan dog have flere kontekster pr. klynge, differentieret efter bruger eller navneområde. Denne multi-kontekst-konfiguration er dog ualmindelig, så der er normalt en en-til-en-mapping mellem klynger og kontekster.

På ethvert givet tidspunkt er en af sammenhængene aktuel:

Når kubectl læser en konfigurationsfil, tager den altid information fra den aktuelle kontekst. I eksemplet ovenfor vil kubectl oprette forbindelse til Hare-klyngen.

For at skifte til en anden klynge skal du derfor ændre den aktuelle kontekst i kubeconfig-filen:

Nu vil kubectl oprette forbindelse til Fox-klyngen.

For at skifte til et andet navneområde i den samme klynge skal du ændre værdien af navnerumselementet for den aktuelle kontekst:

I ovenstående eksempel vil kubectl bruge Fox-klyngens Prod-navneområde (tidligere blev Test-navnerummet indstillet).

Bemærk, at kubectl også giver muligheder --cluster, --user, --namespace и --context, som giver dig mulighed for at overskrive individuelle elementer og selve den aktuelle kontekst, uanset hvad der er indstillet i kubeconfig. Se kubectl options.

I teorien kan du manuelt ændre indstillingerne i kubeconfig. Men det er ubelejligt. For at forenkle disse operationer er der forskellige værktøjer, der giver dig mulighed for at ændre parametre automatisk.

Brug kubectx

Et meget populært værktøj til at skifte mellem klynger og navneområder.

Værktøjet giver kommandoer kubectx и kubens for at ændre henholdsvis den aktuelle kontekst og navnerum.

Som nævnt betyder ændring af den aktuelle kontekst at ændre klyngen, hvis du kun har én kontekst pr. klynge.

Her er et eksempel på at køre disse kommandoer:

I det væsentlige redigerer disse kommandoer blot kubeconfig-filen som beskrevet ovenfor.

at installere kubectx, følg instruktionerne på Github.

Begge kommandoer understøtter autofuldførelse af kontekst- og navneområdenavne, hvilket eliminerer behovet for at skrive dem fuldstændigt. Instruktioner til opsætning af autofuldførelse her.

En anden nyttig funktion kubectx er interaktiv tilstand. Det fungerer sammen med værktøjet fzf, som skal installeres separat. Installation af fzf gør automatisk interaktiv tilstand tilgængelig i kubectx. Interaktivt kan du vælge kontekst og navneområde gennem den interaktive gratis søgegrænseflade fra fzf.

Brug af shell-aliaser

Du behøver ikke separate værktøjer for at ændre den aktuelle kontekst og navneområde, fordi kubectl også giver kommandoer til dette. Ja, hold kubectl config giver underkommandoer til redigering af kubeconfig-filer.

Her er nogle af dem:

kubectl config get-contexts: Vis alle sammenhænge;
kubectl config current-context: få aktuel kontekst;
kubectl config use-context: ændre nuværende kontekst;
kubectl config set-context: Skift kontekstelementet.

Det er dog ikke særlig praktisk at bruge disse kommandoer, fordi de er lange. Du kan lave shell-aliaser til dem, som er nemme at udføre.

Jeg oprettede et sæt aliaser baseret på disse kommandoer, der giver funktionalitet svarende til kubectx. Her kan du se dem i aktion:

Bemærk, at aliaser bruger fzf til at give en interaktiv gratis opslagsgrænseflade (som kubectx' interaktive tilstand). Det betyder, at du har brug for installer fzfat bruge disse aliasser.

Her er definitionerne af selve aliaserne:

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

For at indstille disse aliaser skal du tilføje ovenstående definitioner til din fil ~/.bashrc eller ~/.zshrc og genstart din shell.

Brug af plugins

Kubectl giver dig mulighed for at indlæse plugins, der udføres på samme måde som grundlæggende kommandoer. Du kan for eksempel installere kubectl-foo-plugin'et og køre det ved at udføre kommandoen kubectl foo.

Det ville være praktisk at ændre konteksten og navnerummet på denne måde, for eksempel ved at køre kubectl ctx at ændre kontekst og kubectl ns for at ændre navneområdet.

Jeg har skrevet to plugins, der gør dette:

Arbejdet med plugins er baseret på aliaser fra det foregående afsnit.

Sådan fungerer de:

Bemærk, at plugins bruger fzf til at give en interaktiv gratis søgegrænseflade (som kubectx' interaktive tilstand). Det betyder, at du har brug for installer fzfat bruge disse aliasser.

For at installere plugins skal du downloade shell-scripts med navn kubectl-ctx и kubectl-ns til enhver mappe i din PATH-variabel og gør dem eksekverbare med f.eks. chmod +x. Umiddelbart herefter vil du være i stand til at bruge kubectl ctx и kubectl ns.

5. Reducer input med autoaliaser

Shell aliaser er en god måde at fremskynde input. Projekt kubectl-aliaser indeholder omkring 800 genveje til grundlæggende kubectl-kommandoer.

Du undrer dig måske - hvordan husker du 800 aliaser? Men du behøver ikke at huske dem alle, fordi de er bygget efter et simpelt skema, som er givet nedenfor:

For eksempel:

kgpooyaml - kubectl get pods oyaml
ksysgsvcw — kubectl -n kube-system få svc w
ksysrmcm -kubectl -n kube-system rm cm
kgdepallsl - kubectl få udrulning alle sl

Som du kan se, består aliaser af komponenter, som hver repræsenterer et specifikt element i kubectl-kommandoen. Hvert alias kan have én komponent til basiskommando, operation og ressource og flere komponenter til parametre. Du "udfylder" blot disse komponenter fra venstre mod højre i henhold til diagrammet ovenfor.

Det aktuelle detaljerede diagram er kl GitHub. Der kan du også finde komplet liste over aliaser.

For eksempel svarer aliaset kgpooyamlall til kommandoen kubectl get pods -o yaml --all-namespaces.

Den relative rækkefølge af mulighederne er ikke vigtig: kommando kgpooyamlall svarer til kommandoen kgpoalloyaml.

Du behøver ikke bruge alle komponenter som aliaser. For eksempel k, kg, klo, ksys, kgpo kan også bruges. Desuden kan du kombinere aliaser og almindelige kommandoer eller muligheder på kommandolinjen:

For eksempel:

I stedet for kubectl proxy du kan skrive k proxy.
I stedet for kubectl get roles du kan skrive kg roles (der er i øjeblikket intet alias for Roller-ressourcen).
For at få data for en bestemt pod kan du bruge kommandoen kgpo my-pod — kubectl get pod my-pod.

Bemærk venligst, at nogle aliaser kræver et kommandolinjeargument. For eksempel alias kgpol betyder kubectl get pods -l. Mulighed -l kræver et argument - en etiketspecifikation. Hvis du bruger et alias vil det se ud kgpol app=ui.

Fordi nogle aliaser kræver argumenter, skal aliasserne a, f og l bruges sidst.

Generelt, når du først har fået styr på dette skema, kan du intuitivt udlede aliaser fra de kommandoer, du vil udføre, og spare en masse skrivetid.

Installation

For at installere kubectl-aliaser skal du downloade filen .kubectl_aliaser fra GitHub og inkludere det i filen ~/.bashrc eller ~/.zshrc:

source ~/.kubectl_aliases

Autofuldførelse

Som vi sagde før, tilføjer du ofte yderligere ord til et alias på kommandolinjen. For eksempel:

$ kgpooyaml test-pod-d4b77b989

Hvis du bruger kubectl-kommandofuldførelse, har du sandsynligvis brugt autofuldførelse til ting som ressourcenavne. Men kan dette lade sig gøre, når der bruges aliaser?

Dette er et meget vigtigt spørgsmål, for hvis autofuldførelse ikke virker, vil du miste nogle af fordelene ved aliaser.

Svaret afhænger af, hvilken shell du bruger:

For Zsh fungerer fuldførelse af alias uden for boksen.
For Bash kræves der desværre noget arbejde for at få autofuldførelse til at fungere.

Aktiverer autofuldførelse for aliaser i Bash

Problemet med Bash er, at den forsøger at fuldføre (hver gang du trykker på Tab) aliasset, ikke kommandoen, som aliaset refererer til (som Zsh f.eks. gør). Da du ikke har færdiggørelsesscripts for alle 800 aliaser, virker autofuldførelse ikke.

Projekt komplet-alias giver en generel løsning på dette problem. Den forbinder til fuldførelsesmekanismen for aliaser, udvider internt aliaset til en kommando og returnerer fuldførelsesmuligheder for den fuldførte kommando. Det betyder, at udfyldningen for et alias opfører sig nøjagtigt det samme som for en fuld kommando.

I det følgende vil jeg først forklare, hvordan man installerer complete-alias og derefter hvordan man konfigurerer det til at aktivere færdiggørelse for alle kubectl-aliaser.

Installerer komplet-alias

Først og fremmest afhænger komplet-alias af bash-afslutning. Derfor, før du installerer complete-alias, skal du sikre dig, at bash-completion er installeret. Der er tidligere leveret installationsinstruktioner til Linux og MacOS.

Vigtig bemærkning til MacOS-brugere: Ligesom kubectl autofuldførelsesscriptet virker complete-alias ikke med Bash 3.2, som er standard på MacOS. Især afhænger komplet-alias af bash-fuldførelse v2 (brew install bash-completion@2), som kræver mindst Bash 4.1. Dette betyder, at for at bruge komplet-alias på MacOS skal du installere en nyere version af Bash.

Du skal downloade scriptet bash_completion.sh af GitHub-depot og inkludere det i din fil ~/.bashrc:

source ~/bash_completion.sh

Efter genstart af skallen, vil complete-alias være fuldt installeret.

Aktiverer autofuldførelse for kubectl-aliasser

Teknisk komplet-alias giver en indpakningsfunktion _complete_alias. Denne funktion kontrollerer alias og returnerer fuldførelsestip for alias-kommandoen.

For at knytte en funktion til et specifikt alias skal du bruge den indbyggede Bash-mekanisme fuldføre, at installere _complete_alias som en alias-fuldførelsesfunktion.

Som et eksempel, lad os tage aliaset k, som står for kommandoen kubectl. at installere _complete_alias Som en komplementfunktion til dette alias skal du køre følgende kommando:

$ complete -F _complete_alias k

Resultatet af dette er, at hver gang du autofuldfører et alias k, kaldes funktionen _complete_alias, som kontrollerer aliaset og returnerer fuldførelsestip for kommandoen kubectl.

Som et andet eksempel, lad os tage aliaset kg, som betegner kubectl get:

$ complete -F _complete_alias kg

Ligesom i det foregående eksempel, når du autofuldfører kg, får du de samme færdiggørelsestip, som du ville få for kubectl get.

Bemærk, at du kan bruge komplet-alias til ethvert alias på dit system.

Derfor, for at aktivere autofuldførelse for alle kubectl-aliasser, skal du køre ovenstående kommando for hver af dem. Det følgende uddrag gør præcis dette, forudsat at du har sat kubectl-aliaser til ~/.kubectl-aliases:

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

Dette stykke kode skal placeres i din ~/.bashrc, genstart kommandoskallen, og autofuldførelse bliver tilgængelig for alle 800 kubectl-aliasser.

6. Udvidelse af kubectl med plugins

Begyndende fra version 1.12, kubectl understøtter plugin mekanisme, som giver dig mulighed for at udvide dens funktioner med yderligere kommandoer.

Hvis du er bekendt med Git plugin mekanismer, så er kubectl-plugins bygget efter samme princip.

I dette kapitel vil vi dække, hvordan du installerer plugins, hvor du finder dem, og hvordan du opretter dine egne plugins.

Installation af plugins

Kubectl-plugins distribueres som simple eksekverbare filer med navnet som kubectl-x. Præfiks kubectl- er påkrævet, efterfulgt af en ny kubectl-underkommando, der giver dig mulighed for at kalde plugin'et.

For eksempel vil hello plugin blive distribueret som en fil kaldet kubectl-hello.

For at installere plugin'et skal du kopiere filen kubectl-x til enhver mappe i din PATH og gør den eksekverbar, for eksempel med chmod +x. Umiddelbart herefter kan du ringe til plugin med kubectl x.

Du kan bruge følgende kommando til at liste alle plugins, der i øjeblikket er installeret på dit system:

$ kubectl plugin list

Denne kommando vil også vise advarsler, hvis du har flere plugins med samme navn, eller hvis der er en plugins-fil, der ikke er eksekverbar.

Finde og installere plugins ved hjælp af Krew

Kubectl-plugins kan deles eller genbruges som softwarepakker. Men hvor kan du finde plugins, som andre har delt?

Projekt Krew har til formål at levere en samlet løsning til deling, søgning, installation og styring af kubectl-plugins. Projektet kalder sig selv en "pakke manager for kubectl plugins" (Krew ligner Brygge).

Krew er en liste over kubectl-plugins, som du kan vælge og installere. Samtidig er Krew også et plugin til kubectl.

Dette betyder, at installation af Krew i det væsentlige fungerer som at installere ethvert andet kubectl-plugin. Du kan finde detaljerede instruktioner på snit GitHub.

De vigtigste Krew-kommandoer er:

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

Bemærk venligst, at installation af plugins ved hjælp af Krew ikke forstyrrer installation af plugins ved hjælp af standardmetoden beskrevet ovenfor.

Bemærk venligst, at kommandoen kubectl krew list viser kun plugins, der blev installeret ved hjælp af Krew, mens kommandoen kubectl plugin list viser alle plugins, det vil sige dem, der er installeret ved hjælp af Krew, og dem, der er installeret med andre metoder.

Find plugins andetsteds

Krew er et ungt projekt, der i øjeblikket er i gang listen kun omkring 30 plugins. Hvis du ikke kan finde det, du har brug for, kan du finde plugins andre steder, såsom GitHub.

Jeg anbefaler at se på GitHub-sektionen kubectl-plugins. Der vil du finde snesevis af tilgængelige plugins, som er værd at tjekke ud.

At skrive dine egne plugins

du kan selv oprette plugins - Det er ikke svært. Du skal oprette en eksekverbar fil, der gør det, du har brug for, navngive det kubectl-x og installer som beskrevet ovenfor.

Filen kan være et bash-script, et python-script eller et kompileret GO-program – det er lige meget. Den eneste betingelse er, at den kan udføres direkte i operativsystemet.

Lad os oprette et eksempel plugin lige nu. I det forrige afsnit brugte du kommandoen kubectl til at liste beholderne for hver pod. Det er nemt at lave denne kommando om til et plugin, som du kan kalde med f.eks. kubectl img.

Opret en fil kubectl-img følgende indhold:

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

Gør nu filen eksekverbar med chmod +x kubectl-img og flyt den til en hvilken som helst mappe i din PATH. Umiddelbart herefter kan du bruge plugin'et kubectl img.

Som nævnt kan kubectl-plugins skrives i ethvert programmerings- eller scriptsprog. Hvis du bruger shell-scripts, er fordelen ved nemt at kunne kalde kubectl inde fra plugin'et. Du kan dog skrive mere komplekse plugins i rigtige programmeringssprog ved hjælp af Kubernetes klientbibliotek. Hvis du bruger Go, kan du også bruge cli-runtime bibliotek, som eksisterer specifikt til at skrive kubectl-plugins.

Sådan deler du dine plugins

Hvis du tror, at dine plugins kan være nyttige for andre, er du velkommen til at dele dem på GitHub. Sørg for at tilføje dem til emnet kubectl-plugins.

Du kan også anmode om at få tilføjet dit plugin Krew liste. Instruktioner til, hvordan du gør dette, er inde GitHub-depoter.

Kommandofuldførelse

Plugins understøtter i øjeblikket ikke autofuldførelse. Det vil sige, at du skal indtaste det fulde navn på plugin'et og de fulde navne på argumenterne.

GitHub kubectl-lageret for denne funktion har åben anmodning. Så det er muligt, at denne funktion vil blive implementeret engang i fremtiden.

Held og lykke!!!

Hvad skal man ellers læse om emnet:

Kilde: www.habr.com

Sådan bruger du kubectl mere effektivt: en detaljeret vejledning