🥇Hvordan bruke kubectl mer effektivt: en detaljert veiledning

Hvis du jobber med Kubernetes, er kubectl sannsynligvis et av verktøyene du bruker mest. Og når du bruker mye tid på å jobbe med et bestemt verktøy, lønner det seg å studere det godt og lære å bruke det effektivt.

Lag Kubernetes aaS fra Mail.ru oversatt en artikkel av Daniel Weibel der du finner tips og triks for å jobbe effektivt med kubectl. Det vil også hjelpe deg å få en dypere forståelse av Kubernetes.

Ifølge forfatteren er målet med artikkelen å gjøre ditt daglige arbeid med Kubernetes ikke bare mer effektivt, men også morsommere!

Introduksjon: Hva er kubectl

Før du kan lære å bruke kubectl mer effektivt, må du få en grunnleggende forståelse av hva det er og hvordan det fungerer.

Fra et brukerperspektiv er kubectl et kontrollpanel som lar deg utføre Kubernetes-operasjoner.

Teknisk sett er kubectl en Kubernetes API-klient.

Kubernetes API er en HTTP REST API. Denne APIen er det sanne Kubernetes-brukergrensesnittet, som det er fullstendig kontrollert gjennom. Dette betyr at hver Kubernetes-operasjon er eksponert som et API-endepunkt og kan gjøres med en HTTP-forespørsel til det endepunktet.

Derfor er hovedoppgaven til kubectl å sende HTTP-forespørsler til Kubernetes API:

Kubernetes er et fullstendig ressursorientert system. Dette betyr at den opprettholder ressursens interne tilstand og alle Kubernetes-operasjoner er CRUD-operasjoner.

Du har full kontroll over Kubernetes ved å administrere disse ressursene, og Kubernetes finner ut hva de skal gjøre basert på ressursens nåværende tilstand. Av denne grunn er Kubernetes API-referansen organisert som en liste over ressurstyper med tilhørende operasjoner.

La oss se på et eksempel.

La oss si at du vil opprette en ReplicaSet-ressurs. For å gjøre dette, beskriver du ReplicaSet i en fil ved navn replicaset.yaml, kjør deretter kommandoen:

$ kubectl create -f replicaset.yaml

Dette vil opprette en ReplicaSet-ressurs. Men hva skjer bak kulissene?

Kubernetes har en ReplicaSet-opprettingsoperasjon. Som enhver annen operasjon er den eksponert som et API-endepunkt. Det spesifikke API-endepunktet for denne operasjonen ser slik ut:

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

API-endepunkter for alle Kubernetes-operasjoner finner du på API-referanse (inkludert endepunktet ovenfor). For å gjøre en faktisk forespørsel til et endepunkt, må du først legge til API-server-URLen til endepunktbanene som er oppført i API-referansen.

Derfor, når du utfører kommandoen ovenfor, sender kubectl en HTTP POST-forespørsel til API-endepunktet ovenfor. ReplicaSet-definisjonen du oppga i filen replicaset.yaml, sendes i forespørselens brødtekst.

Dette er hvordan kubectl fungerer for alle kommandoer som samhandler med Kubernetes-klyngen. I alle disse tilfellene gjør kubectl ganske enkelt HTTP-forespørsler til de riktige Kubernetes API-endepunktene.

Vær oppmerksom på at du fullt ut kan administrere Kubernetes ved å bruke et verktøy som f.eks curlved å manuelt sende HTTP-forespørsler til Kubernetes API. Kubectl gjør det enkelt å bruke Kubernetes API.

Dette er det grunnleggende om hva kubectl er og hvordan det fungerer. Men det er noe annet med Kubernetes API som enhver kubectl-bruker bør vite. La oss ta en rask titt inn i Kubernetes indre verden.

Kubernetes indre verden

Kubernetes består av et sett med uavhengige komponenter som kjører som separate prosesser på klyngenoder. Noen komponenter kjører på masternoder, andre på arbeidernoder, hver komponent utfører sin egen spesifikke oppgave.

Her er de viktigste komponentene på hovednodene:

repository - lagrer ressursdefinisjoner (vanligvis er det osv).
API-server — gir en API og administrerer lagring.
Controller Manager — Sikrer at ressursstatuser samsvarer med spesifikasjoner.
Planlegger — planlegger pods på arbeidernoder.

Og her er en viktigste komponent på arbeidernodene:

kubelet — administrerer lanseringen av containere på arbeidsnoden.

For å forstå hvordan disse komponentene fungerer sammen, la oss se på et eksempel.

La oss anta at du nettopp har fullført kubectl create -f replicaset.yaml, hvoretter kubectl sendte en HTTP POST-forespørsel til ReplicaSet API-endepunkt (bestått ReplicaSet-ressursdefinisjonen).

Hva skjer i klyngen?

