🥇 Hur man använder kubectl mer effektivt: en detaljerad guide

Om du arbetar med Kubernetes är kubectl förmodligen ett av de verktyg du använder mest. Och när du lägger mycket tid på att arbeta med ett visst verktyg, lönar det sig att studera det väl och lära dig hur man använder det effektivt.

Team Kubernetes aaS från Mail.ru översatt en artikel av Daniel Weibel där du hittar tips och tricks för att arbeta effektivt med kubectl. Det kommer också att hjälpa dig att få en djupare förståelse av Kubernetes.

Enligt författaren är målet med artikeln att göra ditt dagliga arbete med Kubernetes inte bara effektivare, utan också roligare!

Introduktion: Vad är kubectl

Innan du kan lära dig att använda kubectl mer effektivt måste du få en grundläggande förståelse för vad det är och hur det fungerar.

Ur ett användarperspektiv är kubectl en kontrollpanel som låter dig utföra Kubernetes-operationer.

Tekniskt sett är kubectl en Kubernetes API-klient.

Kubernetes API är ett HTTP REST API. Detta API är det sanna Kubernetes-användargränssnittet, genom vilket det är helt kontrollerat. Detta innebär att varje Kubernetes-operation exponeras som en API-slutpunkt och kan göras med en HTTP-begäran till den slutpunkten.

Därför är kubectls huvudsakliga uppgift att göra HTTP-förfrågningar till Kubernetes API:

Kubernetes är ett helt resursorienterat system. Detta innebär att det upprätthåller det interna tillståndet för resurser och alla Kubernetes-operationer är CRUD-operationer.

Du har fullständig kontroll över Kubernetes genom att hantera dessa resurser, och Kubernetes räknar ut vad som ska göras baserat på resursernas nuvarande tillstånd. Av denna anledning är Kubernetes API-referens organiserad som en lista över resurstyper med tillhörande operationer.

Låt oss titta på ett exempel.

Låt oss säga att du vill skapa en ReplicaSet-resurs. För att göra detta beskriver du ReplicaSet i en fil med namn replicaset.yaml, kör sedan kommandot:

$ kubectl create -f replicaset.yaml

Detta kommer att skapa en ReplicaSet-resurs. Men vad händer bakom kulisserna?

Kubernetes har en ReplicaSet-skapande operation. Som alla andra operationer exponeras den som en API-slutpunkt. Den specifika API-slutpunkten för denna operation ser ut så här:

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

API-slutpunkter för alla Kubernetes-operationer finns på API-referens (inklusive ovanstående slutpunkt). För att göra en faktisk begäran till en slutpunkt måste du först lägga till API-serverns URL till slutpunktssökvägarna som anges i API-referensen.

När du kör kommandot ovan skickar kubectl därför en HTTP POST-begäran till ovanstående API-slutpunkt. ReplicaSet-definitionen som du angav i filen replicaset.yaml, skickas i brödtexten i begäran.

Så här fungerar kubectl för alla kommandon som interagerar med Kubernetes-klustret. I alla dessa fall gör kubectl helt enkelt HTTP-förfrågningar till lämpliga Kubernetes API-slutpunkter.

Observera att du helt kan hantera Kubernetes med hjälp av ett verktyg som t.ex curlgenom att manuellt skicka HTTP-förfrågningar till Kubernetes API. Kubectl gör det helt enkelt enklare att använda Kubernetes API.

Detta är grunderna för vad kubectl är och hur det fungerar. Men det finns något annat med Kubernetes API som alla kubectl-användare borde känna till. Låt oss ta en snabb titt in i Kubernetes inre värld.

Kubernetes inre värld

Kubernetes består av en uppsättning oberoende komponenter som körs som separata processer på klusternoder. Vissa komponenter körs på masternoder, andra på arbetarnoder, där varje komponent utför sin egen specifika uppgift.

Här är de viktigaste komponenterna på huvudnoderna:

förvaret - lagrar resursdefinitioner (vanligtvis är det etcd).
API-server — tillhandahåller ett API och hanterar lagring.
Controller Manager — Säkerställer att resursstatus överensstämmer med specifikationer.
Schemaläggare — schemalägger poddar på arbetarnoder.

Och här är en viktig komponent på arbetarnoderna:

kubelet — hanterar lanseringen av containrar på arbetsnoden.

För att förstå hur dessa komponenter fungerar tillsammans, låt oss titta på ett exempel.

Låt oss anta att du precis har slutfört kubectl create -f replicaset.yaml, varefter kubectl gjorde en HTTP POST-begäran till ReplicaSet API-slutpunkt (som klarar ReplicaSet-resursdefinitionen).

Vad händer i klustret?

