🥇Hoe om kubectl meer effektief te gebruik: 'n gedetailleerde gids

As jy met Kubernetes werk, dan is kubectl waarskynlik een van die nutsprogramme wat jy die meeste gebruik. En wanneer jy ook al baie tyd spandeer om met 'n spesifieke instrument te werk, is dit die moeite werd om dit goed te bestudeer en te leer hoe om dit doeltreffend te gebruik.

Span Kubernetes aaS van Mail.ru het 'n artikel deur Daniel Weibel vertaal waarin jy wenke en truuks sal vind om effektief met kubectl te werk. Dit sal jou ook help om 'n dieper begrip van Kubernetes te kry.

Volgens die skrywer is die doel van die artikel om jou daaglikse werk met Kubernetes nie net doeltreffender te maak nie, maar ook lekkerder!

Inleiding: Wat is kubectl

Voordat jy kan leer om kubectl meer effektief te gebruik, moet jy 'n basiese begrip kry van wat dit is en hoe dit werk.

Vanuit 'n gebruiker se perspektief is kubectl 'n beheerpaneel wat jou toelaat om Kubernetes-bewerkings uit te voer.

Tegnies gesproke is kubectl 'n Kubernetes API-kliënt.

Kubernetes API is 'n HTTP REST API. Hierdie API is die ware Kubernetes-gebruikerskoppelvlak, waardeur dit heeltemal beheer word. Dit beteken dat elke Kubernetes-bewerking as 'n API-eindpunt blootgestel word en met 'n HTTP-versoek na daardie eindpunt gemaak kan word.

Daarom is die hooftaak van kubectl om HTTP-versoeke aan die Kubernetes API te rig:

Kubernetes is 'n heeltemal hulpbron-georiënteerde stelsel. Dit beteken dat dit die interne toestand van hulpbronne handhaaf en dat alle Kubernetes-bedrywighede CRUD-bedrywighede is.

Jy is in volle beheer van Kubernetes deur hierdie hulpbronne te bestuur, en Kubernetes vind uit wat om te doen op grond van die huidige stand van die hulpbronne. Om hierdie rede is die Kubernetes API-verwysing georganiseer as 'n lys van hulpbrontipes met hul gepaardgaande bedrywighede.

Kom ons kyk na 'n voorbeeld.

Kom ons sê jy wil 'n ReplicaSet-hulpbron skep. Om dit te doen, beskryf jy die ReplicaSet in 'n lêer by die naam replicaset.yaml, voer dan die opdrag uit:

$ kubectl create -f replicaset.yaml

Dit sal 'n ReplicaSet-hulpbron skep. Maar wat gebeur agter die skerms?

Kubernetes het 'n ReplicaSet-skeppingsbewerking. Soos enige ander operasie, word dit as 'n API-eindpunt blootgestel. Die spesifieke API eindpunt vir hierdie operasie lyk soos volg:

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

API-eindpunte vir alle Kubernetes-bedrywighede kan gevind word by API verwysing (insluitend bogenoemde eindpunt). Om 'n werklike versoek na 'n eindpunt te rig, moet jy eers die API-bediener-URL by die eindpuntpaaie wat in die API-verwysing gelys word, byvoeg.

Dus, wanneer u die bogenoemde opdrag uitvoer, stuur kubectl 'n HTTP POST-versoek na die bogenoemde API-eindpunt. Die ReplicaSet-definisie wat jy in die lêer verskaf het replicaset.yaml, word in die liggaam van die versoek gestuur.

Dit is hoe kubectl werk vir alle opdragte wat interaksie het met die Kubernetes-groepering. In al hierdie gevalle rig kubectl eenvoudig HTTP-versoeke na die toepaslike Kubernetes API-eindpunte.

Neem asseblief kennis dat jy Kubernetes volledig kan bestuur deur 'n nutsprogram soos curldeur HTTP-versoeke handmatig na die Kubernetes API te stuur. Kubectl maak dit eenvoudig makliker om die Kubernetes API te gebruik.

Dit is die basiese beginsels van wat kubectl is en hoe dit werk. Maar daar is iets anders oor die Kubernetes API wat elke kubectl-gebruiker moet weet. Kom ons kyk vinnig na die innerlike wêreld van Kubernetes.

Die innerlike wêreld van Kubernetes

Kubernetes bestaan uit 'n stel onafhanklike komponente wat as afsonderlike prosesse op cluster nodusse loop. Sommige komponente loop op meester nodusse, ander op werker nodusse, elke komponent verrig sy eie spesifieke taak.

Hier is die belangrikste komponente op die hoof nodusse:

repository - stoor hulpbrondefinisies (gewoonlik is dit ens).
API-bediener - bied 'n API en bestuur berging.
Beheerder Bestuurder — Verseker dat hulpbronstatusse aan spesifikasies voldoen.
Skeduleerder - skeduleer peule op werker nodusse.

En hier is een belangrikste komponent op die werker nodusse:

kubelet - bestuur die bekendstelling van houers op die werkende nodus.

Om te verstaan hoe hierdie komponente saamwerk, kom ons kyk na 'n voorbeeld.

Kom ons neem aan jy het pas voltooi kubectl create -f replicaset.yaml, waarna kubectl 'n HTTP POST-versoek aan ReplicaSet API eindpunt (deur die ReplicaSet-hulpbrondefinisie).

Wat gaan in die groep aan?