Etter å ha gjort kubectl create -f replicaset.yaml API-serveren lagrer ReplicaSet-ressursdefinisjonen i lagring:
Deretter lanseres ReplicaSet-kontrolleren i kontrolleren, som håndterer opprettelse, modifikasjon og sletting av ReplicaSet-ressurser:
ReplicaSet-kontrolleren oppretter en poddefinisjon for hver ReplicaSet-replika (i henhold til podmalen i ReplicaSet-definisjonen) og lagrer dem i lagring:
Planleggeren er lansert og sporer pods som ennå ikke er tilordnet noen arbeidernoder:
Planleggeren velger en passende arbeidernode for hver pod og legger til denne informasjonen til poddefinisjonen i butikken:
På arbeidernoden som poden er tilordnet til, startes Kubelet, den sporer podene som er tildelt denne noden:
Kubelet leser pod-definisjonen fra lagring og instruerer en containerkjøringstid, for eksempel Docker, om å starte containere på noden:

Nedenfor er en tekstversjon av denne beskrivelsen.

API-forespørselen til ReplicaSet-opprettingsendepunktet behandles av API-serveren. API-serveren autentiserer forespørselen og lagrer ReplicaSet-ressursdefinisjonen i lagring.

Denne hendelsen starter ReplicaSet-kontrolleren, som er en underprosess av kontrolleren. ReplicaSet-kontrolleren overvåker opprettelsen, oppdateringen og slettingen av ReplicaSet-ressurser i butikken og mottar en hendelsesvarsling når dette skjer.

ReplicaSet-kontrollerens jobb er å sikre at det nødvendige antallet ReplicaSet-pods finnes. I vårt eksempel eksisterer ingen pods ennå, så ReplicaSet-kontrolleren oppretter disse poddefinisjonene (i henhold til podmalen i ReplicaSet-definisjonen) og lagrer dem i lagring.

Opprettelsen av nye pods utløses av en planlegger som holder styr på poddefinisjoner som ennå ikke er planlagt for arbeidernoder. Planleggeren velger en passende arbeidernode for hver pod og oppdaterer poddefinisjonene i depotet.

Vær oppmerksom på at frem til dette tidspunktet kjørte ingen arbeidsbelastningskode noe sted i klyngen. Alt som er gjort så langt - dette er opprettelse og oppdatering av ressurser i depotet på masternoden.

Den siste hendelsen utløser Kubelets, som overvåker podene som er planlagt for arbeidernodene deres. Kubelet til arbeidernoden som ReplicaSet-podene dine er installert på, må instruere beholderens kjøretid, for eksempel Docker, om å laste ned de nødvendige beholderbildene og kjøre dem.

På dette tidspunktet kjører endelig ReplicaSet-applikasjonen din!

Rollen til Kubernetes API

Som du så i forrige eksempel, ser Kubernetes-komponenter (bortsett fra API-serveren og lagringen) etter endringer i ressurser i lagring og endrer informasjon om ressurser i lagring.

Disse komponentene samhandler selvfølgelig ikke med lagringen direkte, men bare gjennom Kubernetes API.

Tenk på følgende eksempler:

ReplicaSet-kontrolleren bruker API-endepunktet liste ReplicaSets med parameter watch for å overvåke endringer i ReplicaSet-ressurser.
ReplicaSet-kontrolleren bruker API-endepunktet opprette Pod (opprett pod) for å lage poder.
Scheduler bruker API-endepunkt patch pod (rediger pod) for å oppdatere pods med informasjon om den valgte arbeidernoden.

Som du kan se, er dette det samme API-et som kubectl får tilgang til. Å bruke samme API for interne komponenter og eksterne brukere er et grunnleggende konsept i Kubernetes-design.

Nå kan vi oppsummere hvordan Kubernetes fungerer:

Lagringsbutikkene oppgir, det vil si Kubernetes-ressurser.
API-serveren gir et grensesnitt til lagringen i form av Kubernetes API.
Alle andre Kubernetes-komponenter og brukere leser, observerer og manipulerer Kubernetes-tilstand (ressurser) gjennom API.

Å kjenne disse konseptene vil hjelpe deg å forstå kubectl bedre og få mest mulig ut av det.

La oss nå se på noen spesifikke tips og triks som vil bidra til å forbedre produktiviteten din med kubectl.

1. Få fart på inndata ved hjelp av kommandofullføring

En av de mest nyttige, men ofte oversett, teknikkene for å forbedre ytelsen med kubectl er kommandofullføring.

Kommandofullføring lar deg fullføre deler av kubectl-kommandoer automatisk ved å bruke Tab-tasten. Dette fungerer for underkommandoer, alternativer og argumenter, inkludert noe så komplekst som ressursnavn.

Se hvordan kubectl-kommandofullføring fungerer:

Kommandofullføring fungerer for Bash- og Zsh-skjell.