Efter att ha gjort kubectl create -f replicaset.yaml API-servern lagrar din ReplicaSet-resursdefinition i lagring:
Därefter startas ReplicaSet-styrenheten i styrenhetshanteraren, som hanterar skapande, modifiering och radering av ReplicaSet-resurser:
ReplicaSet-styrenheten skapar en poddefinition för varje ReplicaSet-replika (enligt podmallen i ReplicaSet-definitionen) och lagrar dem i lagring:
Schemaläggaren startas och spårar pods som ännu inte har tilldelats några arbetarnoder:
Schemaläggaren väljer en lämplig arbetarnod för varje pod och lägger till denna information till poddefinitionen i butiken:
På arbetarnoden som podden är tilldelad till, startas Kubelet, den spårar podarna som tilldelats denna nod:
Kubelet läser poddefinitionen från lagringen och instruerar en containerkörning, som Docker, att starta containrar på noden:

Nedan finns en textversion av denna beskrivning.

API-begäran till slutpunkten för att skapa ReplicaSet bearbetas av API-servern. API-servern autentiserar begäran och lagrar ReplicaSet-resursdefinitionen i lagring.

Denna händelse startar ReplicaSet-styrenheten, som är en underprocess till styrenhetshanteraren. ReplicaSet-styrenheten övervakar skapandet, uppdateringen och raderingen av ReplicaSet-resurser i butiken och får ett händelsemeddelande när detta inträffar.

ReplicaSet-styrenhetens uppgift är att säkerställa att det erforderliga antalet ReplicaSet-pods finns. I vårt exempel finns inga poddar ännu, så ReplicaSet-kontrollern skapar dessa poddefinitioner (enligt podmallen i ReplicaSet-definitionen) och lagrar dem i lagring.

Skapandet av nya pods utlöses av en schemaläggare som håller reda på poddefinitioner som ännu inte är schemalagda för arbetarnoder. Schemaläggaren väljer en lämplig arbetarnod för varje pod och uppdaterar poddefinitionerna i förvaret.

Observera att fram till denna tidpunkt kördes ingen arbetsbelastningskod någonstans i klustret. Allt som har gjorts hittills - detta är skapandet och uppdateringen av resurser i arkivet på masternoden.

Den sista händelsen utlöser Kubelets, som övervakar poddarna som är schemalagda för deras arbetarnoder. Kubelet för arbetarnoden där dina ReplicaSet-pods är installerade måste instruera containerruntime, som Docker, att ladda ner de nödvändiga containerbilderna och köra dem.

Vid det här laget kör äntligen din ReplicaSet-applikation!

Rollen för Kubernetes API

Som du såg i föregående exempel, tittar Kubernetes-komponenter (förutom API-servern och lagringen) efter ändringar av resurser i lagring och ändrar information om resurser i lagring.

Naturligtvis interagerar dessa komponenter inte med lagringen direkt, utan endast genom Kubernetes API.

Betrakta följande exempel:

ReplicaSet-kontrollern använder API-slutpunkten lista ReplicaSets med parameter watch för att övervaka ändringar av ReplicaSet-resurser.
ReplicaSet-kontrollern använder API-slutpunkten skapa Pod (skapa pod) för att skapa poddar.
Schemaläggaren använder API-slutpunkt patch pod (redigera pod) för att uppdatera poddar med information om den valda arbetarnoden.

Som du kan se är detta samma API som kubectl kommer åt. Att använda samma API för interna komponenter och externa användare är ett grundläggande koncept i Kubernetes design.

Nu kan vi sammanfatta hur Kubernetes fungerar:

Lagringsbutikerna anger, det vill säga Kubernetes-resurser.
API-servern tillhandahåller ett gränssnitt till lagringen i form av Kubernetes API.
Alla andra Kubernetes-komponenter och användare läser, observerar och manipulerar Kubernetes-tillstånd (resurser) via API:et.

Att känna till dessa begrepp hjälper dig att förstå kubectl bättre och få ut det mesta av det.

Låt oss nu titta på några specifika tips och tricks som hjälper dig att förbättra din produktivitet med kubectl.

1. Snabba upp inmatningen genom att använda kommando

En av de mest användbara, men ofta förbisedda, teknikerna för att förbättra prestandan med kubectl är kommandokomplettering.

Genom att utföra kommandon kan delar av kubectl-kommandon slutföras automatiskt med hjälp av Tab-tangenten. Detta fungerar för underkommandon, alternativ och argument, inklusive något så komplext som resursnamn.

Se hur kubectl-kommandot fungerar:

Kommandoslutförande fungerar för Bash- och Zsh-skal.