Na doen kubectl create -f replicaset.yaml Die API-bediener stoor jou ReplicaSet-hulpbrondefinisie in berging:
Vervolgens word die ReplicaSet-beheerder in die beheerderbestuurder bekendgestel, wat die skepping, wysiging en verwydering van ReplicaSet-hulpbronne hanteer:
Die ReplicaSet-beheerder skep 'n peuldefinisie vir elke ReplicaSet-replika (volgens die peulsjabloon in die ReplicaSet-definisie) en stoor dit in die stoor:
Die skeduleerder word geloods en volg peule op wat nog nie aan enige werkernodusse toegewys is nie:
Die skeduleerder kies 'n geskikte werkernodus vir elke peul en voeg hierdie inligting by die peuldefinisie in die winkel:
Op die werkernodus waaraan die peul toegewys is, word Kubelet geloods, dit volg die peule wat aan hierdie nodus toegewys is:
Die Kubelet lees die peuldefinisie vanaf berging en gee 'n houerlooptyd, soos Docker, opdrag om houers op die nodus te begin:

Hieronder is 'n teksweergawe van hierdie beskrywing.

Die API-versoek na die ReplicaSet-skeppingseindpunt word deur die API-bediener verwerk. Die API-bediener staaf die versoek en stoor die ReplicaSet-hulpbrondefinisie in berging.

Hierdie gebeurtenis begin die ReplicaSet-beheerder, wat 'n subproses van die beheerderbestuurder is. Die ReplicaSet-beheerder monitor die skepping, opdatering en verwydering van ReplicaSet-hulpbronne in die winkel en ontvang 'n gebeurteniskennisgewing wanneer dit gebeur.

Die ReplicaSet-beheerder se taak is om te verseker dat die vereiste aantal ReplicaSet-peule bestaan. In ons voorbeeld bestaan daar nog geen peule nie, so die ReplicaSet-beheerder skep hierdie peuldefinisies (volgens die peulsjabloon in die ReplicaSet-definisie) en stoor dit in die stoor.

Die skepping van nuwe peule word veroorsaak deur 'n skeduleerder wat tred hou met peuldefinisies wat nog nie vir werkernodusse geskeduleer is nie. Die skeduleerder kies 'n geskikte werkernodus vir elke peul en werk die peuldefinisies in die bewaarplek op.

Let daarop dat tot op hierdie stadium geen werkladingskode op enige plek in die groepering geloop het nie. Alles wat tot dusver gedoen is - dit is die skepping en opdatering van hulpbronne in die bewaarplek op die hoofnodus.

Die laaste gebeurtenis veroorsaak Kubelets, wat die peule monitor wat vir hul werkersnodes geskeduleer is. Die Kubelet van die werkernodus waarop jou ReplicaSet-peule geïnstalleer is, moet die houerlooptyd, soos Docker, opdrag gee om die vereiste houerprente af te laai en dit uit te voer.

Op hierdie stadium loop jou ReplicaSet-toepassing uiteindelik!

Rol van die Kubernetes API

Soos u in die vorige voorbeeld gesien het, kyk Kubernetes-komponente (behalwe vir die API-bediener en berging) vir veranderinge aan hulpbronne in berging en verander inligting oor hulpbronne in berging.

Natuurlik werk hierdie komponente nie direk met die berging nie, maar slegs deur die Kubernetes API.

Beskou die volgende voorbeelde:

Die ReplicaSet-beheerder gebruik die API-eindpunt lys ReplicaSets met parameter watch om veranderinge aan ReplicaSet-hulpbronne te monitor.
Die ReplicaSet-beheerder gebruik die API-eindpunt skep Pod (create pod) to create peule.
Skeduleerder gebruik API eindpunt lap pod (wysig peul) om peule op te dateer met inligting oor die geselekteerde werkernodus.

Soos u kan sien, is dit dieselfde API waartoe kubectl toegang het. Die gebruik van dieselfde API vir interne komponente en eksterne gebruikers is 'n fundamentele konsep in Kubernetes-ontwerp.

Nou kan ons opsom hoe Kubernetes werk:

Die stoorwinkels verklaar, dit wil sê Kubernetes-hulpbronne.
Die API-bediener bied 'n koppelvlak aan die berging in die vorm van die Kubernetes API.
Alle ander Kubernetes-komponente en gebruikers lees, neem waar en manipuleer Kubernetes-toestand (hulpbronne) deur die API.

Om hierdie konsepte te ken, sal jou help om kubectl beter te verstaan en die meeste daaruit te kry.

Kom ons kyk nou na 'n paar spesifieke wenke en truuks wat sal help om jou produktiwiteit met kubectl te verbeter.

1. Bespoedig invoer deur opdragvoltooiing

Een van die nuttigste, maar dikwels oor die hoof gesien, tegnieke om werkverrigting met kubectl te verbeter, is opdragvoltooiing.

Opdragvoltooiing laat jou toe om dele van kubectl-opdragte outomaties te voltooi deur die Tab-sleutel te gebruik. Dit werk vir subopdragte, opsies en argumente, insluitend iets so kompleks soos hulpbronname.

Kyk hoe kubectl-opdragvoltooiing werk:

Opdragvoltooiing werk vir Bash- en Zsh-skulpe.

Amptelike gids bevat gedetailleerde instruksies vir die opstel van outovoltooiing, maar hieronder sal ons 'n kort uittreksel verskaf.

Hoe opdragvoltooiing werk

Opdragvoltooiing is 'n dopkenmerk wat met 'n voltooiingskrip werk. 'n Uitbreidingskrip is 'n dopskrif wat die gedrag van 'n uitbreiding vir 'n spesifieke opdrag definieer.