Offisiell guide inneholder detaljerte instruksjoner for å sette opp autofullføring, men nedenfor gir vi et kort utdrag.

Hvordan kommandofullføring fungerer

Kommandofullføring er en skallfunksjon som fungerer ved hjelp av et fullføringsskript. Et utvidelsesskript er et skallskript som definerer oppførselen til en utvidelse for en bestemt kommando.

Kubectl genererer og sender automatisk ut utvidelsesskript for Bash og Zsh ved å bruke følgende kommandoer:

$ kubectl completion bash

Или:

$ kubectl completion zsh

I teorien er det nok å koble utdataene fra disse kommandoene til det riktige kommandoskallet slik at kubectl kan utfylle kommandoene.

I praksis er tilkoblingsmetoden forskjellig for Bash (inkludert forskjeller mellom Linux og MacOS) og Zsh. Nedenfor vil vi se på alle disse alternativene.

Bash på Linux

Bash-kompletteringsskriptet avhenger av bash-completion-pakken, så du må installere det først:

$ sudo apt-get install bash-completion

Или:

$ yum install bash-completion

Du kan teste at pakken er vellykket installert ved å bruke følgende kommando:

$ type _init_completion

Hvis dette gir ut shell-funksjonskode, er bash-completion installert riktig. Hvis kommandoen gir en "Ikke funnet"-feil, må du legge til følgende linje i filen ~ / .bashrc:

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

Er det nødvendig å legge til denne linjen i filen ~ / .bashrc eller ikke avhenger av pakkebehandlingen du brukte til å installere bash-completion. Dette er nødvendig for APT, men ikke for YUM.

Etter å ha installert bash-completion, må du konfigurere alt slik at kubectl-fullføringsskriptet er aktivert i alle shell-økter.

En måte å gjøre dette på er å legge til følgende linje i filen ~ / .bashrc:

source <(kubectl completion bash)

En annen måte er å legge til kubectl-utvidelsesskriptet til katalogen /etc/bash_completion.d (opprett det hvis det ikke finnes):

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

Alle tilleggsskript i katalogen /etc/bash_completion.d er automatisk inkludert i bash-fullføring.

Begge alternativene er like aktuelle.

Etter å ha startet skallet på nytt, vil fullføring av kubectl-kommandoen fungere.

Bash på MacOS

På MacOS er oppsettet litt mer komplisert. Faktum er at MacOS som standard bruker Bash versjon 3.2, og kubectl autofullføringsskriptet krever en Bash-versjon på minst 4.1 og fungerer ikke i Bash 3.2.

Det er lisensieringsproblemer knyttet til bruk av en utdatert versjon av Bash på MacOS. Bash versjon 4 er lisensiert under GPLv3, som ikke støttes av Apple.

For å konfigurere kubectl-autofullføring på MacOS, må du installere en nyere versjon av Bash. Du kan også angi den oppdaterte Bash som standard skall, noe som vil spare deg for mange problemer i fremtiden. Det er ikke vanskelig, detaljer er gitt i artikkelen "Oppdaterer Bash på MacOS'.

Før du fortsetter, sørg for at du bruker en nyere versjon av Bash (sjekk utdataene bash --version).

Bash-fullføringsskriptet varierer fra prosjekt til prosjekt bash-fullføring, så du må installere den først.

Du kan installere bash-komplettering ved å bruke Homebrew:

$ brew install bash-completion@2

Her @2 står for bash-completion versjon 2. kubectl autocompletion krever bash-completion v2, og bash-completion v2 krever minimum Bash versjon 4.1.

Kommandoutgang brew-install inneholder en seksjon for forbehold, som spesifiserer hva som må legges 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 imidlertid å ikke legge til disse linjene ~/.bash_profileog i ~/.bashrc. I dette tilfellet vil autofullføring være tilgjengelig ikke bare i hovedmenyen, men også i underordnede kommandoskall.

Etter å ha startet kommandoskallet på nytt, kan du bekrefte at installasjonen er riktig ved å bruke følgende kommando:

$ type _init_completion

Hvis du ser en skallfunksjon i utgangen, er alt konfigurert riktig.

Nå må vi sørge for at kubectl-autofullføring er aktivert i alle økter.

En måte er å legge til følgende linje i din ~/.bashrc:

source <(kubectl completion bash)

Den andre måten er å legge til et autofullføringsskript i mappen /usr/local/etc/bash_completion.d:

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

Denne metoden vil bare fungere hvis du installerte bash-completion med Homebrew. I dette tilfellet laster bash-completion alle skript fra denne katalogen.

Hvis du har installert kubectl ved hjelp av Homebrew, så er det ikke nødvendig å utføre det forrige trinnet, siden autofullføringsskriptet vil automatisk plasseres i mappen /usr/local/etc/bash_completion.d under installasjonen. I dette tilfellet vil kubectl-autofullføring begynne å fungere så snart du installerer bash-fullføring.