Officiell guide innehåller detaljerade instruktioner för att ställa in autoslutförande, men nedan kommer vi att ge ett kort utdrag.

Hur kommandoslutförande fungerar

Kommandokomplettering är en skalfunktion som fungerar med ett kompletteringsskript. Ett tilläggsskript är ett skalskript som definierar beteendet för ett tillägg för ett specifikt kommando.

Kubectl genererar och matar automatiskt ut tilläggsskript för Bash och Zsh med hjälp av följande kommandon:

$ kubectl completion bash

Или:

$ kubectl completion zsh

I teorin räcker det att ansluta utdata från dessa kommandon till lämpligt kommandoskal så att kubectl kan komplettera kommandona.

I praktiken är anslutningsmetoden annorlunda för Bash (inklusive skillnader mellan Linux och MacOS) och Zsh. Nedan kommer vi att titta på alla dessa alternativ.

Bash på Linux

Bash-kompletteringsskriptet beror på bash-completion-paketet, så du måste installera det först:

$ sudo apt-get install bash-completion

Или:

$ yum install bash-completion

Du kan testa att paketet har installerats framgångsrikt med följande kommando:

$ type _init_completion

Om detta matar ut skalfunktionskod är bash-completion korrekt installerat. Om kommandot ger ett felmeddelande om att det inte hittades, måste du lägga till följande rad i filen ~ / .bashrc:

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

Är det nödvändigt att lägga till denna rad i filen ~ / .bashrc eller inte beror på pakethanteraren du använde för att installera bash-completion. Detta är nödvändigt för APT, men inte för YUM.

Efter installation av bash-completion måste du konfigurera allt så att kubectl-kompletteringsskriptet är aktiverat i alla skalsessioner.

Ett sätt att göra detta är att lägga till följande rad i filen ~ / .bashrc:

source <(kubectl completion bash)

Ett annat sätt är att lägga till tilläggsskriptet kubectl till katalogen /etc/bash_completion.d (skapa den om den inte finns):

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

Alla tilläggsskript i katalogen /etc/bash_completion.d ingår automatiskt i bash-komplettering.

Båda alternativen är lika tillämpliga.

Efter att ha startat om skalet kommer kubectl-kommandot att fungera.

Bash på MacOS

På MacOS är installationen lite mer komplicerad. Faktum är att MacOS som standard använder Bash version 3.2, och kubectl autokompletteringsskriptet kräver en Bash-version på minst 4.1 och fungerar inte i Bash 3.2.

Det finns licensproblem förknippade med att använda en föråldrad version av Bash på MacOS. Bash version 4 är licensierad under GPLv3, som inte stöds av Apple.

För att konfigurera kubectl autokomplettering på MacOS måste du installera en nyare version av Bash. Du kan också ställa in den uppdaterade Bash som ditt standardskal, vilket kommer att spara dig många problem i framtiden. Det är inte svårt, detaljer ges i artikeln "Uppdaterar Bash på MacOS".

Innan du fortsätter, se till att du använder en senaste version av Bash (kontrollera utdata bash --version).

Bash-kompletteringsskriptet varierar beroende på projekt bash-avslutande, så du måste installera den först.

Du kan installera bash-completion med Homebrew:

$ brew install bash-completion@2

Här @2 står för bash-completion version 2. kubectl autocompletion kräver bash-completion v2, och bash-completion v2 kräver minst Bash version 4.1.

Kommandoutgång brew-install innehåller en varningssektion, som anger vad som behöver läggas till 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"

Jag rekommenderar dock att du inte lägger till dessa rader ~/.bash_profile, och i ~/.bashrc. I det här fallet kommer autokomplettering att vara tillgänglig inte bara i huvudet utan också i underordnade kommandoskal.

Efter att ha startat om kommandoskalet kan du verifiera att installationen är korrekt med följande kommando:

$ type _init_completion

Om du ser en skalfunktion i utgången är allt konfigurerat korrekt.

Nu måste vi se till att kubectl autokomplettering är aktiverat i alla sessioner.

Ett sätt är att lägga till följande rad i din ~/.bashrc:

source <(kubectl completion bash)

Det andra sättet är att lägga till ett autoslutförandeskript till mappen /usr/local/etc/bash_completion.d:

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

Den här metoden fungerar bara om du installerade bash-completion med Homebrew. I det här fallet laddar bash-completion alla skript från den här katalogen.

Om du har installerat kubectl med Homebrew, då behöver du inte utföra föregående steg, eftersom autokompletteringsskriptet automatiskt placeras i mappen /usr/local/etc/bash_completion.d under installationen. I det här fallet kommer kubectl autocompletion att börja fungera så snart du installerar bash-completion.

Som ett resultat är alla dessa alternativ likvärdiga.