Kubectl genereer en voer outomaties uitbreidingsskrifte vir Bash en Zsh uit deur die volgende opdragte te gebruik:

$ kubectl completion bash

Или:

$ kubectl completion zsh

In teorie is dit genoeg om die uitset van hierdie opdragte aan die toepaslike opdragdop te koppel sodat kubectl die opdragte kan aanvul.

In die praktyk is die verbindingsmetode anders vir Bash (insluitend verskille tussen Linux en MacOS) en Zsh. Hieronder sal ons na al hierdie opsies kyk.

Bash op Linux

Die Bash-voltooiingskrip hang af van die bash-voltooiingspakket, so jy moet dit eers installeer:

$ sudo apt-get install bash-completion

Или:

$ yum install bash-completion

U kan toets dat die pakket suksesvol geïnstalleer is deur die volgende opdrag te gebruik:

$ type _init_completion

As dit dopfunksiekode uitstuur, is bash-completion korrek geïnstalleer. As die opdrag 'n "Not Found"-fout gee, moet jy die volgende reël by jou lêer voeg ~ / .bashrc:

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

Is dit nodig om hierdie reël by die lêer te voeg ~ / .bashrc of nie, hang af van die pakketbestuurder wat jy gebruik het om bash-completion te installeer. Dit is nodig vir APT, maar nie vir YUM nie.

Nadat u bash-completion geïnstalleer het, moet u alles opstel sodat die kubectl-voltooiingskrip in alle dopsessies geaktiveer is.

Een manier om dit te doen is om die volgende reël by die lêer te voeg ~ / .bashrc:

source <(kubectl completion bash)

Nog 'n manier is om die kubectl-uitbreidingskrip by die gids te voeg /etc/bash_completion.d (skep dit as dit nie bestaan nie):

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

Alle byvoegingsskrifte in die katalogus /etc/bash_completion.d word outomaties by bash-voltooiing ingesluit.

Beide opsies is ewe toepaslik.

Nadat u die dop herbegin het, sal kubectl-opdragvoltooiing werk.

Bash op MacOS

Op MacOS is die opstelling 'n bietjie meer ingewikkeld. Die feit is dat MacOS standaard Bash weergawe 3.2 gebruik, en die kubectl outovoltooiingskrip vereis 'n Bash-weergawe van ten minste 4.1 en werk nie in Bash 3.2 nie.

Daar is lisensiëringskwessies wat verband hou met die gebruik van 'n verouderde weergawe van Bash op MacOS. Bash weergawe 4 is gelisensieer onder GPLv3, wat nie deur Apple ondersteun word nie.

Om kubectl-outovoltooiing op MacOS op te stel, moet jy 'n meer onlangse weergawe van Bash installeer. Jy kan ook die opgedateerde Bash as jou verstek dop stel, wat jou in die toekoms baie probleme sal spaar. Dit is nie moeilik nie, besonderhede word in die artikel gegee "Dateer Bash op MacOS op".

Voordat u voortgaan, maak seker dat u 'n onlangse weergawe van Bash gebruik (kontroleer die uitvoer bash --version).

Bash-voltooiingsskrif verskil volgens projek bash-voltooiing, so jy moet dit eers installeer.

Jy kan bash-voltooiing installeer met behulp van Homebrew:

$ brew install bash-completion@2

Hier @2 staan vir bash-voltooiing weergawe 2. kubectl outovoltooiing vereis bash-voltooiing v2, en bash-voltooiing v2 vereis 'n minimum van Bash weergawe 4.1.

Beveluitvoer brew-install bevat 'n Caveats-afdeling, wat spesifiseer wat by die lêer gevoeg moet word ~/.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"

Ek beveel egter aan om hierdie reëls nie by te voeg nie ~/.bash_profileen in ~/.bashrc. In hierdie geval sal outovoltooiing nie net in die hoof nie, maar ook in kinderopdragdoppe beskikbaar wees.

Nadat u die opdragdop herbegin het, kan u verifieer dat die installasie korrek is deur die volgende opdrag te gebruik:

$ type _init_completion

As u 'n dopfunksie in die uitvoer sien, is alles korrek gekonfigureer.

Nou moet ons verseker dat kubectl-outovoltooiing in alle sessies geaktiveer is.

Een manier is om die volgende reël by jou ~/.bashrc:

source <(kubectl completion bash)

Die tweede manier is om 'n outovoltooi-skrip by die gids te voeg /usr/local/etc/bash_completion.d:

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

Hierdie metode sal slegs werk as jy bash-voltooiing met Homebrew geïnstalleer het. In hierdie geval laai bash-completion alle skrifte vanaf hierdie gids.

As jy geïnstalleer het kubectl met behulp van Homebrew, dan is dit nie nodig om die vorige stap uit te voer nie, aangesien die outovoltooiingskrip outomaties in die gids geplaas sal word /usr/local/etc/bash_completion.d tydens installasie. In hierdie geval sal kubectl-outovoltooiing begin werk sodra jy bash-voltooiing installeer.

As gevolg hiervan is al hierdie opsies gelykstaande.

Zsj

Outovoltooiingsskrifte vir Zsh vereis geen afhanklikhede nie. Al wat jy hoef te doen is om hulle te aktiveer wanneer jy die opdragdop laai.

Jy kan dit doen deur 'n reël by jou ~/.zshrc lêer:

source <(kubectl completion zsh)