Som et resultat er alle disse alternativene likeverdige.

Zsh

Autofullføringsskript for Zsh krever ingen avhengigheter. Alt du trenger å gjøre er å aktivere dem når du laster inn kommandoskallet.

Du kan gjøre dette ved å legge til en linje i din ~/.zshrc fil:

source <(kubectl completion zsh)

Hvis du får en feilmelding not found: compdef etter å ha startet skallet på nytt, må du aktivere den innebygde funksjonen compdef. Du kan aktivere den ved å legge den til i begynnelsen av filen ~/.zshrc følgende:

autoload -Uz compinit
compinit

2. Se raskt ressursspesifikasjoner

Når du oppretter YAML-ressursdefinisjoner, må du kjenne til feltene og deres betydning for disse ressursene. Ett sted å se etter denne informasjonen er i API-referansen, som inneholder fullstendige spesifikasjoner for alle ressurser.

Det er imidlertid ubeleilig å bytte til nettleseren hver gang du trenger å søke etter noe. Derfor gir kubectl kommandoen kubectl explain, som viser spesifikasjonene til alle ressursene rett i terminalen din.

Kommandoformatet er som følger:

$ kubectl explain resource[.field]...

Kommandoen vil gi ut spesifikasjonen for den forespurte ressursen eller feltet. Informasjonen som vises er identisk med informasjonen i API-manualen.

Som standard kubectl explain viser bare det første nivået av hekking av felt.

Se hvordan det ser ut Du kan deretter.

Du kan vise hele treet hvis du legger til alternativet --recursive:

$ kubectl explain deployment.spec --recursive

Hvis du ikke vet nøyaktig hvilke ressurser som trengs, kan du vise dem alle med følgende kommando:

$ kubectl api-resources

Denne kommandoen viser ressursnavn i flertallsform, f.eks. deployments i stedet for deployment. Den viser også det korte navnet, for eksempel deploy, for de ressursene som har det. Ikke bekymre deg for disse forskjellene. Alle disse navnealternativene tilsvarer kubectl. Det vil si at du kan bruke hvilken som helst av dem til kubectl explain.

Alle følgende kommandoer er likeverdige:

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

3. Bruk et tilpasset kolonneutdataformat

Standard kommandoutdataformat 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 formatet er praktisk, men det inneholder en begrenset mengde informasjon. Sammenlignet med formatet for fullstendig ressursdefinisjon, vises bare noen få felt her.

I dette tilfellet kan du bruke et tilpasset kolonneutdataformat. Den lar deg bestemme hvilke data som skal sendes ut. Du kan vise et hvilket som helst ressursfelt som en egen kolonne.

Bruken av et tilpasset format bestemmes ved hjelp av alternativene:

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

Du kan definere hver utdatakolonne som et par <header>:<jsonpath>Der <header> er kolonnenavnet, og <jsonpath> – et uttrykk som definerer et ressursfelt.

La oss se på et enkelt eksempel:

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

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

Utdataene inneholder én kolonne med navnene på podene.

Alternativuttrykket velger podnavnene fra feltet metadata.name. Dette er fordi navnet på poden er definert i undernavnfeltet metadata i ressursbeskrivelsen til poden. Flere detaljer finner du i API-veiledning eller skriv inn kommandoen kubectl explain pod.metadata.name.

La oss nå si at du vil legge til en ekstra kolonne til utdata, for eksempel å vise noden hver pod kjører på. For å gjøre dette kan du ganske enkelt legge til den aktuelle kolonnespesifikasjonen til alternativet for egendefinerte 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

Uttrykket velger nodenavnet fra spec.nodeName — når en pod er tilordnet en node, skrives navnet i feltet spec.nodeName pod-ressursspesifikasjon. Mer detaljert informasjon finnes i utgangen kubectl explain pod.spec.nodeName.

Vær oppmerksom på at Kubernetes-ressursfelt skiller mellom store og små bokstaver.

Du kan vise et hvilket som helst ressursfelt som en kolonne. Bare se gjennom ressursspesifikasjonen og prøv den med alle feltene du liker.

Men først, la oss se nærmere på feltuttrykk.

JSONPath-uttrykk

Uttrykk for valg av ressursfelt er basert på JSONPath.

JSONPath er et språk for å hente data fra JSON-dokumenter. Å velge et enkelt felt er den enkleste brukssaken for JSONPath. Han har mye større stemme, inkludert velgere, filtre og så videre.

Kubectl explain støtter et begrenset antall JSONPath-funksjoner. Mulighetene og eksemplene på deres bruk 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 spesielt viktig. Mange Kubernetes-ressursfelt er lister, og denne operatøren lar deg velge medlemmer av disse listene. Det brukes ofte med et jokertegn som [*] for å velge alle elementene i en liste.