zsh

Autokompletterande skript för Zsh kräver inga beroenden. Allt du behöver göra är att aktivera dem när du laddar kommandoskalet.

Du kan göra detta genom att lägga till en rad i din ~/.zshrc fil:

source <(kubectl completion zsh)

Om du får ett felmeddelande not found: compdef efter att du har startat om ditt skal måste du aktivera den inbyggda funktionen compdef. Du kan aktivera det genom att lägga till det i början av filen ~/.zshrc följande:

autoload -Uz compinit
compinit

2. Visa snabbt resursspecifikationer

När du skapar YAML-resursdefinitioner måste du känna till fälten och deras betydelse för dessa resurser. Ett ställe att leta efter denna information är i API-referensen, som innehåller fullständiga specifikationer för alla resurser.

Det är dock obekvämt att byta till webbläsaren varje gång du behöver söka efter något. Därför tillhandahåller kubectl kommandot kubectl explain, som visar specifikationerna för alla resurser direkt i din terminal.

Kommandoformatet är som följer:

$ kubectl explain resource[.field]...

Kommandot matar ut specifikationen för den begärda resursen eller fältet. Informationen som visas är identisk med den som finns i API-manualen.

Som standard kubectl explain visar endast den första nivån av häckning av fält.

Se hur det ser ut Du kan sedan.

Du kan visa hela trädet om du lägger till alternativet --recursive:

$ kubectl explain deployment.spec --recursive

Om du inte vet exakt vilka resurser som behövs kan du visa dem alla med följande kommando:

$ kubectl api-resources

Detta kommando visar resursnamn i pluralform, t.ex. deployments istället för deployment. Den visar också det korta namnet, till exempel deploy, för de resurser som har det. Oroa dig inte för dessa skillnader. Alla dessa namnalternativ är likvärdiga för kubectl. Det vill säga, du kan använda vilken som helst av dem för kubectl explain.

Alla följande kommandon är likvärdiga:

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

3. Använd ett anpassat kolumnutdataformat

Standardutmatningsformat för kommandon 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

Det här formatet är bekvämt, men det innehåller en begränsad mängd information. Jämfört med formatet för fullständig resursdefinition visas bara ett fåtal fält här.

I det här fallet kan du använda ett anpassat kolumnutdataformat. Det låter dig bestämma vilken data som ska matas ut. Du kan visa vilket resursfält som helst som en separat kolumn.

Användningen av ett anpassat format bestäms med hjälp av alternativen:

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

Du kan definiera varje utdatakolumn som ett par <header>:<jsonpath>var <header> är kolumnnamnet och <jsonpath> — ett uttryck som definierar ett resursfält.

Låt oss titta på ett enkelt exempel:

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

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

Utdatan innehåller en kolumn med namnen på poddarna.

Alternativuttrycket väljer podnamnen från fältet metadata.name. Detta beror på att poddens namn är definierat i fältet för barnnamn metadata i poddens resursbeskrivning. Mer information finns i API-guide eller skriv kommandot kubectl explain pod.metadata.name.

Låt oss nu säga att du vill lägga till en extra kolumn till utdata, till exempel att visa noden varje pod körs på. För att göra detta kan du helt enkelt lägga till lämplig kolumnspecifikation till alternativet för anpassade kolumner:

$ 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

Uttrycket väljer nodnamnet från spec.nodeName — när en pod tilldelas en nod, skrivs dess namn i fältet spec.nodeName pod resursspecifikation. Mer detaljerad information finns i utgången kubectl explain pod.spec.nodeName.

Observera att Kubernetes resursfält är skiftlägeskänsliga.

Du kan visa vilket resursfält som helst som en kolumn. Granska bara resursspecifikationen och prova den med alla fält du vill.

Men låt oss först titta närmare på fältvalsuttryck.

JSONPath-uttryck

Uttryck för val av resursfält baseras på JSONPath.

JSONPath är ett språk för att hämta data från JSON-dokument. Att välja ett enskilt fält är det enklaste användningsfallet för JSONPath. Han har mycket större röst, inklusive väljare, filter och så vidare.

Kubectl explain stöder ett begränsat antal JSONPath-funktioner. Möjligheterna och exemplen på deras användning beskrivs nedan:

# Выбрать все элементы списка
$ 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 [] är särskilt viktig. Många Kubernetes-resursfält är listor, och den här operatören låter dig välja medlemmar i dessa listor. Det används ofta med ett jokertecken som [*] för att välja alla element i en lista.

Applikationsexempel

Möjligheterna att använda ett anpassat kolumnutdataformat är oändliga, eftersom du kan visa vilket fält eller kombination av resursfält som helst i utdata. Här är några exempel på appar, men utforska dem gärna själv och hitta applikationer som fungerar för dig.

