Sådan bruger du kubectl effektivt: en detaljeret vejledning

Lad os se et enkelt eksempel:

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

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

Outputtet indeholder én kolonne med pod-navne.

Udtrykket i optionen vælger pod-navne fra feltet metadata.name. Dette skyldes, at pod-navnet defineres i det underliggende felt name i feltet metadata i beskrivelsen af ressourcen for pod'en. Du kan læse mere i API-guiden eller indtaste kommandoen kubectl explain pod.metadata.name.

Antag at du vil tilføje en ekstra kolonne til output, som for eksempel viser, hvilken node hver pod kører på. For at gøre dette kan du blot tilføje den relevante kolonnenspecifikation i 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

Udsagnet vælger navnet på noden fra spec.nodeName — når en pod tildeles til en node, skrives dens navn ind i feltet spec.nodeName ressourcespecifikationen for pod'en. Yderligere information kan ses i outputtet af kubectl explain pod.spec.nodeName.

Bemærk, at Kubernetes resource-felter er case-sensitive.

Du kan se ethvert resource-felt i form af en kolonne. Gennemgå blot resource-specifikationen og prøv dig frem med enhver felter, du ønsker.

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

JSONPath-udtryk

Udtryk til valg af resource-felter er baseret på JSONPath.

JSONPath er et sprog til at udtrække data fra JSON-dokumenter. At vælge et enkelt felt er den mest grundlæggende brug af JSONPath. Det har meget flere muligheder, herunder vælgere, filtre og så videre.

Kubectl explain understøtter et begrænset antal JSONPath-funktioner. Nedenfor er mulighederne og eksempler på deres anvendelse:

# Выбрать все элементы списка
$ 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 [] har en særlig betydning. Mange Kubernetes resource-felter er lister, og denne operator gør det muligt at vælge elementer fra disse lister. Det bruges ofte med et wildcard som [*] for at vælge alle elementer i listen.

Eksempler på anvendelse

Mulighederne for at bruge brugerdefineret kolonne-outputformat er ubegrænsede, da du kan vise ethvert felt eller enhver kombination af felter fra ressourcen i output. Her er nogle anvendelseseksempler, men tøv ikke med at udforske dem selv og finde nyttige anvendelser for dig.

1. Visning af containerbilleder 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 kommando viser navnene på containerbillederne for hver pod.

   Husk, at der kan være flere containere under, så billednavnene vil blive vist på én linje adskilt med komma.

2. Visning af tilgængelighedszoner for noder:

   $ 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 praktisk, hvis din klynge er hostet i en offentlig sky. Den viser tilgængelighedszonen for hver node.

   En tilgængelighedszone er et skybegreb, der begrænser replikationsområdet til en geografisk region.

   Tilgængelighedszoner for hver node hentes gennem en specifik etikette — topology.kubernetes.io/zone. Hvis klyngen kører i en offentlig sky, oprettes denne etikette automatisk og fyldes med navne på tilgængelighedszoner for hver node.

   Etiketter er ikke en del af specifikationen af Kubernetes-ressourcer, så du finder ikke information om dem i API-guiden. Men de kan ses (som enhver anden etiket), hvis du anmoder om oplysninger om noder i YAML- eller JSON-format:

   $ kubectl get nodes -o yaml
   # eller
   $ kubectl get nodes -o json

   Dette er en fremragende måde at lære mere om ressourcer på, ud over at studere ressource-specifikationerne.

4. Let skift mellem klynger og navnerum

Når kubectl foretager en forespørgsel til Kubernetes API, læser den først kubeconfig-filen for at hente alle nødvendige parametre til forbindelsen.

Som standard er kubeconfig-filen ~/.kube/config. Normalt oprettes eller opdateres denne fil med en særlig kommando.

Når du arbejder med flere klynger, indeholder din kubeconfig-fil forbindelsesparametre til alle disse klynger. Du har brug for en måde at angive til kubectl, hvilken specifik klynge du arbejder med.

Inden for klyngen kan du oprette flere navnerum — en slags virtuel klynge inden for den fysiske klynge. Kubectl bestemmer, hvilket navnerum der skal bruges, også ud fra kubeconfig-filen. Det betyder, at du også har brug for en måde at angive til kubectl, hvilket navnerum der skal arbejdes med.