Applikasjonseksempler

Mulighetene for å bruke et tilpasset kolonneutdataformat er uendelige, siden du kan vise hvilket som helst felt eller kombinasjon av ressursfelt i utdataene. Her er noen eksempler på apper, men utforsk dem gjerne selv og finn apper som fungerer for deg.

Viser beholderbilder for 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 kommandoen viser beholderbildenavnene for hver pod.

Husk at en pod kan inneholde flere beholdere, da vil bildenavnene vises på én linje, atskilt med komma.

Viser nodetilgjengelighetssoner:
```
$ 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 kommandoen er nyttig hvis klyngen din er vert i en offentlig sky. Den viser tilgjengelighetssonen for hver node.

Tilgjengelighetssone er et skykonsept som begrenser replikeringssonen til et geografisk område.

Tilgjengelighetssoner for hver node oppnås gjennom en spesiell etikett - failure-domain.beta.kubernetes.io/zone. Hvis klyngen kjører i en offentlig sky, opprettes denne etiketten automatisk og fylles med navnene på tilgjengelighetssonene for hver node.

Etiketter er ikke en del av Kubernetes ressursspesifikasjon, så du finner ikke informasjon om dem i API-veiledning. De kan imidlertid sees (som alle andre etiketter) hvis du ber om informasjon om nodene i YAML- eller JSON-format:
```
$ kubectl get nodes -o yaml
# или
$ kubectl get nodes -o json
```
Dette er en fin måte å lære mer om ressurser, i tillegg til å lære ressursspesifikasjoner.

4. Bytt enkelt mellom klynger og navneområder

Når kubectl sender en forespørsel til Kubernetes API, leser den først kubeconfig-filen for å få alle nødvendige parametere for tilkoblingen.

Som standard er kubeconfig-filen ~/.kube/config. Vanligvis opprettes eller oppdateres denne filen av en spesiell kommando.

Når du jobber med flere klynger, inneholder kubeconfig-filen innstillinger for å koble til alle disse klyngene. Du trenger en måte å fortelle kubectl-kommandoen hvilken klynge du jobber med.

Innenfor en klynge kan du opprette flere navnerom – en type virtuell klynge i en fysisk klynge. Kubectl bestemmer også hvilket navneområde som skal brukes basert på kubeconfig-filen. Dette betyr at du også trenger en måte å fortelle kubectl-kommandoen hvilket navneområde du skal jobbe med.

I dette kapittelet vil vi forklare hvordan det fungerer og hvordan du får det til å fungere effektivt.

Merk at du kan ha flere kubeconfig-filer oppført i KUBECONFIG-miljøvariabelen. I dette tilfellet vil alle disse filene bli kombinert til én felles konfigurasjon ved kjøring. Du kan også endre standard kubeconfig-filen ved å kjøre kubectl med parameteren --kubeconfig. Se offisiell dokumentasjon.

kubeconfig-filer

La oss se nøyaktig hva kubeconfig-filen inneholder:

Som du kan se, inneholder kubeconfig-filen et sett med kontekster. Kontekst består av tre elementer:

Cluster — API-URL for klyngeserveren.
Bruker - brukerautentiseringslegitimasjon i klyngen.
Navneområde - navneområdet som brukes når du blir med i klyngen.

I praksis bruker de ofte én kontekst per klynge i kubeconfig. Du kan imidlertid ha flere kontekster per klynge, differensiert etter bruker eller navneområde. Imidlertid er denne flerkontekstkonfigurasjonen uvanlig, så det er vanligvis en en-til-en-kartlegging mellom klynger og kontekster.

Til enhver tid er en av kontekstene aktuell:

Når kubectl leser en konfigurasjonsfil, tar den alltid informasjon fra gjeldende kontekst. I eksemplet ovenfor vil kubectl koble seg til Hare-klyngen.

Følgelig, for å bytte til en annen klynge, må du endre gjeldende kontekst i kubeconfig-filen:

Nå vil kubectl koble seg til Fox-klyngen.

For å bytte til et annet navneområde i samme klynge, må du endre verdien til navneromselementet for gjeldende kontekst:

I eksemplet ovenfor vil kubectl bruke Fox-klyngens Prod-navneområde (tidligere ble testnavneområdet satt).

Merk at kubectl også gir alternativer --cluster, --user, --namespace и --context, som lar deg overskrive individuelle elementer og selve gjeldende kontekst, uavhengig av hva som er satt i kubeconfig. Se kubectl options.

I teorien kan du manuelt endre innstillingene i kubeconfig. Men det er upraktisk. For å forenkle disse operasjonene er det forskjellige verktøy som lar deg endre parametere automatisk.

Bruk kubectx

Et veldig populært verktøy for å bytte mellom klynger og navneområder.

Verktøyet gir kommandoer kubectx и kubens for å endre henholdsvis gjeldende kontekst og navneområde.

Som nevnt betyr å endre gjeldende kontekst å endre klyngen hvis du bare har én kontekst per klynge.

Her er et eksempel på hvordan du kjører disse kommandoene:

I hovedsak redigerer disse kommandoene bare kubeconfig-filen som beskrevet ovenfor.

å installere kubectx, følg instruksjonene på GitHub.

Begge kommandoene støtter autofullføring av kontekst- og navneromsnavn, noe som eliminerer behovet for å skrive dem fullstendig. Instruksjoner for å sette opp autofullføring her.

En annen nyttig funksjon kubectx er interaktiv modus. Det fungerer sammen med verktøyet fzf, som må installeres separat. Ved å installere fzf blir interaktiv modus automatisk tilgjengelig i kubectx. Interaktivt kan du velge kontekst og navneområde gjennom det interaktive gratis søkegrensesnittet fra fzf.

Bruke skallaliaser

Du trenger ikke separate verktøy for å endre gjeldende kontekst og navneområde fordi kubectl også gir kommandoer for dette. Ja, team kubectl config gir underkommandoer for redigering av kubeconfig-filer.

Her er noen av dem:

kubectl config get-contexts: vis alle kontekster;
kubectl config current-context: få gjeldende kontekst;
kubectl config use-context: endre gjeldende kontekst;
kubectl config set-context: Endre kontekstelementet.

Det er imidlertid ikke særlig praktisk å bruke disse kommandoene direkte fordi de er lange. Du kan lage skallaliaser for dem som er enkle å utføre.

Jeg opprettet et sett med aliaser basert på disse kommandoene som gir funksjonalitet som ligner på kubectx. Her kan du se dem i aksjon:

Merk at aliaser bruker fzf for å gi et interaktivt gratis oppslagsgrensesnitt (som kubectx sin interaktive modus). Dette betyr at du trenger installer fzfå bruke disse aliasene.

Her er definisjonene av selve aliasene:

# Получить текущий контекст
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 å angi disse aliasene må du legge til definisjonene ovenfor i filen din ~/.bashrc eller ~/.zshrc og start skallet på nytt.

Bruker plugins

Kubectl lar deg laste inn plugins som kjøres på samme måte som grunnleggende kommandoer. Du kan for eksempel installere kubectl-foo plugin og kjøre den ved å utføre kommandoen kubectl foo.

Det ville være praktisk å endre konteksten og navneområdet på denne måten, for eksempel ved å kjøre kubectl ctx å endre kontekst og kubectl ns for å endre navneområdet.

Jeg har skrevet to plugins som gjør dette:

Arbeidet med plugins er basert på aliaser fra forrige seksjon.

Slik fungerer de:

Merk at pluginene bruker fzf for å gi et interaktivt gratis søkegrensesnitt (som kubectx sin interaktive modus). Dette betyr at du trenger installer fzfå bruke disse aliasene.

For å installere plugins, må du laste ned shell scripts navngitt kubectl-ctx и kubectl-ns til en hvilken som helst katalog i PATH-variabelen din og gjør dem kjørbare med f.eks. chmod +x. Umiddelbart etter dette vil du kunne bruke kubectl ctx и kubectl ns.

5. Reduser input med autoaliaser

Shell-aliaser er en god måte å øke hastigheten på input. Prosjekt kubectl-aliaser inneholder omtrent 800 snarveier for grunnleggende kubectl-kommandoer.

Du lurer kanskje - hvordan husker du 800 aliaser? Men du trenger ikke å huske dem alle, fordi de er bygget i henhold til et enkelt opplegg, som er gitt nedenfor:

For eksempel:

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

Som du kan se, består aliaser av komponenter, som hver representerer et spesifikt element i kubectl-kommandoen. Hvert alias kan ha én komponent for basiskommandoen, operasjonen og ressursen, og flere komponenter for parametere. Du "befolker" disse komponentene fra venstre til høyre i henhold til diagrammet ovenfor.

Det nåværende detaljerte diagrammet er kl GitHub. Der kan du også finne fullstendig liste over aliaser.

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

Den relative rekkefølgen av alternativene er ikke viktig: kommando kgpooyamlall tilsvarer kommandoen kgpoalloyaml.

Du trenger ikke bruke alle komponenter som aliaser. For eksempel k, kg, klo, ksys, kgpo kan også brukes. Dessuten kan du kombinere aliaser og vanlige kommandoer eller alternativer 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 (det er for øyeblikket ikke noe alias for Roller-ressursen).
For å få data for en bestemt pod, kan du bruke kommandoen kgpo my-pod — kubectl get pod my-pod.

Vær oppmerksom på at noen aliaser krever et kommandolinjeargument. For eksempel alias kgpol betyr kubectl get pods -l. Alternativ -l krever et argument - en etikettspesifikasjon. Hvis du bruker et alias vil det se ut som kgpol app=ui.

Fordi noen alias krever argumenter, må aliasene a, f og l brukes sist.

Generelt, når du først har fått taket på dette opplegget, kan du intuitivt utlede aliaser fra kommandoene du vil utføre og spare mye skrivetid.

installasjon

For å installere kubectl-aliaser, må du laste ned filen .kubectl_aliaser fra GitHub og inkludere den i filen ~/.bashrc eller ~/.zshrc:

source ~/.kubectl_aliases

Autofullføring

Som vi sa før, legger du ofte til flere ord til et alias på kommandolinjen. For eksempel:

$ kgpooyaml test-pod-d4b77b989

Hvis du bruker kubectl-kommandofullføring, har du sannsynligvis brukt autofullføring for ting som ressursnavn. Men kan dette gjøres når aliaser brukes?

Dette er et veldig viktig spørsmål fordi hvis autofullføring ikke fungerer, vil du miste noen av fordelene med aliaser.

Svaret avhenger av hvilket skall du bruker:

For Zsh fungerer aliasfullføring rett ut av boksen.
For Bash kreves det dessverre noe arbeid for å få autofullføring til å fungere.

Aktiverer autofullføring for aliaser i Bash

Problemet med Bash er at den prøver å fullføre (hver gang du trykker Tab) aliaset, ikke kommandoen som aliaset refererer til (som Zsh for eksempel gjør). Siden du ikke har fullføringsskript for alle 800 aliaser, fungerer ikke autofullføring.

Prosjekt komplett-alias gir en generell løsning på dette problemet. Den kobles til fullføringsmekanismen for aliaser, utvider aliaset internt til en kommando, og returnerer fullføringsalternativer for den fullførte kommandoen. Dette betyr at utfyllingen for et alias oppfører seg nøyaktig det samme som for en full kommando.

I det følgende vil jeg først forklare hvordan du installerer komplett-alias og deretter hvordan du konfigurerer det for å aktivere fullføring for alle kubectl-aliaser.

Installerer komplett-alias

Først av alt, komplett-alias avhenger av bash-fullføring. Derfor, før du installerer complete-alias, må du sørge for at bash-completion er installert. Installasjonsinstruksjoner har blitt gitt tidligere for Linux og MacOS.

Viktig merknad for MacOS-brukere: I likhet med kubectl autofullføringsskriptet, fungerer ikke complete-alias med Bash 3.2, som er standard på MacOS. Spesielt avhenger komplett-alias av bash-fullføring v2 (brew install bash-completion@2), som krever minst Bash 4.1. Dette betyr at for å bruke komplett-alias på MacOS må du installere en nyere versjon av Bash.

Du må laste ned skriptet bash_completion.sh av GitHub-depot og inkludere den i filen din ~/.bashrc:

source ~/bash_completion.sh

Etter omstart av skallet, vil complete-alias være fullstendig installert.

Aktiverer autofullføring for kubectl-aliaser

Teknisk komplett-alias gir en innpakningsfunksjon _complete_alias. Denne funksjonen sjekker aliaset og returnerer fullføringstips for aliaskommandoen.

For å knytte en funksjon til et spesifikt alias, må du bruke den innebygde Bash-mekanismen fullføre, å installere _complete_alias som en alias fullføringsfunksjon.

Som et eksempel, la oss ta aliaset k, som står for kommandoen kubectl. å installere _complete_alias Som en komplementfunksjon for dette aliaset, bør du kjøre følgende kommando:

$ complete -F _complete_alias k

Resultatet av dette er at hver gang du autofullfører et alias k, kalles funksjonen _complete_alias, som sjekker aliaset og returnerer fullføringstips for kommandoen kubectl.

Som et annet eksempel, la oss ta aliaset kg, som betegner kubectl get:

$ complete -F _complete_alias kg

Akkurat som i forrige eksempel, når du autofullfører kg, får du de samme fullføringstipsene som du ville fått for kubectl get.

Merk at du kan bruke komplett-alias for alle aliaser på systemet ditt.

Derfor, for å aktivere autofullføring for alle kubectl-aliaser, må du kjøre kommandoen ovenfor for hver av dem. Følgende kodebit gjør akkurat dette, forutsatt at du har satt kubectl-aliaser til ~/.kubectl-aliases:

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

Denne kodebiten må plasseres i din ~/.bashrc, start kommandoskallet på nytt og autofullføring vil bli tilgjengelig for alle 800 kubectl-aliaser.

6. Utvide kubectl med plugins

Starter fra versjon 1.12, støtter kubectl plugin-mekanisme, som lar deg utvide funksjonene med flere kommandoer.

Hvis du er kjent med Git plugin-mekanismer, så er kubectl-plugins bygget på samme prinsipp.

I dette kapittelet vil vi dekke hvordan du installerer plugins, hvor du finner dem og hvordan du lager dine egne plugins.

Installerer plugins

Kubectl-plugins distribueres som enkle kjørbare filer med navnet som kubectl-x. Prefiks kubectl- er nødvendig, etterfulgt av en ny kubectl-underkommando som lar deg kalle opp plugin-modulen.

For eksempel vil hello-pluginen bli distribuert som en fil kalt kubectl-hello.

For å installere plugin-en må du kopiere filen kubectl-x til en hvilken som helst katalog i PATH og gjør den kjørbar, for eksempel med chmod +x. Umiddelbart etter dette kan du ringe plugin med kubectl x.

Du kan bruke følgende kommando for å liste alle plugins som for øyeblikket er installert på systemet ditt:

$ kubectl plugin list

Denne kommandoen vil også vise advarsler hvis du har flere plugins med samme navn, eller hvis det er en plugin-fil som ikke er kjørbar.

Finne og installere plugins ved hjelp av Krew

Kubectl-plugins kan deles eller gjenbrukes som programvarepakker. Men hvor kan du finne plugins som andre har delt?

Prosjekt Krew har som mål å tilby en enhetlig løsning for å dele, søke, installere og administrere kubectl-plugins. Prosjektet kaller seg en "pakkebehandling for kubectl-plugins" (Krew ligner på Brygge).

Krew er en liste over kubectl-plugins som du kan velge og installere. Samtidig er Krew også en plugin for kubectl.

Dette betyr at installasjon av Krew fungerer i hovedsak som å installere alle andre kubectl-plugin. Du finner detaljerte instruksjoner på GitHub-siden.

De viktigste Krew-kommandoene er:

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

Vær oppmerksom på at installasjon av plugins ved hjelp av Krew ikke forstyrrer installasjon av plugins ved bruk av standardmetoden beskrevet ovenfor.

Vær oppmerksom på at kommandoen kubectl krew list viser bare plugins som ble installert med Krew, mens kommandoen kubectl plugin list viser alle plugins, det vil si de som er installert med Krew og de som er installert med andre metoder.

Finne plugins andre steder

Krew er et ungt prosjekt som for tiden er i gang listen bare rundt 30 plugins. Hvis du ikke finner det du trenger, kan du finne plugins andre steder, for eksempel GitHub.

Jeg anbefaler å se på GitHub-delen kubectl-plugins. Der finner du dusinvis av tilgjengelige plugins som er verdt å sjekke ut.

Skrive dine egne plugins

du kan selv lage plugins – Det er ikke vanskelig. Du må lage en kjørbar fil som gjør det du trenger, navngi det kubectl-x og installer som beskrevet ovenfor.

Filen kan være et bash-skript, et python-skript eller en kompilert GO-applikasjon - det spiller ingen rolle. Den eneste betingelsen er at den kan kjøres direkte i operativsystemet.

La oss lage et eksempelplugin akkurat nå. I forrige seksjon brukte du kubectl-kommandoen til å liste opp beholderne for hver pod. Det er enkelt å gjøre denne kommandoen om til en plugin som du kan ringe med f.eks. kubectl img.

Opprett en fil kubectl-img følgende innhold:

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

Gjør nå filen kjørbar med chmod +x kubectl-img og flytt den til en hvilken som helst katalog i PATH. Umiddelbart etter dette kan du bruke plugin kubectl img.

Som nevnt kan kubectl-plugins skrives i et hvilket som helst programmerings- eller skriptspråk. Hvis du bruker shell-skript, er fordelen ved å enkelt kunne ringe kubectl fra plugin-modulen. Du kan imidlertid skrive mer komplekse plugins på ekte programmeringsspråk ved å bruke Kubernetes klientbibliotek. Hvis du bruker Go, kan du også bruke cli-runtime-bibliotek, som eksisterer spesielt for å skrive kubectl-plugins.

Slik deler du pluginene dine

Hvis du tror at pluginene dine kan være nyttige for andre, kan du gjerne dele dem på GitHub. Sørg for å legge dem til emnet kubectl-plugins.

Du kan også be om at plugin-en din legges til Krew liste. Instruksjoner for hvordan du gjør dette er i GitHub-lagre.

Kommandofullføring

Programtillegg støtter for øyeblikket ikke autofullføring. Det vil si at du må skrive inn hele navnet på plugin-en og de fulle navnene på argumentene.

GitHub kubectl-depotet for denne funksjonen har åpen forespørsel. Så det er mulig at denne funksjonen vil bli implementert en gang i fremtiden.

Lykke til!!!

Hva annet å lese om emnet:

Kilde: www.habr.com

Hvordan bruke kubectl mer effektivt: en detaljert veiledning