As jy 'n fout ontvang not found: compdef nadat jy jou dop herbegin het, moet jy die ingeboude funksie aktiveer compdef. Jy kan dit aktiveer deur dit by die begin van jou lêer te voeg ~/.zshrc Die volgende:

autoload -Uz compinit
compinit

2. Bekyk hulpbronspesifikasies vinnig

Wanneer jy YAML-hulpbrondefinisies skep, moet jy die velde en hul betekenis vir daardie hulpbronne ken. Een plek om na hierdie inligting te soek, is in die API-verwysing, wat volledige spesifikasies vir alle hulpbronne bevat.

Dit is egter ongerieflik om na die webblaaier oor te skakel elke keer as jy iets moet soek. Daarom verskaf kubectl die opdrag kubectl explain, wat die spesifikasies van alle hulpbronne direk in jou terminaal wys.

Die opdragformaat is soos volg:

$ kubectl explain resource[.field]...

Die opdrag sal die spesifikasie van die gevraagde hulpbron of veld uitvoer. Die inligting wat vertoon word, is identies aan dié wat in die API-handleiding vervat is.

By verstek kubectl explain toon slegs die eerste vlak van nes van velde.

Kyk hoe dit lyk kan hier wees.

Jy kan die hele boom vertoon as jy die opsie byvoeg --recursive:

$ kubectl explain deployment.spec --recursive

As jy nie presies weet watter hulpbronne benodig word nie, kan jy hulle almal vertoon met die volgende opdrag:

$ kubectl api-resources

Hierdie opdrag vertoon hulpbronname in meervoudsvorm, bv. deployments in plaas van deployment. Dit vertoon byvoorbeeld ook die kort naam deploy, vir daardie hulpbronne wat dit het. Moenie bekommerd wees oor hierdie verskille nie. Al hierdie naamopsies is gelykstaande aan kubectl. Dit wil sê, jy kan enige van hulle gebruik vir kubectl explain.

Al die volgende opdragte is ekwivalent:

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

3. Gebruik 'n pasgemaakte kolomuitvoerformaat

Verstek opdrag uitvoer formaat 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

Hierdie formaat is gerieflik, maar dit bevat 'n beperkte hoeveelheid inligting. In vergelyking met die volledige hulpbrondefinisieformaat word slegs 'n paar velde hier vertoon.

In hierdie geval kan u 'n pasgemaakte kolomuitsetformaat gebruik. Dit laat jou toe om te bepaal watter data om uit te voer. Jy kan enige hulpbronveld as 'n aparte kolom vertoon.

Die gebruik van 'n pasgemaakte formaat word bepaal deur die opsies:

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

Jy kan elke uitvoerkolom as 'n paar definieer <header>:<jsonpath>Waar <header> is die kolomnaam, en <jsonpath> — 'n uitdrukking wat 'n hulpbronveld definieer.

Kom ons kyk na 'n eenvoudige voorbeeld:

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

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

Die afvoer bevat een kolom met die name van die peule.

Die opsie-uitdrukking kies die peulname uit die veld metadata.name. Dit is omdat die naam van die peul in die kindnaamveld gedefinieer word metadata in die hulpbronbeskrywing van die peul. Meer besonderhede kan gevind word in API-gids of tik die opdrag kubectl explain pod.metadata.name.

Kom ons sê nou jy wil 'n ekstra kolom by die uitvoer voeg, byvoorbeeld om die nodus te wys waarop elke peul loop. Om dit te doen, kan jy eenvoudig die toepaslike kolomspesifikasie by die pasgemaakte kolomme-opsie voeg:

$ 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

Die uitdrukking kies die nodusnaam uit spec.nodeName — wanneer 'n peul aan 'n nodus toegewys word, word sy naam in die veld geskryf spec.nodeName peulhulpbronspesifikasie. Meer gedetailleerde inligting kan in die uitset gevind word kubectl explain pod.spec.nodeName.

Neem asseblief kennis dat Kubernetes-hulpbronvelde hooflettergevoelig is.

Jy kan enige hulpbronveld as 'n kolom sien. Hersien net die hulpbronspesifikasie en probeer dit uit met enige velde wat jy wil.

Maar kom ons kyk eers na veldkeuse-uitdrukkings van naderby.

JSONPath-uitdrukkings

Uitdrukkings vir die seleksie van hulpbronvelde is gebaseer op JSONPath.

JSONPath is 'n taal vir die herwinning van data uit JSON-dokumente. Die keuse van 'n enkele veld is die eenvoudigste gebruiksgeval vir JSONPath. Hy het baie meer moontlikhede, insluitend kiesers, filters en so meer.

Kubectl verduidelik ondersteun 'n beperkte aantal JSONPath-kenmerke. Die moontlikhede en voorbeelde van hul gebruik word hieronder beskryf:

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

Die [] operateur is veral belangrik. Baie Kubernetes-hulpbronvelde is lyste, en hierdie operateur laat jou toe om lede van daardie lyste te kies. Dit word dikwels gebruik met 'n jokerteken soos [*] om alle elemente van 'n lys te kies.

Toepassingsvoorbeelde

Die moontlikhede vir die gebruik van 'n pasgemaakte kolomafvoerformaat is eindeloos, aangesien jy enige veld of kombinasie van hulpbronvelde in die uitvoer kan vertoon. Hier is 'n paar voorbeeldprogramme, maar verken dit gerus self en vind toepassings wat vir jou werk.

Vertoon houerbeelde vir peule:

$ 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

Hierdie opdrag vertoon die houerprentname vir elke peul.