I dette kapitel vil vi forklare, hvordan dette fungerer, og hvordan du opnår effektiv drift.

Bemærk, at du kan have flere kubeconfig-filer angivet i miljøvariablen KUBECONFIG. I så fald vil alle disse filer blive sammenflettet til én samlet konfiguration under kørsel. Du kan også ændre den standard kubeconfig-fil, der anvendes, ved at køre kubectl med parameteren --kubeconfig. Se den officielle dokumentation.

Kubeconfig-filer

Lad os se, hvad kubeconfig-filen indeholder:

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

• Cluster — URL til API-serveren for klyngen.
• User — autentificeringsoplysninger for brugeren i klyngen.
• Namespace — navnerum, der anvendes ved tilslutning til klyngen.

I praksis anvender man ofte en kontekst pr. klynge i sin kubeconfig-fil. Du kan dog have flere kontekster for en klynge, der adskiller sig efter bruger eller navnerum. En sådan konfiguration med flere kontekster forekommer sjældent, så der er normalt en entydig sammenhæng mellem klynger og kontekster.

På ethvert tidspunkt er en af konteksterne den aktuelle:

Når kubectl læser konfigurationsfilen, tages der altid information fra den aktuelle kontekst. I eksemplet ovenfor vil kubectl oprette forbindelse til klyngen Hare.

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

Nu vil kubectl oprette forbindelse til klyngen Fox.

For at skifte til et andet navnerum i den samme klynge, skal du ændre værdien for elementet namespace for den aktuelle kontekst:

I det ovenstående eksempel vil kubectl bruge navnerummet Prod i klyngen Fox (det tidligere indstillede navnerum var Test).

Bemærk, at kubectl også tilbyder parametre --cluster, --user, --namespace og --context, som gør det muligt at overskrive individuelle elementer og den aktuelle kontekst, uanset hvad der er angivet i kubeconfig-filen. Se kubectl options.

Teoretisk set kan du manuelt ændre parametrene i kubeconfig-filen. Men det er ikke praktisk. For at forenkle disse operationer findes der forskellige værktøjer, der giver mulighed for at ændre parametrene automatisk.

Brug kubectx

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

Værktøjet tilbyder kommandoerne kubectx og kubens for at ændre den aktuelle kontekst og navnerum henholdsvis.

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

Her er et eksempel på udførelsen af disse kommandoer:

I bund og grund redigerer disse kommandoer blot kubeconfig-filen, som beskrevet ovenfor.

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

Begge kommandoer understøtter autoudfyldelse af navne for kontekster og navnerum, så du ikke behøver at indtaste dem helt. Instruktioner til opsætning af autoudfyldelse her.

En anden nyttig funktion kubectx Baggrunden indeholder tekstur af siden og illustrationer, og dens opløsning er lavere end maskens. Baggrunden gemmes tabsløst for opfattelse med en opløsning på 100 dpi. interaktiv tilstand. Den fungerer sammen med værktøjet fzf, som skal installeres separat. Installation af fzf gør interaktiv tilstand tilgængelig i kubectx. I interaktiv tilstand kan du vælge kontekst og navnerum gennem et interaktivt søgeinterface leveret af fzf.

Brug af shell-aliasser

Du har ikke brug for separate værktøjer til at ændre den aktuelle kontekst og navnerum, fordi kubectl også tilbyder kommandoer til dette. Så kommandoen kubectl config tilbyder underkommandoer til at redigere kubeconfig-filer.

Her er nogle af dem:

• kubectl config get-contexts: viser alle kontekster;
• kubectl config current-context: får den aktuelle kontekst;
• kubectl config use-context: ændrer den aktuelle kontekst;
• kubectl config set-context: ændrer kontekstelementet.

Men det er ikke særlig praktisk at bruge disse kommandoer direkte, fordi de er lange. Du kan lave shell-aliasser for dem, som er nemme at udføre.

Jeg har oprettet et sæt aliasser baseret på disse kommandoer, som tilbyder funktionalitet svarende til kubectx. Her kan du se dem i aktion:

Bemærk, at aliasserne bruger fzf til at levere et interaktivt søgeinterface (som i den interaktive tilstand kubectx). Det betyder, at du skal installere fzf, for at bruge disse aliasser.

Her er definitionerne af aliasserne:

# Получить текущий контекст
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 installere disse aliasser skal du tilføje de givne definitioner til din fil ~\/ .bashrc eller ~/ .zshrc og genstarte dit shell.

Brug af plugins

Kubectl tillader indlæsning af plugins, der kører ligesom de primære kommandoer. Du kan for eksempel installere en plugin kubectl-foo og køre den ved at udføre kommandoen kubectl foo.

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

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

• kubectl-ctx
• kubectl-ns

Plugin'ernes funktionalitet er baseret på aliaser fra det foregående afsnit.

Her er, hvordan de fungerer:

Bemærk, at plugins bruger fzf til at give et interaktivt grænseflade til fri søgning (som i interaktiv tilstand med kubectx). Dette betyder, at du skal installere fzf, for at bruge disse aliasser.

For at installere plugins skal du downloade shell-scripts med navnene kubectl-ctx og kubectl-ns til en hvilken som helst katalog i din PATH-variabel og gøre dem eksekverbare, for eksempel ved hjælp af chmod +x. Umiddelbart efter dette kan du bruge kubectl ctx og kubectl ns.

5. Forkortet indtastning med autoaliaser

Shell-aliaser er en god måde at fremskynde indtastningen på. Projektet kubectl-aliases indeholder omkring 800 forkortelser for de grundlæggende kubectl-kommandoer.

Du undrer dig måske — hvordan kan jeg huske 800 aliaser? Men du behøver ikke at huske dem alle, da de er bygget efter et simpelt mønster, som er beskrevet nedenfor:

For eksempel:

1. kgpooyaml — kubectl get pods oyaml
2. ksysgsvcw — kubectl -n kube-system get svc w
3. ksysrmcm — kubectl -n kube-system rm cm
4. kgdepallsl — kubectl get deployment all sl

Som du kan se, består aliaser af komponenter, hvor hver repræsenterer et bestemt element i kubectl-kommandoen. Hver alias kan have én komponent til grundkommandoen, operationen og ressourcen samt flere komponenter til parametrene. Du 'fylder' blot disse komponenter fra venstre mod højre i henhold til det ovenfor nævnte mønster.

Den aktuelle detaljerede skema findes på GitHub. Der kan du også finde den komplette liste over synonymer.

For eksempel er alias kgpooyamlall lig med kommandoen kubectl get pods -o yaml --all-namespaces.

Den relative rækkefølge af muligheder er ikke vigtig: kommandoen kgpooyamlall er lig med kommandoen kgpoalloyaml.

Du kan 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 valgmuligheder i kommandolinjen:

For eksempel:

1. I stedet for kubectl proxy kan skrives som k proxy.
2. I stedet for kubectl get roles kan skrives som kg roles (der eksisterer i øjeblikket ikke et alias for ressourcen Roles).
3. For at få data for en bestemt pod kan du bruge kommandoen kgpo my-pod — kubectl get pod my-pod.

Vær opmærksom på, at nogle aliaser kræver et argument i kommandolinjen. For eksempel er aliaset kgpol betyder kubectl get pods -l. Muligheden -l kræver et argument – et etiketspecifikation. Hvis du bruger et alias, ser det ud som kgpol app=ui.

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

Generelt, så snart du mestrer dette mønster, kan du intuitivt udlede aliaser fra de kommandoer, du ønsker at udføre, og spare meget tid på indtastningen.

Installation

For at installere kubectl-aliases skal du downloade filen .kubectl_aliases fra GitHub og inkludere den i filen ~\/ .bashrc eller ~/ .zshrc:

source ~\/ .kubectl_aliases

Automatisk fuldførelse

Som vi allerede har nævnt, tilføjer du ofte ekstra ord til aliaset i kommandolinjen. For eksempel:

$ kgpooyaml test-pod-d4b77b989