Visar behållarbilder för poddar:

$ 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

Detta kommando visar behållarbildnamnen för varje pod.

Kom ihåg att en pod kan innehålla flera behållare, då kommer bildnamnen att visas på en rad, separerade med kommatecken.

Visar nodtillgänglighetszoner:
```
$ 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
```
Det här kommandot är användbart om ditt kluster finns i ett offentligt moln. Den visar tillgänglighetszonen för varje nod.

Tillgänglighetszon är ett molnkoncept som begränsar replikeringszonen till en geografisk region.

Tillgänglighetszoner för varje nod erhålls genom en speciell etikett - failure-domain.beta.kubernetes.io/zone. Om klustret körs i ett offentligt moln skapas denna etikett automatiskt och fylls med namnen på tillgänglighetszonerna för varje nod.

Etiketter är inte en del av Kubernetes resursspecifikation, så du hittar inte information om dem i API-guide. De kan dock ses (som alla andra etiketter) om du begär information om noderna i YAML- eller JSON-format:
```
$ kubectl get nodes -o yaml
# или
$ kubectl get nodes -o json
```
Det här är ett utmärkt sätt att lära sig mer om resurser, förutom att lära sig resursspecifikationer.

4. Växla enkelt mellan kluster och namnområden

När kubectl gör en begäran till Kubernetes API läser den först kubeconfig-filen för att få alla nödvändiga parametrar för anslutningen.

Som standard är kubeconfig-filen ~/.kube/config. Vanligtvis skapas eller uppdateras den här filen med ett speciellt kommando.

När du arbetar med flera kluster innehåller din kubeconfig-fil inställningar för att ansluta till alla dessa kluster. Du behöver ett sätt att berätta för kommandot kubectl vilket kluster du arbetar med.

Inom ett kluster kan du skapa flera namnområden – en typ av virtuellt kluster inom ett fysiskt kluster. Kubectl bestämmer också vilket namnområde som ska användas baserat på kubeconfig-filen. Det betyder att du också behöver ett sätt att tala om för kommandot kubectl vilket namnområde som ska arbeta med.

I det här kapitlet kommer vi att förklara hur det fungerar och hur man får det att fungera effektivt.

Observera att du kan ha flera kubeconfig-filer listade i miljövariabeln KUBECONFIG. I det här fallet kommer alla dessa filer att kombineras till en gemensam konfiguration vid körning. Du kan också ändra standardfilen för kubeconfig genom att köra kubectl med parametern --kubeconfig. Se officiell dokumentation.

kubeconfig-filer

Låt oss se exakt vad kubeconfig-filen innehåller:

Som du kan se innehåller kubeconfig-filen en uppsättning sammanhang. Kontext består av tre element:

Kluster — API-URL för klusterservern.
Användare – användarautentiseringsuppgifter i klustret.
Namnutrymme - namnområdet som används när du går med i klustret.

I praktiken använder de ofta ett sammanhang per kluster i sin kubeconfig. Du kan dock ha flera sammanhang per kluster, differentierade efter användare eller namnutrymme. Denna multikontextkonfiguration är dock ovanlig, så det finns vanligtvis en en-till-en-mappning mellan kluster och sammanhang.

Vid varje given tidpunkt är ett av sammanhangen aktuellt:

När kubectl läser en konfigurationsfil tar den alltid information från det aktuella sammanhanget. I exemplet ovan kommer kubectl att ansluta till Hare-klustret.

Följaktligen, för att byta till ett annat kluster, måste du ändra det aktuella sammanhanget i kubeconfig-filen:

Nu kommer kubectl att ansluta till Fox-klustret.

För att byta till ett annat namnområde i samma kluster måste du ändra värdet på namnområdeselementet för den aktuella kontexten:

I exemplet ovan kommer kubectl att använda Fox-klustrets Prod-namnområde (tidigare angavs testnamnområdet).

Observera att kubectl också tillhandahåller alternativ --cluster, --user, --namespace и --context, som låter dig skriva över enskilda element och själva den aktuella kontexten, oavsett vad som är inställt i kubeconfig. Se kubectl options.

I teorin kan du ändra inställningarna manuellt i kubeconfig. Men det är obekvämt. För att förenkla dessa operationer finns det olika verktyg som låter dig ändra parametrar automatiskt.

Använd kubectx

Ett mycket populärt verktyg för att växla mellan kluster och namnområden.

Verktyget tillhandahåller kommandon kubectx и kubens för att ändra aktuell kontext respektive namnutrymme.