Onthou dat 'n peul verskeie houers kan bevat, dan sal die prentname op een reël vertoon word, geskei deur kommas.

Vertoon nodus beskikbaarheid sones:
```
$ 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
```
Hierdie opdrag is nuttig as jou groepering in 'n publieke wolk gehuisves word. Dit wys die beskikbaarheidsone vir elke nodus.

Beskikbaarheidsone is 'n wolkkonsep wat die replikasiesone tot 'n geografiese streek beperk.

Beskikbaarheidsones vir elke nodus word verkry deur 'n spesiale etiket - failure-domain.beta.kubernetes.io/zone. As die groepering in 'n publieke wolk loop, word hierdie etiket outomaties geskep en gevul met die name van die beskikbaarheidsones vir elke nodus.

Etikette is nie deel van die Kubernetes-hulpbronspesifikasie nie, so jy sal nie inligting daaroor vind in API-gids. Hulle kan egter gesien word (soos enige ander etikette) as jy inligting oor die nodusse in YAML- of JSON-formaat versoek:
```
$ kubectl get nodes -o yaml
# или
$ kubectl get nodes -o json
```
Dit is 'n goeie manier om meer oor hulpbronne te wete te kom, benewens om hulpbronspesifikasies te leer.

4. Skakel maklik tussen groepe en naamruimtes

Wanneer kubectl 'n versoek aan die Kubernetes API rig, lees dit eers die kubeconfig-lêer om al die nodige parameters vir die verbinding te kry.

By verstek is die kubeconfig-lêer ~/.kube/config. Tipies word hierdie lêer geskep of opgedateer deur 'n spesiale opdrag.

Wanneer jy met veelvuldige groepe werk, bevat jou kubeconfig-lêer instellings om aan al daardie groepe te koppel. U het 'n manier nodig om die kubectl-opdrag te vertel met watter groep u werk.

Binne 'n groepering kan jy veelvuldige naamruimtes skep—'n tipe virtuele groepering binne 'n fisiese groepering. Kubectl bepaal ook watter naamruimte om te gebruik gebaseer op die kubeconfig-lêer. Dit beteken dat jy ook 'n manier nodig het om die kubectl-opdrag te vertel watter naamruimte om mee te werk.

In hierdie hoofstuk sal ons verduidelik hoe dit werk en hoe om dit effektief te laat werk.

Let daarop dat u moontlik verskeie kubeconfig-lêers in die KUBECONFIG-omgewingsveranderlike gelys het. In hierdie geval sal al hierdie lêers gekombineer word in een algemene konfigurasie tydens looptyd. U kan ook die verstekkubeconfig-lêer verander deur kubectl met die parameter uit te voer --kubeconfig. Kyk amptelike dokumentasie.

kubeconfig lêers

Kom ons kyk wat presies die kubeconfig-lêer bevat:

Soos u kan sien, bevat die kubeconfig-lêer 'n stel kontekste. Konteks bestaan uit drie elemente:

Cluster - API URL van die cluster bediener.
Gebruiker - gebruiker stawing geloofsbriewe in die groepering.
Naamspasie - die naamspasie wat gebruik word wanneer by die groep aangesluit word.

In die praktyk gebruik hulle dikwels een konteks per groepering in hul kubeconfig. U kan egter veelvuldige kontekste per groepering hê, onderskei deur gebruiker of naamruimte. Hierdie multi-konteks konfigurasie is egter ongewoon, so daar is gewoonlik 'n een-tot-een kartering tussen trosse en kontekste.

Op enige gegewe tydstip is een van die kontekste aktueel:

Wanneer kubectl 'n konfigurasielêer lees, neem dit altyd inligting uit die huidige konteks. In die voorbeeld hierbo sal kubectl aan die Haas-kluster koppel.

Gevolglik, om na 'n ander groep oor te skakel, moet jy die huidige konteks in die kubeconfig-lêer verander:

Nou sal kubectl aan die Fox-groep koppel.

Om na 'n ander naamruimte in dieselfde groepie oor te skakel, moet jy die waarde van die naamruimte-element vir die huidige konteks verander:

In die voorbeeld hierbo sal kubectl die Fox-groep se Prod-naamruimte gebruik (voorheen is die toetsnaamruimte gestel).

Let daarop dat kubectl ook opsies bied --cluster, --user, --namespace и --context, wat jou toelaat om individuele elemente en die huidige konteks self te oorskryf, ongeag wat in die kubeconfig gestel is. Kyk kubectl options.

In teorie kan u die instellings in die kubeconfig handmatig verander. Maar dis ongerieflik. Om hierdie bewerkings te vereenvoudig, is daar verskeie nutsprogramme waarmee u parameters outomaties kan verander.

Gebruik kubectx

'n Baie gewilde hulpmiddel om tussen groepe en naamruimtes te wissel.

Die nut verskaf opdragte kubectx и kubens om die huidige konteks en naamruimte onderskeidelik te verander.

Soos genoem, beteken die verandering van die huidige konteks om die groep te verander as jy net een konteks per groep het.

Hier is 'n voorbeeld van die uitvoer van hierdie opdragte:

In wese wysig hierdie opdragte eenvoudig die kubeconfig-lêer soos hierbo beskryf.

te installeer kubectx, volg die instruksies op GitHub.

Albei opdragte ondersteun outovoltooiing van konteks- en naamruimtename, wat die behoefte uitskakel om dit heeltemal te tik. Instruksies vir die opstel van outovoltooiing hier.