Hvis du bruger automatisk fuldførelse af kubectl-kommandoen, har du sandsynligvis brugt automatisk fuldførelse til ting som ressourcenavne. Men kan dette gøres, når der bruges aliaser?

Dette er et meget vigtigt spørgsmål, fordi hvis automatisk fuldførelse ikke fungerer, går du glip af nogle af fordelene ved aliaser.

Svaret afhænger af, hvilken kommandolinje du bruger:

1. For Zsh fungerer automatisk fuldførelse for aliaser «out of the box».
2. For Bash er der desværre nogle trin, der er nødvendige for at få automatisk fuldførelse til at fungere.

Aktivering af automatisk fuldførelse for aliaser i Bash

Problemet med Bash er, at det forsøger at fuldføre (hver gang du trykker på Tab) et alias og ikke den kommando, som aliaset henviser til (som Zsh gør). Da du ikke har fuldender til alle 800 aliaser, fungerer automatisk fuldførelse ikke.

Projekt complete-alias giver en generel løsning på dette problem. Den tilslutter sig mekanismen for fuldførelse for aliaser, fuldender intern aliaset til en kommando og returnerer forslag til fuldførelse for den fuldendte kommando. Dette betyder, at fuldførelsen for aliaset opfører sig nøjagtigt som for den fulde kommando.

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

Installation af complete-alias

Først og fremmest afhænger complete-alias af bash-completion. Derfor skal du sørge for, at bash-completion er installeret, inden du installerer complete-alias. Instruktioner til installation er givet tidligere for Linux og MacOS.

Vigtig bemærkning til brugere af MacOS: ligesom skriptet til automatisk fuldførelse af kubectl, fungerer complete-alias ikke med Bash 3.2, som standard bruges i MacOS. Især afhænger complete-alias af bash-completion v2 (brew install bash-completion@2), som kræver mindst Bash 4.1. Det betyder, at for at bruge complete-alias på MacOS skal du installere en nyere version af Bash.

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

source ~/bash_completion.sh

Efter genstart af kommandolinjen vil complete-alias være helt installeret.

Aktivering af autoudfyldning for kubectl-aliaser

Teknisk set giver complete-alias en shells funktion _complete_alias. Denne funktion tjekker aliaset og returnerer autoudfyldningsforslag til alias-kommandoen.

For at binde funktionen til et bestemt alias skal du bruge den indbyggede Bash-mekanisme complete, for at indstille _complete_alias som en alias autoudfyldningsfunktion.

Som eksempel tager vi aliaset k, der repræsenterer kommandoen kubectl. For at indstille _complete_alias som autoudfyldningsfunktionen for dette alias skal du køre følgende kommando:

$ complete -F _complete_alias k

Resultatet af dette er, at hver gang du autoudfylder aliaset k, kaldes funktionen _complete_alias, som tjekker aliaset og returnerer autoudfyldningsforslagene til kommandoen kubectl.

Som et andet eksempel lad os tage aliaset kg, som repræsenterer kubectl get:

$ complete -F _complete_alias kg

På samme måde som i det tidligere eksempel, når du autoudfylder kg, får du de samme autoudfyldningsforslag, som du ville få for kubectl get.

Bemærk, at complete-alias kan bruges til ethvert alias i dit system.

Derfor, for at aktivere autoudfyldning for alle kubectl-aliaser, skal du køre den nævnte kommando for hver af dem. Det følgende fragment gør netop dette, forudsat at du har installeret kubectl-aliases i ~/ .kubectl-aliases:

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

Denne kodebit skal placeres i din ~\/ .bashrc, genstart kommandolinjen, og autoudfyldning vil være tilgængelig for alle 800 kubectl-aliaser.

6. Udvidelse af kubectl med plugins

Startende med Fra version 1.12, understøtter kubectl et pluginsystem, som tillader udvidelse af dets funktioner med yderligere kommandoer.

Hvis du er bekendt med Git pluginsystemer, er kubectl-plugins bygget på samme princip.

I dette kapitel vil vi forklare, hvordan man installerer plugins, hvor man finder dem, og hvordan man opretter sine egne plugins.

Installation af plugins