Som nämnts innebär att ändra det aktuella sammanhanget att ändra klustret om du bara har ett sammanhang per kluster.

Här är ett exempel på hur du kör dessa kommandon:

Dessa kommandon redigerar i huvudsak kubeconfig-filen enligt beskrivningen ovan.

att installera kubectx, följ instruktionerna på Github.

Båda kommandona stöder autokomplettering av kontext- och namnutrymmesnamn, vilket eliminerar behovet av att skriva in dem helt. Instruktioner för att ställa in autokomplettering här.

En annan användbar funktion kubectx är interaktivt läge. Det fungerar tillsammans med verktyget fzf, som måste installeras separat. Genom att installera fzf blir interaktivt läge automatiskt tillgängligt i kubectx. Interaktivt kan du välja kontext och namnutrymme genom det interaktiva fria sökgränssnittet från fzf.

Använda skalalias

Du behöver inga separata verktyg för att ändra aktuell kontext och namnutrymme eftersom kubectl också tillhandahåller kommandon för detta. Ja, laget kubectl config tillhandahåller underkommandon för redigering av kubeconfig-filer.

Вот некоторые из них:

kubectl config get-contexts: visa alla sammanhang;
kubectl config current-context: få aktuell kontext;
kubectl config use-context: ändra aktuellt sammanhang;
kubectl config set-context: Ändra kontextelementet.

Men att använda dessa kommandon direkt är inte särskilt bekvämt eftersom de är långa. Du kan göra skalalias för dem som är lätta att utföra.

Jag skapade en uppsättning alias baserat på dessa kommandon som ger funktionalitet som liknar kubectx. Här kan du se dem i aktion:

Observera att alias använder fzf för att tillhandahålla ett interaktivt gratis uppslagsgränssnitt (som kubectx interaktiva läge). Det betyder att du behöver installera fzfatt använda dessa alias.

Här är definitionerna av själva alias:

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

För att ställa in dessa alias måste du lägga till ovanstående definitioner till din fil ~/.bashrc eller ~/.zshrc och starta om ditt skal.

Använder plugins

Kubectl låter dig ladda insticksprogram som körs på samma sätt som grundläggande kommandon. Du kan till exempel installera insticksprogrammet kubectl-foo och köra det genom att köra kommandot kubectl foo.

Det skulle vara bekvämt att ändra kontext och namnutrymme på detta sätt, till exempel genom att köra kubectl ctx att ändra sammanhang och kubectl ns för att ändra namnutrymmet.

Jag har skrivit två plugins som gör detta:

Arbetet med plugins är baserat på alias från föregående avsnitt.

Så här fungerar de:

Observera att plugins använder fzf för att tillhandahålla ett interaktivt gratis sökgränssnitt (som kubectx interaktiva läge). Det betyder att du behöver installera fzfatt använda dessa alias.

För att installera plugins måste du ladda ner skalskript med namnet kubectl-ctx и kubectl-ns till valfri katalog i din PATH-variabel och gör dem körbara med t.ex. chmod +x. Omedelbart efter detta kommer du att kunna använda kubectl ctx и kubectl ns.

5. Minska indata med autoalias

Skalalias är ett bra sätt att snabba upp inmatningen. Projekt kubectl-alias innehåller cirka 800 genvägar för grundläggande kubectl-kommandon.

Du kanske undrar - hur minns du 800 alias? Men du behöver inte komma ihåg dem alla, eftersom de är byggda enligt ett enkelt schema, som ges nedan:

Till exempel:

kgpooyaml - kubectl get pods oyaml
ksysgsvcw — kubectl -n kube-system få svc w
ksysrmcm -kubectl -n kube-system rm cm
kgdepallsl - kubectl hämta distribution alla sl

Som du kan se består alias av komponenter, som var och en representerar ett specifikt element i kommandot kubectl. Varje alias kan ha en komponent för baskommandot, operationen och resursen, och flera komponenter för parametrar. Du "befolkar" helt enkelt dessa komponenter från vänster till höger enligt diagrammet ovan.

Det aktuella detaljerade diagrammet är kl GitHub. Där kan du också hitta fullständig lista över alias.

Till exempel är aliaset kgpooyamlall ekvivalent med kommandot kubectl get pods -o yaml --all-namespaces.

Den relativa ordningen för alternativen är inte viktig: kommando kgpooyamlall motsvarar kommandot kgpoalloyaml.

Du behöver inte använda alla komponenter som alias. Till exempel k, kg, klo, ksys, kgpo kan också användas. Dessutom kan du kombinera alias och vanliga kommandon eller alternativ på kommandoraden:

Till exempel:

I stället för kubectl proxy du kan skriva k proxy.
I stället för kubectl get roles du kan skriva kg roles (det finns för närvarande inget alias för rollresursen).
För att få data för en specifik pod kan du använda kommandot kgpo my-pod — kubectl get pod my-pod.

Observera att vissa alias kräver ett kommandoradsargument. Till exempel alias kgpol innebär kubectl get pods -l. Alternativ -l kräver ett argument - en etikettspecifikation. Om du använder ett alias kommer det att se ut kgpol app=ui.

Eftersom vissa alias kräver argument måste aliasen a, f och l användas sist.

I allmänhet, när du väl har fått kläm på detta schema, kan du intuitivt härleda alias från de kommandon du vill köra och spara mycket skrivtid.

installation

För att installera kubectl-alias måste du ladda ner filen .kubectl_aliases från GitHub och inkludera den i filen ~/.bashrc eller ~/.zshrc:

source ~/.kubectl_aliases

Autoslutförande

Som vi sa tidigare lägger du ofta till ytterligare ord till ett alias på kommandoraden. Till exempel:

$ kgpooyaml test-pod-d4b77b989

Om du använder kubectl-kommandokomplettering har du förmodligen använt autokomplettering för saker som resursnamn. Men kan detta göras när alias används?

Det här är en mycket viktig fråga för om autokomplettering inte fungerar kommer du att förlora några av fördelarna med alias.

Svaret beror på vilket skal du använder:

För Zsh fungerar komplettering av alias direkt.
För Bash krävs tyvärr en del arbete för att få autokomplettering att fungera.

Aktiverar autokomplettering för alias i Bash

Problemet med Bash är att den försöker slutföra (varje gång du trycker på Tab) aliaset, inte kommandot som aliaset refererar till (som Zsh till exempel gör). Eftersom du inte har kompletteringsskript för alla 800 alias, fungerar inte autokomplettering.

Projekt komplett-alias ger en allmän lösning på detta problem. Den ansluter till aliaskompletteringsmekanismen, expanderar internt aliaset till ett kommando och returnerar kompletteringsalternativ för det slutförda kommandot. Det betyder att utfyllnaden för ett alias beter sig exakt likadant som för ett fullständigt kommando.

I det följande kommer jag först att förklara hur man installerar komplett-alias och sedan hur man konfigurerar det för att möjliggöra komplettering för alla kubectl-alias.

Installerar komplett-alias

Först och främst beror komplett-alias på bash-avslutande. Innan du installerar complete-alias måste du därför se till att bash-completion är installerat. Installationsinstruktioner har tillhandahållits tidigare för Linux och MacOS.

Viktig anmärkning för MacOS-användare: Precis som kubectl-skriptet för autokomplettering fungerar inte complete-alias med Bash 3.2, som är standard på MacOS. I synnerhet beror komplett-alias på bash-komplettering v2 (brew install bash-completion@2), vilket kräver minst Bash 4.1. Detta innebär att för att använda komplett-alias på MacOS måste du installera en nyare version av Bash.

Du måste ladda ner skriptet bash_completion.sh av GitHub-förråd och inkludera det i din fil ~/.bashrc:

source ~/bash_completion.sh

Efter omstart av skalet kommer complete-alias att vara helt installerat.

Aktiverar autoslutförande för kubectl-alias

Tekniskt komplett-alias ger en omslagsfunktion _complete_alias. Den här funktionen kontrollerar aliaset och returnerar slutföringstips för aliaskommandot.

För att associera en funktion med ett specifikt alias måste du använda den inbyggda Bash-mekanismen fullborda, att installera _complete_alias som en alias kompletteringsfunktion.

Som ett exempel, låt oss ta aliaset k, som står för kommandot kubectl. att installera _complete_alias Som en komplementfunktion för detta alias bör du köra följande kommando:

$ complete -F _complete_alias k

Resultatet av detta är att när du autokompletterar ett alias k anropas funktionen _complete_alias, som kontrollerar aliaset och returnerar slutföringstips för kommandot kubectl.

Som ett andra exempel, låt oss ta aliaset kg, vilket betecknar kubectl get:

$ complete -F _complete_alias kg

Precis som i föregående exempel, när du autokompletterar kg, får du samma slutförandetips som du skulle få för kubectl get.

Observera att du kan använda komplett-alias för alla alias på ditt system.

Därför, för att aktivera autokomplettering för alla kubectl-alias, måste du köra kommandot ovan för vart och ett av dem. Följande kodavsnitt gör exakt detta, förutsatt att du har ställt in kubectl-alias till ~/.kubectl-aliases:

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

Denna kodbit måste placeras i din ~/.bashrc, starta om kommandoskalet och autokomplettering blir tillgängligt för alla 800 kubectl-alias.