Nog 'n nuttige kenmerk kubectx is interaktiewe modus. Dit werk in samewerking met die nut fzf, wat apart geïnstalleer moet word. Die installering van fzf maak outomaties interaktiewe modus beskikbaar in kubectx. Interaktief kan jy konteks en naamruimte kies deur die interaktiewe gratis soekkoppelvlak wat deur fzf verskaf word.

Gebruik dopaliasse

Jy het nie aparte gereedskap nodig om die huidige konteks en naamruimte te verander nie, want kubectl verskaf ook opdragte hiervoor. Ja, span kubectl config verskaf subopdragte vir die redigering van kubeconfig-lêers.

Hier is 'n paar van hulle:

kubectl config get-contexts: vertoon alle kontekste;
kubectl config current-context: kry huidige konteks;
kubectl config use-context: verander huidige konteks;
kubectl config set-context: Verander die kontekselement.

Dit is egter nie baie gerieflik om hierdie opdragte direk te gebruik nie, want hulle is lank. Jy kan dopaliasse vir hulle maak wat maklik is om uit te voer.

Ek het 'n stel aliasse geskep gebaseer op hierdie opdragte wat funksionaliteit soortgelyk aan kubectx bied. Hier kan jy hulle in aksie sien:

Let daarop dat aliasse fzf gebruik om 'n interaktiewe gratis opsoek-koppelvlak (soos kubectx se interaktiewe modus) te verskaf. Dit beteken dat jy nodig het installeer fzfom hierdie aliasse te gebruik.

Hier is die definisies van aliasse self:

# Получить текущий контекст
alias krc='kubectl config current-context'
# Список всех контекстов
alias klc='kubectl config get-contexts -o name | sed "s/^/  /;|^  $(krc)$|s/ /*/"'
# Изменить текущий контекст
alias kcc='kubectl config use-context "$(klc | fzf -e | sed "s/^..//")"'

# Получить текущее пространство имен
alias krn='kubectl config get-contexts --no-headers "$(krc)" | awk "{print $5}" | sed "s/^$/default/"'
# Список всех пространств имен
alias kln='kubectl get -o name ns | sed "s|^.*/|  |;|^  $(krn)$|s/ /*/"'
# Изменить текущее пространство имен
alias kcn='kubectl config set-context --current --namespace "$(kln | fzf -e | sed "s/^..//")"'

Om hierdie aliasse te stel, moet jy die bogenoemde definisies by jou lêer voeg ~/.bashrc of ~/.zshrc en herlaai jou dop.

Gebruik plugins

Kubectl laat jou toe om plugins te laai wat op dieselfde manier as basiese opdragte uitgevoer word. U kan byvoorbeeld die kubectl-foo-inprop installeer en dit laat loop deur die opdrag uit te voer kubectl foo.

Dit sal gerieflik wees om die konteks en naamruimte op hierdie manier te verander, byvoorbeeld deur te hardloop kubectl ctx konteks te verander en kubectl ns om die naamruimte te verander.

Ek het twee inproppe geskryf wat dit doen:

Die werk van plugins is gebaseer op aliasse uit die vorige afdeling.

Dit is hoe hulle werk:

Let daarop dat die inproppe fzf gebruik om 'n interaktiewe gratis soekkoppelvlak (soos kubectx se interaktiewe modus) te verskaf. Dit beteken dat jy nodig het installeer fzfom hierdie aliasse te gebruik.

Om plugins te installeer, moet u dopskrifte aflaai met die naam kubectl-ctx и kubectl-ns na enige gids in jou PATH veranderlike en maak dit uitvoerbaar met bv. chmod +x. Onmiddellik hierna sal jy in staat wees om te gebruik kubectl ctx и kubectl ns.

5. Verminder invoer met outo-aliases

Shell-aliasse is 'n goeie manier om insette te bespoedig. Projek kubectl-aliasse bevat ongeveer 800 kortpaaie vir basiese kubectl-opdragte.

Jy wonder dalk – hoe onthou jy 800 aliasse? Maar jy hoef hulle nie almal te onthou nie, want hulle is gebou volgens 'n eenvoudige skema, wat hieronder gegee word:

Byvoorbeeld:

kgpooyaml - kubectl kry peule oyaml
ksysgsvcw — kubectl -n kube-stelsel kry svc w
ksysrmcm -kubectl -n kube-stelsel rm cm
kgdepallsl - kubectl kry ontplooiing alle sl

Soos u kan sien, bestaan aliasse uit komponente, wat elkeen 'n spesifieke element van die kubectl-opdrag verteenwoordig. Elke alias kan een komponent vir die basisopdrag, operasie en hulpbron hê, en veelvuldige komponente vir parameters. Jy "vul" eenvoudig hierdie komponente van links na regs volgens die diagram hierbo.

Die huidige gedetailleerde diagram is by GitHub. Daar kan jy ook vind volledige lys van aliasse.

Byvoorbeeld, die alias kgpooyamlall is gelykstaande aan die opdrag kubectl get pods -o yaml --all-namespaces.

Die relatiewe volgorde van die opsies is nie belangrik nie: bevel kgpooyamlall is gelykstaande aan die opdrag kgpoalloyaml.

Jy hoef nie alle komponente as aliasse te gebruik nie. Byvoorbeeld k, kg, klo, ksys, kgpo kan ook gebruik word. Boonop kan u aliasse en gereelde opdragte of opsies op die opdragreël kombineer:

Byvoorbeeld:

In plaas van kubectl proxy jy kan skryf k proxy.
In plaas van kubectl get roles jy kan skryf kg roles (daar is tans geen alias vir die Rolle-hulpbron nie).
Om data vir 'n spesifieke peul te kry, kan jy die opdrag gebruik kgpo my-pod — kubectl get pod my-pod.

Neem asseblief kennis dat sommige aliasse 'n opdragreëlargument vereis. Byvoorbeeld, alias kgpol beteken kubectl get pods -l. Opsie -l vereis 'n argument - 'n etiketspesifikasie. As jy 'n alias gebruik sal dit lyk kgpol app=ui.

Omdat sommige aliasse argumente vereis, moet aliasse a, f en l laaste gebruik word.

Oor die algemeen, sodra jy hierdie skema onder die knie het, kan jy intuïtief aliasse aflei van die opdragte wat jy wil uitvoer en baie tiktyd bespaar.

installasie

Om kubectl-aliasse te installeer, moet jy die lêer aflaai .kubectl_aliasse vanaf GitHub en sluit dit in die lêer in ~/.bashrc of ~/.zshrc:

source ~/.kubectl_aliases

Outovoltooiing

Soos ons voorheen gesê het, voeg jy dikwels bykomende woorde by 'n alias op die opdragreël. Byvoorbeeld:

$ kgpooyaml test-pod-d4b77b989

As jy kubectl-opdragvoltooiing gebruik, het jy waarskynlik outovoltooiing gebruik vir dinge soos hulpbronname. Maar kan dit gedoen word wanneer aliasse gebruik word?

Dit is 'n baie belangrike vraag, want as outovoltooiing nie werk nie, sal jy sommige van die voordele van aliasse verloor.

Die antwoord hang af van watter dop jy gebruik:

Vir Zsh werk aliasvoltooiing buite die boks.
Vir Bash is daar ongelukkig 'n bietjie werk nodig om outovoltooiing te laat werk.

Aktiveer outovoltooiing vir aliasse in Bash

Die probleem met Bash is dat dit probeer om (elke keer as jy Tab druk) die alias te voltooi, nie die opdrag waarna die alias verwys nie (soos byvoorbeeld Zsh doen). Aangesien jy nie voltooiingsskrifte vir al 800 aliasse het nie, werk outovoltooiing nie.

Project volledige-alias bied 'n algemene oplossing vir hierdie probleem. Dit koppel aan die voltooiingsmeganisme vir aliasse, brei die alias intern uit na 'n opdrag, en gee voltooiingsopsies vir die voltooide opdrag terug. Dit beteken dat die opvulling vir 'n alias presies dieselfde optree as vir 'n volledige opdrag.

In die volgende sal ek eers verduidelik hoe om complete-alias te installeer en dan hoe om dit in te stel om voltooiing vir alle kubectl-aliasse moontlik te maak.

Installeer volledige alias

Eerstens hang volledige-alias af van bash-voltooiing. Daarom, voordat u complete-alias installeer, moet u seker maak dat bash-completion geïnstalleer is. Installasie-instruksies is voorheen vir Linux en MacOS verskaf.

Belangrike opmerking vir MacOS-gebruikers: Soos die kubectl-outovoltooiingsskrif, werk complete-alias nie met Bash 3.2, wat die verstek op MacOS is nie. In die besonder, volledige-alias hang af van bash-voltooiing v2 (brew install bash-completion@2), wat ten minste Bash 4.1 vereis. Dit beteken dat om volledige alias op MacOS te gebruik, jy 'n nuwer weergawe van Bash moet installeer.

Jy moet die skrif aflaai bash_completion.sh van GitHub-bewaarplek en sluit dit in jou lêer in ~/.bashrc:

source ~/bash_completion.sh

Nadat die dop herlaai is, sal complete-alias volledig geïnstalleer word.

Aktiveer outovoltooiing vir kubectl-aliasse

Tegnies volledige alias bied 'n omhulfunksie _complete_alias. Hierdie funksie kontroleer die alias en gee voltooiingswenke vir die alias-opdrag.

Om 'n funksie met 'n spesifieke alias te assosieer, moet jy die ingeboude Bash-meganisme gebruik volledige, te installeer _complete_alias as 'n alias-voltooiingsfunksie.

As 'n voorbeeld, kom ons neem die alias k, wat staan vir die kubectl-opdrag. te installeer _complete_alias As 'n aanvullingsfunksie vir hierdie alias, moet jy die volgende opdrag uitvoer:

$ complete -F _complete_alias k

Die resultaat hiervan is dat wanneer jy 'n alias k outovoltooi, die funksie opgeroep word _complete_alias, wat die alias nagaan en voltooiingswenke vir die opdrag gee kubectl.

As 'n tweede voorbeeld, kom ons neem die alias kg, wat aandui kubectl get:

$ complete -F _complete_alias kg

Net soos in die vorige voorbeeld, wanneer jy kg outovoltooi, kry jy dieselfde voltooiingswenke as wat jy sou kry vir kubectl get.

Let daarop dat jy volledige alias vir enige alias op jou stelsel kan gebruik.

Daarom, om outovoltooiing vir alle kubectl-aliasse te aktiveer, moet u die bogenoemde opdrag vir elkeen van hulle uitvoer. Die volgende brokkie doen presies dit, mits jy kubectl-aliasse op gestel het ~/.kubectl-aliases:

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

Hierdie stukkie kode moet in jou ~/.bashrc, herbegin die opdragdop en outovoltooiing sal beskikbaar wees vir al 800 kubectl-aliasse.