Kubectl-plugins distribueres som enkle eksekverbare filer med et navn af typen kubectl-x. Præfikset kubectl- er obligatorisk, efterfulgt af den nye kubectl-underkommando, som gør det muligt at kalde pluginet.

For eksempel vil pluginet hello blive distribueret som en fil med navnet kubectl-hello.

For at installere pluginet skal du kopiere filen kubectl-x til en hvilken som helst mappe i din PATH-variabel og gøre den eksekverbar, for eksempel ved hjælp af chmod +x. Umiddelbart efter dette kan du kalde pluginet med kubectl x.

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

$ kubectl plugin list

Denne kommando viser også advarsler, hvis du har flere plugins med de samme navne, eller hvis der er en plugin-fil, der ikke er eksekverbar.

Søgning og installation af plugins med Krew

Kubectl-plugins er egnede til deling eller genbrug ligesom softwarepakker. Men hvor kan man finde plugins, som andre har delt?

Krew-projektet er rettet mod at give en ensartet løsning til deling, søgning, installation og administration af kubectl-plugins. Projektet kalder sig selv "pakkehåndtering til kubectl-plugins" (Krew er ligesom Brew).

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

Det betyder, at installationen af Krew fungerer stort set som installationen af ethvert andet kubectl-plugin. Du kan finde detaljerede instruktioner på GitHub-siden.

De vigtigste Krew-kommandoer:

# Поиск в списке плагинов
$ 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, at installationen af plugins med Krew ikke forhindrer installationen af plugins på den standardmåde, der er beskrevet ovenfor.

Bemærk, at kommandoen kubectl krew list viser kun de plugins, der er installeret ved hjælp af Krew, mens kommandoen kubectl plugin list oplister alle plugins, det vil sige dem installeret ved hjælp af Krew, og dem installeret på andre måder.

Søgning efter plugins andre steder

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

Jeg anbefaler at kigge i sektionen GitHub kubectl-plugins. Der finder du flere dusin tilgængelige plugins, som er værd at se nærmere på.

Skrive dine egne plugins

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

Filen kan være et bash-script, et python-script eller et kompilere go-program — det er ligegyldigt. Det eneste krav er, at den skal kunne køres direkte i operativsystemet.

Lad os oprette et eksempelplugin lige nu. I det forrige afsnit brugte du kommandoen kubectl til at udskrive en liste over containere for hver pod. Det er let at forvandle denne kommando til et plugin, som du kan kalde, for eksempel med kubectl img.

Opret en fil kubectl-img med følgende indhold:

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

Nu skal du gøre filen eksekverbar ved hjælp af chmod +x kubectl-img og flytte den til en hvilken som helst mappe i din PATH. Så snart du gør dette, kan du bruge pluginet. kubectl img.

Som nævnt kan kubectl plugins skrives på ethvert programmeringssprog eller scriptsprog. Hvis du bruger shell scripts, er fordelene, at du nemt kan kalde kubectl fra pluginet. Men du kan skrive mere komplekse plugins på rigtige programmeringssprog ved at bruge Kubernetes klientbiblioteket. Hvis du bruger Go, kan du også bruge cli-runtime biblioteket, som er designet specifikt til at skrive kubectl plugins.

Hvordan man deler sine plugins

Hvis du mener, at dine plugins kan være nyttige for andre, så tøv ikke med at dele dem på GitHub. Husk at tilføje dem til emnet kubectl-plugins.

Du kan også anmode om at få tilføjet dit plugin til Krew-listen. Der er instruktioner om, hvordan man gør dette, i GitHub-repositoriet.

Automatisk fuldførelse af kommandoer

I øjeblikket understøtter plugins ikke autocompletion. Det vil sige, du skal indtaste det fulde navn på pluginet og de fulde navne på argumenterne.

I GitHub-repositoriet for kubectl er der en åben forespørgsel. Så det er muligt, at denne funktion vil blive implementeret i fremtiden.

Held og lykke!!!

Andre artikler om emnet:

1. Tre niveauer af automatisk skalering i Kubernetes, og hvordan man bruger dem effektivt.
2. Kubernetes i piratånd med en implementeringsskabelon.
3. Vores kanal Omkring Kubernetes på Telegram.

Kilde: habr.com