6. Utöka kubectl med plugins

Från och med version 1.12, stöder kubectl plugin-mekanism, som låter dig utöka dess funktioner med ytterligare kommandon.

Om du är bekant med Git plugin-mekanismer, då är kubectl-plugins byggda på samma princip.

I det här kapitlet kommer vi att täcka hur du installerar plugins, var du hittar dem och hur du skapar dina egna plugins.

Installerar plugins

Kubectl-plugins distribueras som enkla körbara filer med namnet som kubectl-x. Prefix kubectl- krävs, följt av ett nytt kubectl-underkommando som låter dig anropa plugin-programmet.

Till exempel kommer hello-pluginet att distribueras som en fil som heter kubectl-hello.

För att installera plugin-programmet måste du kopiera filen kubectl-x till valfri katalog i din PATH och gör den körbar, till exempel med chmod +x. Direkt efter detta kan du ringa plugin med kubectl x.

Du kan använda följande kommando för att lista alla plugins som för närvarande är installerade på ditt system:

$ kubectl plugin list

Detta kommando kommer också att visa varningar om du har flera plugins med samma namn, eller om det finns en plugin-fil som inte är körbar.

Hitta och installera plugins med Krew

Kubectl-plugins kan delas eller återanvändas som mjukvarupaket. Men var kan du hitta plugins som andra har delat?

Projekt Krew syftar till att tillhandahålla en enhetlig lösning för att dela, söka, installera och hantera kubectl-plugins. Projektet kallar sig en "pakethanterare för kubectl-plugins" (Krew liknar Brygga).

Krew är en lista över kubectl-plugin-program som du kan välja och installera. Samtidigt är Krew också ett plugin för kubectl.

Detta betyder att installation av Krew fungerar i princip som att installera alla andra kubectl-plugin. Du hittar detaljerade instruktioner på sida GitHub.

De viktigaste Krew-kommandona är:

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

Observera att installation av plugins med Krew inte stör installationen av plugins med standardmetoden som beskrivs ovan.

Observera att kommandot kubectl krew list visar bara plugins som installerades med Krew, medan kommandot kubectl plugin list listar alla plugins, det vill säga de som installerats med Krew och de som installerats med andra metoder.

Hitta plugins någon annanstans

Krew är ett ungt projekt, för närvarande på gång listan endast cirka 30 plugins. Om du inte hittar det du behöver kan du hitta plugins någon annanstans, som GitHub.

Jag rekommenderar att du tittar på GitHub-sektionen kubectl-plugins. Där hittar du dussintals tillgängliga plugins som är värda att kolla in.

Att skriva dina egna plugins

du kan själv skapa plugins – Det är inte svårt. Du måste skapa en körbar fil som gör vad du behöver, namnge den som kubectl-x och installera enligt beskrivningen ovan.

Filen kan vara ett bash-skript, ett python-skript eller en kompilerad GO-applikation - det spelar ingen roll. Det enda villkoret är att det kan köras direkt i operativsystemet.

Låt oss skapa ett exempel på plugin just nu. I föregående avsnitt använde du kommandot kubectl för att lista behållarna för varje pod. Det är enkelt att göra om detta kommando till ett plugin som du kan anropa med t.ex. kubectl img.

Skapa en fil kubectl-img följande innehåll:

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

Gör nu filen körbar med chmod +x kubectl-img och flytta den till valfri katalog i din PATH. Direkt efter detta kan du använda plugin kubectl img.

Som nämnts kan kubectl-plugins skrivas i vilket programmerings- eller skriptspråk som helst. Om du använder skalskript är fördelen med att enkelt kunna anropa kubectl från plugin-programmet. Du kan dock skriva mer komplexa plugins i riktiga programmeringsspråk med hjälp av Kubernetes klientbibliotek. Om du använder Go kan du också använda cli-runtime-bibliotek, som finns specifikt för att skriva kubectl-plugin-program.

Hur du delar dina plugins

Om du tror att dina plugins kan vara användbara för andra, dela dem gärna på GitHub. Var noga med att lägga till dem i ämnet kubectl-plugins.

Du kan också begära att din plugin läggs till Krew lista. Instruktioner om hur du gör detta finns i GitHub-förråd.

Kommandot slutförts

Plugins stöder för närvarande inte autokomplettering. Det vill säga att du måste ange pluginens fullständiga namn och argumentens fullständiga namn.

GitHub kubectl-förvaret för denna funktion har öppen begäran. Så det är möjligt att den här funktionen kommer att implementeras någon gång i framtiden.

Lycka till!!!

Vad mer att läsa om ämnet:

Källa: will.com

Hur man använder kubectl mer effektivt: en detaljerad guide