6. Die uitbreiding van kubectl met plugins

Begin met weergawe 1.12, kubectl ondersteun inpropmeganisme, wat jou toelaat om sy funksies uit te brei met bykomende opdragte.

As u vertroud is met Git-inpropmeganismes, dan is kubectl-inproppe op dieselfde beginsel gebou.

In hierdie hoofstuk sal ons dek hoe om inproppe te installeer, waar om dit te vind en hoe om jou eie inproppe te skep.

Installeer plugins

Kubectl-inproppe word versprei as eenvoudige uitvoerbare lêers met die naam soos kubectl-x. Voorvoegsel kubectl- word vereis, gevolg deur 'n nuwe kubectl-subopdrag wat jou toelaat om die inprop te bel.

Byvoorbeeld, die hallo-inprop sal versprei word as 'n lêer genaamd kubectl-hello.

Om die inprop te installeer, moet jy die lêer kopieer kubectl-x na enige gids in jou PATH en maak dit uitvoerbaar, byvoorbeeld met chmod +x. Onmiddellik hierna kan jy die inprop bel met kubectl x.

U kan die volgende opdrag gebruik om alle inproppe wat tans op u stelsel geïnstalleer is, te lys:

$ kubectl plugin list

Hierdie opdrag sal ook waarskuwings vertoon as jy veelvuldige inproppe met dieselfde naam het, of as daar 'n inproplêer is wat nie uitvoerbaar is nie.

Soek en installeer plugins met Krew

Kubectl-inproppe kan gedeel of hergebruik word soos sagtewarepakkette. Maar waar kan u inproppe vind wat ander gedeel het?

Projek Krew beoog om 'n verenigde oplossing te bied vir die deel, soek, installering en bestuur van kubectl-inproppe. Die projek noem homself 'n "pakketbestuurder vir kubectl-inproppe" (Krew is soortgelyk aan Brew).

Krew is 'n lys van kubectl-inproppe wat u kan kies en installeer. Terselfdertyd is Krew ook 'n inprop vir kubectl.

Dit beteken dat die installering van Krew in wese werk soos om enige ander kubectl-inprop te installeer. Jy kan gedetailleerde instruksies vind by GitHub-bladsy.

Die belangrikste Krew-opdragte is:

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

Neem asseblief kennis dat die installering van plugins met Krew nie inmeng met die installering van plugins met behulp van die standaardmetode hierbo beskryf nie.

Neem asseblief kennis dat die opdrag kubectl krew list vertoon slegs plugins wat met Krew geïnstalleer is, terwyl die opdrag kubectl plugin list lys alle inproppe, dit wil sê dié wat met Krew geïnstalleer is en dié wat deur ander metodes geïnstalleer is.

Soek plugins elders

Krew is 'n jong projek, tans in sy die lys slegs sowat 30 plugins. As jy nie kan kry wat jy nodig het nie, kan jy plugins elders vind, soos GitHub.

Ek beveel aan om na die GitHub-afdeling te kyk kubectl-invoegtoepassings. Daar sal u tientalle beskikbare inproppe vind wat die moeite werd is om na te gaan.

Skryf jou eie plugins

jy kan self skep plugins - Dit is nie moeilik nie. Jy moet 'n uitvoerbare lêer skep wat doen wat jy nodig het, noem dit soos kubectl-x en installeer soos hierbo beskryf.

Die lêer kan 'n bash script, 'n python script, of 'n saamgestelde GO toepassing wees - dit maak nie saak nie. Die enigste voorwaarde is dat dit direk in die bedryfstelsel uitgevoer kan word.

Kom ons skep nou 'n voorbeeld-inprop. In die vorige afdeling het jy die kubectl-opdrag gebruik om die houers vir elke peul te lys. Dit is maklik om hierdie opdrag te verander in 'n inprop wat jy kan bel met bv. kubectl img.

Skep 'n lêer kubectl-img die volgende inhoud:

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

Maak nou die lêer uitvoerbaar met chmod +x kubectl-img en skuif dit na enige gids in jou PATH. Onmiddellik hierna kan jy die inprop gebruik kubectl img.

Soos genoem, kan kubectl-inproppe in enige programmeer- of skriftaal geskryf word. As jy dopskrifte gebruik, is die voordeel dat jy kubectl maklik van binne die inprop kan bel. U kan egter meer komplekse inproppe in regte programmeertale skryf deur gebruik te maak Kubernetes kliënt biblioteek. As jy Go gebruik, kan jy ook gebruik cli-looptyd-biblioteek, wat spesifiek bestaan om kubectl-inproppe te skryf.

Hoe om jou plugins te deel

As jy dink jou inproppe kan nuttig wees vir ander, deel dit gerus op GitHub. Maak seker dat jy hulle by die onderwerp voeg kubectl-invoegtoepassings.

Jy kan ook versoek dat jou inprop bygevoeg word Krew lys. Instruksies oor hoe om dit te doen is in GitHub-bewaarplekke.

Opdrag voltooiing

Inproppe ondersteun tans nie outovoltooiing nie. Dit wil sê, jy moet die volle naam van die inprop en die volle name van die argumente invoer.

Die GitHub kubectl-bewaarplek vir hierdie funksie het oop versoek. Dit is dus moontlik dat hierdie kenmerk een of ander tyd in die toekoms geïmplementeer sal word.

Sterkte!!!

Wat anders om te lees oor die onderwerp:

Bron: will.com

Hoe om kubectl doeltreffender te gebruik: 'n gedetailleerde gids