🥇Kubectl effectiever gebruiken: een gedetailleerde gids

Als je met Kubernetes werkt, dan is kubectl waarschijnlijk een van de hulpprogramma's die je het meest gebruikt. En wanneer u veel tijd besteedt aan het werken met een bepaald hulpmiddel, loont het de moeite om het goed te bestuderen en te leren hoe u het effectief kunt gebruiken.

Team Kubernetes aaS van Mail.ru een artikel vertaald van Daniel Weibel waarin je tips en trucs vindt om effectief met kubectl te werken. Het zal u ook helpen een dieper inzicht te krijgen in Kubernetes.

Volgens de auteur is het doel van het artikel om jouw dagelijkse werk met Kubernetes niet alleen efficiënter, maar ook leuker te maken!

Inleiding: Wat is kubectl

Voordat u kubectl effectiever kunt leren gebruiken, moet u basiskennis verwerven over wat het is en hoe het werkt.

Vanuit het perspectief van een gebruiker is kubectl een configuratiescherm waarmee u Kubernetes-bewerkingen kunt uitvoeren.

Technisch gezien is kubectl een Kubernetes API-client.

Kubernetes API is een HTTP REST API. Deze API is de echte Kubernetes-gebruikersinterface, waardoor deze volledig wordt aangestuurd. Dit betekent dat elke Kubernetes-bewerking wordt weergegeven als een API-eindpunt en kan worden gedaan met een HTTP-verzoek aan dat eindpunt.

Daarom is de belangrijkste taak van kubectl het doen van HTTP-verzoeken aan de Kubernetes API:

Kubernetes is een volledig resource-georiënteerd systeem. Dit betekent dat het de interne staat van de bronnen handhaaft en dat alle Kubernetes-bewerkingen CRUD-bewerkingen zijn.

U heeft volledige controle over Kubernetes door deze bronnen te beheren, en Kubernetes bedenkt wat te doen op basis van de huidige staat van de bronnen. Om deze reden is de Kubernetes API-referentie georganiseerd als een lijst met resourcetypen met de bijbehorende bewerkingen.

Laten we eens kijken naar een voorbeeld.

Stel dat u een ReplicaSet-resource wilt maken. Om dit te doen, beschrijft u de ReplicaSet in een bestand op naam replicaset.yamlen voer vervolgens de opdracht uit:

$ kubectl create -f replicaset.yaml

Hiermee wordt een ReplicaSet-resource gemaakt. Maar wat gebeurt er achter de schermen?

Kubernetes heeft een ReplicaSet-bewerking. Net als elke andere bewerking wordt deze weergegeven als een API-eindpunt. Het specifieke API-eindpunt voor deze bewerking ziet er als volgt uit:

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

API-eindpunten voor alle Kubernetes-bewerkingen zijn te vinden op API-referentie (met inbegrip van het bovenstaande eindpunt). Als u een daadwerkelijk verzoek aan een eindpunt wilt doen, moet u eerst de API-server-URL toevoegen aan de eindpuntpaden die worden vermeld in de API-referentie.

Wanneer u de bovenstaande opdracht uitvoert, verzendt kubectl dus een HTTP POST-verzoek naar het bovenstaande API-eindpunt. De ReplicaSet-definitie die u in het bestand hebt opgegeven replicaset.yaml, wordt verzonden in de hoofdtekst van het verzoek.

Dit is hoe kubectl werkt voor alle opdrachten die communiceren met het Kubernetes-cluster. In al deze gevallen doet kubectl eenvoudigweg HTTP-verzoeken aan de juiste Kubernetes API-eindpunten.

Houd er rekening mee dat u Kubernetes volledig kunt beheren met een hulpprogramma zoals curldoor handmatig HTTP-verzoeken naar de Kubernetes API te sturen. Kubectl maakt het eenvoudigweg eenvoudiger om de Kubernetes API te gebruiken.

Dit is de basis van wat kubectl is en hoe het werkt. Maar er is nog iets anders aan de Kubernetes API dat elke kubectl-gebruiker zou moeten weten. Laten we even een kijkje nemen in de innerlijke wereld van Kubernetes.

De binnenwereld van Kubernetes

Kubernetes bestaat uit een reeks onafhankelijke componenten die als afzonderlijke processen op clusterknooppunten draaien. Sommige componenten draaien op hoofdknooppunten, andere op werkknooppunten, waarbij elke component zijn eigen specifieke taak uitvoert.

Dit zijn de belangrijkste componenten op de hoofdknooppunten:

bewaarplaats - slaat resourcedefinities op (meestal is het enz).
API-server — biedt een API en beheert de opslag.
Controller beheerder — Zorgt ervoor dat de status van hulpbronnen voldoet aan de specificaties.
Планировщик — plant pods op werkknooppunten.

En hier is een van de belangrijkste componenten op de werkknooppunten:

kubus — beheert de lancering van containers op het werkknooppunt.

Laten we een voorbeeld bekijken om te begrijpen hoe deze componenten samenwerken.

Laten we aannemen dat u zojuist klaar bent kubectl create -f replicaset.yaml, waarna kubectl een HTTP POST-verzoek deed aan ReplicaSet API-eindpunt (waarbij de ReplicaSet-resourcedefinitie wordt doorgegeven).

Wat gebeurt er in het cluster?

Na het doen van kubectl create -f replicaset.yaml De API-server slaat uw ReplicaSet-resourcedefinitie op in de opslag:
Vervolgens wordt de ReplicaSet-controller gestart in de controllermanager, die het maken, wijzigen en verwijderen van ReplicaSet-bronnen afhandelt:
De ReplicaSet-controller maakt een poddefinitie voor elke ReplicaSet-replica (volgens de pod-sjabloon in de ReplicaSet-definitie) en slaat deze op in de opslag:
De planner wordt gestart en volgt pods die nog niet zijn toegewezen aan werkknooppunten:
De planner selecteert voor elke pod een geschikt werkknooppunt en voegt deze informatie toe aan de poddefinitie in de winkel:
Op het werkknooppunt waaraan de pod is toegewezen, wordt Kubelet gelanceerd. Het volgt de pods die aan dit knooppunt zijn toegewezen:
De Kubelet leest de poddefinitie uit de opslag en instrueert een containerruntime, zoals Docker, om containers op het knooppunt te starten:

Hieronder vindt u een tekstversie van deze beschrijving.

Het API-verzoek aan het eindpunt voor het maken van ReplicaSet wordt verwerkt door de API-server. De API-server verifieert het verzoek en slaat de ReplicaSet-brondefinitie op in de opslag.

Deze gebeurtenis start de ReplicaSet-controller, een subproces van de controllermanager. De ReplicaSet-controller bewaakt het maken, bijwerken en verwijderen van ReplicaSet-bronnen in de winkel en ontvangt een gebeurtenismelding wanneer dit gebeurt.

De taak van de ReplicaSet-controller is ervoor te zorgen dat het vereiste aantal ReplicaSet-pods bestaat. In ons voorbeeld bestaan er nog geen pods, dus de ReplicaSet-controller maakt deze poddefinities (volgens de pod-sjabloon in de ReplicaSet-definitie) en slaat deze op in de opslag.

Het maken van nieuwe peulen wordt geactiveerd door een planner die poddefinities bijhoudt die nog niet zijn gepland voor werkknooppunten. De planner selecteert voor elke pod een geschikt werkknooppunt en werkt de poddefinities in de repository bij.

Houd er rekening mee dat er tot nu toe nergens in het cluster werkbelastingcode werd uitgevoerd. Alles wat tot nu toe is gedaan - dit is het aanmaken en bijwerken van bronnen in de repository op het masterknooppunt.

De laatste gebeurtenis activeert Kubelets, die de pods bewaken die zijn gepland voor hun werkknooppunten. De Kubelet van het werkknooppunt waarop uw ReplicaSet-pods zijn geïnstalleerd, moet de containerruntime, zoals Docker, instrueren om de vereiste containerinstallatiekopieën te downloaden en uit te voeren.

Op dit punt is uw ReplicaSet-applicatie eindelijk actief!

Rol van de Kubernetes-API

Zoals u in het vorige voorbeeld hebt gezien, letten Kubernetes-componenten (behalve de API-server en opslag) op wijzigingen in bronnen in opslag en wijzigen ze informatie over bronnen in opslag.

Uiteraard hebben deze componenten geen directe interactie met de opslag, maar alleen via de Kubernetes API.

Beschouw de volgende voorbeelden:

De ReplicaSet-controller gebruikt het API-eindpunt lijst ReplicaSets met parameter watch om wijzigingen in ReplicaSet-bronnen te controleren.
De ReplicaSet-controller gebruikt het API-eindpunt Pod maken (pod maken) om pods te maken.
Scheduler gebruikt API-eindpunt patch-pod (pod bewerken) om pods bij te werken met informatie over het geselecteerde werkknooppunt.

Zoals u kunt zien, is dit dezelfde API waartoe kubectl toegang heeft. Het gebruik van dezelfde API voor interne componenten en externe gebruikers is een fundamenteel concept in het Kubernetes-ontwerp.

Nu kunnen we samenvatten hoe Kubernetes werkt:

De opslagopslagplaatsen vermelden Kubernetes-bronnen.
De API-server biedt een interface voor de opslag in de vorm van de Kubernetes API.
Alle andere Kubernetes-componenten en gebruikers lezen, observeren en manipuleren de Kubernetes-status (bronnen) via de API.

Als u deze concepten kent, kunt u kubectl beter begrijpen en er het maximale uit halen.

Laten we nu eens kijken naar enkele specifieke tips en trucs die u zullen helpen uw productiviteit met kubectl te verbeteren.

1. Versnel de invoer door het voltooien van opdrachten

Een van de nuttigste, maar vaak over het hoofd geziene technieken voor het verbeteren van de prestaties met kubectl is het voltooien van opdrachten.

Met het voltooien van opdrachten kunt u delen van kubectl-opdrachten automatisch voltooien met behulp van de Tab-toets. Dit werkt voor subopdrachten, opties en argumenten, inclusief zoiets complex als bronnamen.

Bekijk hoe het voltooien van kubectl-opdrachten werkt:

Het voltooien van opdrachten werkt voor Bash- en Zsh-shells.

Officiële gids bevat gedetailleerde instructies voor het instellen van automatisch aanvullen, maar hieronder geven we een kort fragment.

Hoe het voltooien van opdrachten werkt

Commandovoltooiing is een shell-functie die werkt met behulp van een voltooiingsscript. Een extensiescript is een shellscript dat het gedrag van een extensie voor een specifieke opdracht definieert.

Kubectl genereert en voert automatisch extensiescripts uit voor Bash en Zsh met behulp van de volgende opdrachten:

$ kubectl completion bash

Или:

$ kubectl completion zsh

In theorie is het voldoende om de uitvoer van deze opdrachten te verbinden met de juiste opdrachtshell, zodat kubectl de opdrachten kan aanvullen.

In de praktijk is de verbindingsmethode anders voor Bash (inclusief verschillen tussen Linux en MacOS) en Zsh. Hieronder zullen we al deze opties bekijken.

Bash op Linux

Het Bash-voltooiingsscript is afhankelijk van het bash-voltooiingspakket, dus je moet het eerst installeren:

$ sudo apt-get install bash-completion

Или:

$ yum install bash-completion

U kunt testen of het pakket succesvol is geïnstalleerd met behulp van de volgende opdracht:

$ type _init_completion

Als hierdoor de shell-functiecode wordt uitgevoerd, is bash-completion correct geïnstalleerd. Als de opdracht de foutmelding "Niet gevonden" geeft, moet u de volgende regel aan uw bestand toevoegen ~ / .bashrc:

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

Is het nodig om deze regel aan het bestand toe te voegen ~ / .bashrc of niet hangt af van de pakketbeheerder die u gebruikte om bash-completion te installeren. Dit is nodig voor APT, maar niet voor YUM.

Nadat u bash-completion hebt geïnstalleerd, moet u alles zo configureren dat het kubectl-voltooiingsscript in alle shell-sessies is ingeschakeld.

Eén manier om dit te doen is door de volgende regel aan het bestand toe te voegen ~ / .bashrc:

source <(kubectl completion bash)

Een andere manier is om het kubectl-extensiescript aan de map toe te voegen /etc/bash_completion.d (maak het aan als het niet bestaat):

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

Alle add-on-scripts in de catalogus /etc/bash_completion.d worden automatisch opgenomen in bash-voltooiing.

Beide opties zijn evenzeer van toepassing.

Nadat de shell opnieuw is opgestart, werkt de voltooiing van de kubectl-opdracht.

Bash op MacOS

Op MacOS is de installatie iets ingewikkelder. Feit is dat MacOS standaard Bash versie 3.2 gebruikt, en het kubectl-script voor automatisch aanvullen vereist een Bash-versie van minimaal 4.1 en werkt niet in Bash 3.2.

Er zijn licentieproblemen verbonden aan het gebruik van een verouderde versie van Bash op MacOS. Bash versie 4 is gelicentieerd onder GPLv3, wat niet wordt ondersteund door Apple.

Om de automatische aanvulling van kubectl op MacOS te configureren, moet u een recentere versie van Bash installeren. Je kunt de bijgewerkte Bash ook instellen als je standaardshell, wat je in de toekomst veel problemen zal besparen. Het is niet moeilijk, details worden gegeven in het artikel “Bash bijwerken op MacOS.

Voordat u doorgaat, moet u ervoor zorgen dat u een recente versie van Bash gebruikt (controleer de uitvoer bash --version).

Het Bash-voltooiingsscript verschilt per project bash-voltooiing, dus je moet het eerst installeren.

Je kunt bash-completion installeren met behulp van Homebrew:

$ brew install bash-completion@2

Hier @2 staat voor bash-completion versie 2. kubectl autocompletion vereist bash-completion v2, en bash-completion v2 vereist minimaal Bash versie 4.1.

Commando-uitvoer brew-install bevat een sectie Caveats, die specificeert wat er aan het bestand moet worden toegevoegd ~/.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"

Ik raad echter aan om deze regels niet toe te voegen ~/.bash_profileen in ~/.bashrc. In dit geval is automatische aanvulling niet alleen beschikbaar in de hoofdopdracht, maar ook in onderliggende opdrachtshells.

Nadat u de opdrachtshell opnieuw hebt opgestart, kunt u met de volgende opdracht controleren of de installatie correct is:

$ type _init_completion

Als u een shell-functie in de uitvoer ziet, is alles correct geconfigureerd.

Nu moeten we ervoor zorgen dat kubectl automatisch aanvullen in alle sessies is ingeschakeld.

Eén manier is om de volgende regel toe te voegen aan uw ~/.bashrc:

source <(kubectl completion bash)

De tweede manier is door een automatisch aanvulscript aan de map toe te voegen /usr/local/etc/bash_completion.d:

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

Deze methode werkt alleen als je bash-completion hebt geïnstalleerd met Homebrew. In dit geval laadt bash-completion alle scripts uit deze map.

Als je hebt geïnstalleerd kubectl met Homebrew, dan is het niet nodig om de vorige stap uit te voeren, omdat het script voor automatisch aanvullen automatisch in de map wordt geplaatst /usr/local/etc/bash_completion.d Tijdens de installatie. In dit geval zal kubectl autocompletion beginnen te werken zodra u bash-completion installeert.

Als gevolg hiervan zijn al deze opties gelijkwaardig.

zsh

Automatische aanvullingsscripts voor Zsh vereisen geen afhankelijkheden. Het enige dat u hoeft te doen, is ze inschakelen wanneer u de opdrachtshell laadt.

U kunt dit doen door een regel aan uw ~/.zshrc bestand:

source <(kubectl completion zsh)

Als u een foutmelding krijgt not found: compdef nadat u uw shell opnieuw hebt opgestart, moet u de ingebouwde functie inschakelen compdef. U kunt dit inschakelen door het aan het begin van uw bestand toe te voegen ~/.zshrc het volgende:

autoload -Uz compinit
compinit

2. Bekijk snel de resourcespecificaties

Wanneer u YAML-resourcedefinities maakt, moet u de velden en hun betekenis voor die resources kennen. Eén plaats waar u deze informatie kunt zoeken, is de API-referentie, die volledige specificaties voor alle bronnen bevat.

Het is echter lastig om telkens naar de webbrowser over te schakelen wanneer u iets moet zoeken. Daarom levert kubectl de opdracht kubectl explain, die de specificaties van alle bronnen rechtstreeks in uw terminal toont.

Het opdrachtformaat is als volgt:

$ kubectl explain resource[.field]...

Met de opdracht wordt de specificatie van de aangevraagde bron of het aangevraagde veld weergegeven. De weergegeven informatie is identiek aan die in de API-handleiding.

Bij verstek kubectl explain toont alleen het eerste niveau van nesten van velden.

Kijk hoe het eruit ziet U kunt dan.

Als u de optie toevoegt, kunt u de hele boom weergeven --recursive:

$ kubectl explain deployment.spec --recursive

Als u niet precies weet welke bronnen nodig zijn, kunt u ze allemaal weergeven met de volgende opdracht:

$ kubectl api-resources

Deze opdracht geeft bronnamen in meervoud weer, b.v. deployments in plaats van deployment. Hier wordt bijvoorbeeld ook de korte naam weergegeven deploy, voor de bronnen die dit hebben. Maak je geen zorgen over deze verschillen. Al deze naamgevingsopties zijn gelijkwaardig voor kubectl. Dat wil zeggen, je kunt ze allemaal gebruiken kubectl explain.

Alle volgende opdrachten zijn gelijkwaardig:

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

3. Gebruik een aangepast kolomuitvoerformaat

Standaard uitvoerformaat voor opdrachten 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

Dit formaat is handig, maar bevat een beperkte hoeveelheid informatie. Vergeleken met het volledige resourcedefinitieformaat worden hier slechts enkele velden weergegeven.

In dit geval kunt u een aangepast kolomuitvoerformaat gebruiken. Hiermee kunt u bepalen welke gegevens moeten worden uitgevoerd. U kunt elk resourceveld als een afzonderlijke kolom weergeven.

Het gebruik van een aangepast formaat wordt bepaald met behulp van de opties:

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

U kunt elke uitvoerkolom als een paar definiëren <header>:<jsonpath>Waar <header> is de kolomnaam, en <jsonpath> — een expressie die een resourceveld definieert.

Laten we een eenvoudig voorbeeld bekijken:

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

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

De uitvoer bevat één kolom met de namen van de peulen.

De optie-expressie selecteert de podnamen uit het veld metadata.name. Dit komt omdat de naam van de pod is gedefinieerd in het onderliggende naamveld metadata in de resourcebeschrijving van de pod. Meer details zijn te vinden in API-gids of typ de opdracht kubectl explain pod.metadata.name.

Stel nu dat u een extra kolom aan de uitvoer wilt toevoegen, bijvoorbeeld door het knooppunt weer te geven waarop elke pod draait. Om dit te doen, kunt u eenvoudig de juiste kolomspecificatie toevoegen aan de optie voor aangepaste kolommen:

$ 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

De expressie selecteert de knooppuntnaam uit spec.nodeName — wanneer een pod aan een knooppunt wordt toegewezen, wordt de naam ervan in het veld geschreven spec.nodeName pod-bronspecificatie. Meer gedetailleerde informatie vindt u in de uitvoer kubectl explain pod.spec.nodeName.

Houd er rekening mee dat Kubernetes-bronvelden hoofdlettergevoelig zijn.

U kunt elk resourceveld als een kolom bekijken. Bekijk gewoon de resourcespecificatie en probeer het uit met alle velden die u leuk vindt.

Maar laten we eerst eens nader kijken naar veldselectie-expressies.

JSONPath-expressies

Expressies voor het selecteren van resourcevelden zijn gebaseerd op JSONPath.

JSONPath is een taal voor het ophalen van gegevens uit JSON-documenten. Het selecteren van een enkel veld is het eenvoudigste gebruiksscenario voor JSONPath. Hij heeft veel meer mogelijkheden, inclusief selectors, filters enzovoort.

Kubectl uitleg ondersteunt een beperkt aantal JSONPath-functies. De mogelijkheden en voorbeelden van hun gebruik worden hieronder beschreven:

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

Vooral de operator [] is belangrijk. Veel Kubernetes-bronvelden zijn lijsten, en met deze operator kunt u leden van die lijsten selecteren. Het wordt vaak gebruikt met een jokerteken zoals [*] om alle elementen van een lijst te selecteren.

Toepassingsvoorbeelden

De mogelijkheden voor het gebruik van een aangepast kolomuitvoerformaat zijn eindeloos, omdat u elk veld of elke combinatie van resourcevelden in de uitvoer kunt weergeven. Hier zijn enkele voorbeeldapps, maar u kunt ze gerust zelf verkennen en toepassingen vinden die voor u werken.

Containerimages voor pods weergeven:

$ 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

Met deze opdracht worden de namen van de containerinstallatiekopieën voor elke pod weergegeven.

Houd er rekening mee dat een pod meerdere containers kan bevatten. De namen van de afbeeldingen worden dan op één regel weergegeven, gescheiden door komma's.

Beschikbaarheidszones van knooppunten weergeven:
```
$ 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
```
Deze opdracht is handig als uw cluster wordt gehost in een openbare cloud. Het toont de beschikbaarheidszone voor elk knooppunt.

Beschikbaarheidszone is een cloudconcept dat de replicatiezone beperkt tot een geografische regio.

Beschikbaarheidszones voor elk knooppunt worden verkregen via een speciaal label - failure-domain.beta.kubernetes.io/zone. Als het cluster in een publieke cloud draait, wordt dit label automatisch aangemaakt en gevuld met de namen van de beschikbaarheidszones voor elk knooppunt.

Labels maken geen deel uit van de Kubernetes-resourcespecificatie, dus u vindt er geen informatie over in API-gids. Ze kunnen echter wel worden gezien (net als alle andere labels) als u informatie opvraagt over de knooppunten in YAML- of JSON-indeling:
```
$ kubectl get nodes -o yaml
# или
$ kubectl get nodes -o json
```
Dit is een geweldige manier om meer over leermiddelen te leren, naast de specificaties van leermiddelen.

4. Schakel eenvoudig tussen clusters en naamruimten

Wanneer kubectl een verzoek indient bij de Kubernetes API, leest het eerst het kubeconfig-bestand om alle benodigde parameters voor de verbinding op te halen.

Standaard is het kubeconfig-bestand ~/.kube/config. Normaal gesproken wordt dit bestand gemaakt of bijgewerkt door een speciale opdracht.

Wanneer u met meerdere clusters werkt, bevat uw kubeconfig-bestand instellingen voor het verbinden met al deze clusters. U hebt een manier nodig om de kubectl-opdracht te vertellen met welk cluster u werkt.

Binnen een cluster kunt u meerdere naamruimten maken: een soort virtueel cluster binnen een fysiek cluster. Kubectl bepaalt ook welke naamruimte moet worden gebruikt op basis van het kubeconfig-bestand. Dit betekent dat je ook een manier nodig hebt om de opdracht kubectl te vertellen met welke naamruimte je moet werken.

In dit hoofdstuk leggen we uit hoe het werkt en hoe je het effectief kunt laten werken.

Houd er rekening mee dat er mogelijk meerdere kubeconfig-bestanden zijn vermeld in de KUBECONFIG-omgevingsvariabele. In dit geval worden al deze bestanden tijdens runtime gecombineerd tot één gemeenschappelijke configuratie. U kunt ook het standaard kubeconfig-bestand wijzigen door kubectl uit te voeren met de parameter --kubeconfig. Zien officiële documentatie.

kubeconfig-bestanden

Laten we eens kijken wat het kubeconfig-bestand precies bevat:

Zoals u kunt zien, bevat het kubeconfig-bestand een reeks contexten. Context bestaat uit drie elementen:

Cluster — API-URL van de clusterserver.
Gebruiker: referenties voor gebruikersauthenticatie in het cluster.
Naamruimte: de naamruimte die wordt gebruikt bij deelname aan het cluster.

In de praktijk gebruiken ze vaak één context per cluster in hun kubeconfig. U kunt echter meerdere contexten per cluster hebben, verschillend per gebruiker of naamruimte. Deze configuratie met meerdere contexten is echter ongebruikelijk, dus er is meestal een één-op-één-toewijzing tussen clusters en contexten.

Op elk moment is een van de contexten actueel:

Wanneer kubectl een configuratiebestand leest, wordt altijd informatie uit de huidige context gebruikt. In het bovenstaande voorbeeld maakt kubectl verbinding met het Hare-cluster.

Als u naar een ander cluster wilt overschakelen, moet u daarom de huidige context in het kubeconfig-bestand wijzigen:

Nu zal kubectl verbinding maken met het Fox-cluster.

Als u naar een andere naamruimte in hetzelfde cluster wilt overschakelen, moet u de waarde van het naamruimte-element voor de huidige context wijzigen:

In het bovenstaande voorbeeld gebruikt kubectl de Prod-naamruimte van het Fox-cluster (voorheen was de Test-naamruimte ingesteld).

Merk op dat kubectl ook opties biedt --cluster, --user, --namespace и --context, waarmee u individuele elementen en de huidige context zelf kunt overschrijven, ongeacht wat er in de kubeconfig is ingesteld. Kijk kubectl options.

In theorie kun je de instellingen in de kubeconfig handmatig wijzigen. Maar het is lastig. Om deze handelingen te vereenvoudigen, zijn er verschillende hulpprogramma's waarmee u parameters automatisch kunt wijzigen.

Gebruik kubectx

Een zeer populair hulpprogramma voor het schakelen tussen clusters en naamruimten.

Het hulpprogramma biedt opdrachten kubectx и kubens om respectievelijk de huidige context en naamruimte te wijzigen.

Zoals gezegd betekent het wijzigen van de huidige context het wijzigen van het cluster als u slechts één context per cluster heeft.

Hier is een voorbeeld van het uitvoeren van deze opdrachten:

In wezen bewerken deze opdrachten eenvoudigweg het kubeconfig-bestand zoals hierboven beschreven.

installeren kubectx, volg de instructies op Github.

Beide opdrachten ondersteunen het automatisch aanvullen van context- en naamruimtenamen, waardoor het niet meer nodig is om ze volledig te typen. Instructies voor het instellen van automatisch aanvullen hier.

Nog een handige functie kubectx is interactieve modus. Het werkt in combinatie met het hulpprogramma FZF, die apart geïnstalleerd moet worden. Door fzf te installeren wordt de interactieve modus automatisch beschikbaar in kubectx. Interactief kunt u context en naamruimte selecteren via de interactieve gratis zoekinterface van fzf.

Shell-aliassen gebruiken

Je hebt geen aparte tools nodig om de huidige context en naamruimte te wijzigen, omdat kubectl hiervoor ook opdrachten biedt. Ja, team kubectl config biedt subopdrachten voor het bewerken van kubeconfig-bestanden.

Hier zijn enkele van hen:

kubectl config get-contexts: toon alle contexten;
kubectl config current-context: huidige context ophalen;
kubectl config use-context: verander huidige context;
kubectl config set-context: Wijzig het contextelement.

Het rechtstreeks gebruiken van deze opdrachten is echter niet erg handig omdat ze lang zijn. U kunt er shell-aliassen voor maken die eenvoudig uit te voeren zijn.

Ik heb een reeks aliassen gemaakt op basis van deze opdrachten die functionaliteit bieden die vergelijkbaar is met kubectx. Hier kun je ze in actie zien:

Houd er rekening mee dat aliassen fzf gebruiken om een interactieve, gratis opzoekinterface te bieden (zoals de interactieve modus van kubectx). Dit betekent dat je nodig hebt fzf installerenom deze aliassen te gebruiken.

Hier volgen de definities van aliassen zelf:

# Получить текущий контекст
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 deze aliassen in te stellen, moet u de bovenstaande definities aan uw bestand toevoegen ~/.bashrc of ~/.zshrc en start je shell opnieuw op.

Plugins gebruiken

Met Kubectl kunt u plug-ins laden die op dezelfde manier worden uitgevoerd als basisopdrachten. U kunt bijvoorbeeld de plug-in kubectl-foo installeren en uitvoeren door de opdracht uit te voeren kubectl foo.

Het zou handig zijn om de context en naamruimte op deze manier te wijzigen, bijvoorbeeld door uit te voeren kubectl ctx context veranderen en kubectl ns om de naamruimte te wijzigen.

Ik heb twee plug-ins geschreven die dit doen:

Het werk van plug-ins is gebaseerd op aliassen uit de vorige sectie.

Zo werken ze:

Merk op dat de plug-ins fzf gebruiken om een interactieve gratis zoekinterface te bieden (zoals de interactieve modus van kubectx). Dit betekent dat je nodig hebt fzf installerenom deze aliassen te gebruiken.

Om plug-ins te installeren, moet u shell-scripts met de naam downloaden kubectl-ctx и kubectl-ns naar elke map in uw PATH-variabele en maak ze uitvoerbaar met b.v. chmod +x. Direct hierna kunt u er gebruik van maken kubectl ctx и kubectl ns.

5. Verminder de invoer met automatische aliassen

Shell-aliassen zijn een goede manier om het typen te versnellen. Project kubectl-aliassen bevat ongeveer 800 snelkoppelingen voor standaard kubectl-opdrachten.

Je vraagt je misschien af: hoe onthoud je 800 aliassen? Maar je hoeft ze niet allemaal te onthouden, omdat ze zijn gebouwd volgens een eenvoudig schema, dat hieronder wordt gegeven:

Bijvoorbeeld:

kgpooyaml - kubectl krijgt peulen oyaml
ksysgsvcw — kubectl -n kube-systeem haal svc w op
ksysrmcm -kubectl -n kube-systeem rm cm
kgdepallsl - kubectl krijgt implementatie alle sl

Zoals u kunt zien, bestaan aliassen uit componenten, die elk een specifiek element van de kubectl-opdracht vertegenwoordigen. Elke alias kan één component hebben voor de basisopdracht, bewerking en bron, en meerdere componenten voor parameters. U "vult" deze componenten eenvoudigweg van links naar rechts in volgens het bovenstaande diagram.

Het huidige gedetailleerde diagram staat op GitHub. Daar kun je ook vinden volledige lijst met aliassen.

De alias kgpooyamlall is bijvoorbeeld gelijk aan de opdracht kubectl get pods -o yaml --all-namespaces.

De relatieve volgorde van de opties is niet belangrijk: commando kgpooyamlall is gelijk aan het commando kgpoalloyaml.

U hoeft niet alle componenten als aliassen te gebruiken. Bijvoorbeeld k, kg, klo, ksys, kgpo kan ook gebruikt worden. Bovendien kunt u aliassen en reguliere opdrachten of opties op de opdrachtregel combineren:

Bijvoorbeeld:

In plaats van kubectl proxy je kan schrijven k proxy.
In plaats van kubectl get roles je kan schrijven kg roles (er is momenteel geen alias voor de rolbron).
Om gegevens voor een specifieke pod op te halen, kunt u de opdracht gebruiken kgpo my-pod — kubectl get pod my-pod.

Houd er rekening mee dat voor sommige aliassen een opdrachtregelargument vereist is. Bijvoorbeeld alias kgpol middelen kubectl get pods -l. Keuze -l vereist een argument - een labelspecificatie. Als u een alias gebruikt, ziet deze er zo uit kgpol app=ui.

Omdat sommige aliassen argumenten vereisen, moeten de aliassen a, f en l als laatste worden gebruikt.

Over het algemeen kunt u, als u dit schema eenmaal onder de knie heeft, intuïtief aliassen afleiden van de opdrachten die u wilt uitvoeren, waardoor u veel typtijd kunt besparen.

installatie

Om kubectl-aliassen te installeren, moet u het bestand downloaden .kubectl_aliassen van GitHub en neem het op in het bestand ~/.bashrc of ~/.zshrc:

source ~/.kubectl_aliases

Automatische aanvulling

Zoals we eerder zeiden, voeg je vaak extra woorden toe aan een alias op de opdrachtregel. Bijvoorbeeld:

$ kgpooyaml test-pod-d4b77b989

Als u kubectl-opdrachtvoltooiing gebruikt, hebt u waarschijnlijk automatische aanvulling gebruikt voor zaken als bronnamen. Maar kan dit ook als er aliassen worden gebruikt?

Dit is een zeer belangrijke vraag, want als automatisch aanvullen niet werkt, verliest u een aantal voordelen van aliassen.

Het antwoord hangt af van welke shell je gebruikt:

Voor Zsh werkt aliasvoltooiing standaard.
Voor Bash is er helaas wat werk nodig om automatisch aanvullen te laten werken.

Automatisch aanvullen voor aliassen inschakelen in Bash

Het probleem met Bash is dat het probeert de alias te voltooien (elke keer dat je op Tab drukt), en niet de opdracht waarnaar de alias verwijst (zoals bijvoorbeeld Zsh doet). Omdat u niet voor alle 800 aliassen over voltooiingsscripts beschikt, werkt automatisch aanvullen niet.

Project compleet-alias biedt een algemene oplossing voor dit probleem. Het maakt verbinding met het voltooiingsmechanisme voor aliassen, breidt de alias intern uit tot een opdracht en retourneert voltooiingsopties voor de voltooide opdracht. Dit betekent dat de opvulling voor een alias zich precies hetzelfde gedraagt als voor een volledige opdracht.

Hieronder leg ik eerst uit hoe u complete-alias installeert en vervolgens hoe u deze configureert om voltooiing voor alle kubectl-aliassen in te schakelen.

Volledige alias installeren

Allereerst hangt de volledige alias af van bash-voltooiing. Voordat u complete-alias installeert, moet u er daarom voor zorgen dat bash-completion is geïnstalleerd. Er zijn eerder installatie-instructies gegeven voor Linux en MacOS.

Belangrijke opmerking voor MacOS-gebruikers: Net als het kubectl-script voor automatisch aanvullen werkt complete-alias niet met Bash 3.2, wat de standaard is op MacOS. In het bijzonder hangt de volledige alias af van bash-completion v2 (brew install bash-completion@2), waarvoor minimaal Bash 4.1 vereist is. Dit betekent dat om volledige alias op MacOS te gebruiken, je een nieuwere versie van Bash moet installeren.

U moet het script downloaden bash_completion.sh van GitHub-opslagplaats en neem het op in uw dossier ~/.bashrc:

source ~/bash_completion.sh

Na het opnieuw opstarten van de shell wordt de volledige alias volledig geïnstalleerd.

Automatische aanvulling inschakelen voor kubectl-aliassen

Technisch gezien biedt een complete alias een wrapper-functie _complete_alias. Deze functie controleert de alias en retourneert voltooiingstips voor de aliasopdracht.

Om een functie aan een specifieke alias te koppelen, moet je het ingebouwde Bash-mechanisme gebruiken compleet, installeren _complete_alias als een aliasvoltooiingsfunctie.

Laten we als voorbeeld de alias k nemen, wat staat voor de opdracht kubectl. installeren _complete_alias Als aanvullingsfunctie voor deze alias moet u de volgende opdracht uitvoeren:

$ complete -F _complete_alias k

Het resultaat hiervan is dat telkens wanneer u een alias k automatisch aanvult, de functie wordt aangeroepen _complete_alias, dat de alias controleert en voltooiingstips voor de opdracht retourneert kubectl.

Als tweede voorbeeld nemen we de alias kg, wat aangeeft kubectl get:

$ complete -F _complete_alias kg

Net als in het vorige voorbeeld krijgt u bij het automatisch aanvullen van kg dezelfde voltooiingstips als waarvoor u zou krijgen kubectl get.

Houd er rekening mee dat u een volledige alias kunt gebruiken voor elke alias op uw systeem.

Om automatische aanvulling voor alle kubectl-aliassen in te schakelen, moet u daarom de bovenstaande opdracht voor elk ervan uitvoeren. Het volgende fragment doet precies dit, op voorwaarde dat u kubectl-aliassen hebt ingesteld ~/.kubectl-aliases:

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

Dit stukje code moet in uw ~/.bashrc, start u de opdrachtshell opnieuw op en wordt automatisch aanvullen beschikbaar voor alle 800 kubectl-aliassen.

6. Kubectl uitbreiden met plug-ins

vanaf versie 1.12, kubectl ondersteunt plug-in mechanisme, waarmee u de functies ervan kunt uitbreiden met extra opdrachten.

Als je bekend bent met Mechanismen van Git-plug-ins, dan zijn kubectl-plug-ins op hetzelfde principe gebouwd.

In dit hoofdstuk bespreken we hoe u plug-ins installeert, waar u ze kunt vinden en hoe u uw eigen plug-ins kunt maken.

Plug-ins installeren

Kubectl-plug-ins worden gedistribueerd als eenvoudige uitvoerbare bestanden met de naam like kubectl-x. Voorvoegsel kubectl- is vereist, gevolgd door een nieuwe kubectl-subopdracht waarmee u de plug-in kunt aanroepen.

De hello-plug-in wordt bijvoorbeeld gedistribueerd als een bestand met de naam kubectl-hello.

Om de plug-in te installeren, moet u het bestand kopiëren kubectl-x naar een map in uw PATH en maak het uitvoerbaar, bijvoorbeeld met chmod +x. Direct hierna kun je de plugin aanroepen met kubectl x.

U kunt de volgende opdracht gebruiken om alle plug-ins weer te geven die momenteel op uw systeem zijn geïnstalleerd:

$ kubectl plugin list

Met deze opdracht worden ook waarschuwingen weergegeven als u meerdere plug-ins met dezelfde naam hebt, of als er een plug-insbestand is dat niet uitvoerbaar is.

Plug-ins zoeken en installeren met Krew

Kubectl-plug-ins kunnen worden gedeeld of hergebruikt zoals softwarepakketten. Maar waar vind je plug-ins die anderen hebben gedeeld?

Project Krew heeft tot doel een uniforme oplossing te bieden voor het delen, zoeken, installeren en beheren van kubectl-plug-ins. Het project noemt zichzelf een "pakketbeheerder voor kubectl-plug-ins" (Krew is vergelijkbaar met Brouwen).

Krew is een lijst met kubectl-plug-ins die u kunt selecteren en installeren. Tegelijkertijd is Krew ook een plug-in voor kubectl.

Dit betekent dat het installeren van Krew in essentie hetzelfde werkt als het installeren van elke andere kubectl-plug-in. Gedetailleerde instructies vindt u op met GitHub.

De belangrijkste Krew-commando's zijn:

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

Houd er rekening mee dat het installeren van plug-ins met behulp van Krew het installeren van plug-ins met behulp van de standaardmethode die hierboven wordt beschreven niet hindert.

Houd er rekening mee dat de opdracht kubectl krew list geeft alleen plug-ins weer die zijn geïnstalleerd met Krew, terwijl de opdracht kubectl plugin list geeft alle plug-ins weer, dat wil zeggen de plug-ins die met Krew zijn geïnstalleerd en de plug-ins die met andere methoden zijn geïnstalleerd.

Plug-ins elders vinden

Krew is een jong project dat zich momenteel in de ontwikkelingsfase bevindt lijst van slechts ongeveer 30 plug-ins. Als u niet kunt vinden wat u nodig heeft, kunt u elders plug-ins vinden, zoals GitHub.

Ik raad aan om de GitHub-sectie te bekijken kubectl-plug-ins. Daar vindt u tientallen beschikbare plug-ins die de moeite van het bekijken waard zijn.

Zelf plug-ins schrijven

je kunt jezelf plug-ins maken - Het is niet moeilijk. Je moet een uitvoerbaar bestand maken dat doet wat je nodig hebt, noem het maar zo kubectl-x en installeer zoals hierboven beschreven.

Het bestand kan een bash-script, een Python-script of een gecompileerde GO-applicatie zijn - het maakt niet uit. De enige voorwaarde is dat het direct in het besturingssysteem kan worden uitgevoerd.

Laten we nu een voorbeeldplug-in maken. In de vorige sectie hebt u de opdracht kubectl gebruikt om de containers voor elke pod weer te geven. Het is eenvoudig om van dit commando een plug-in te maken die u kunt aanroepen met b.v. kubectl img.

Maak een bestand kubectl-img de volgende inhoud:

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

Maak het bestand nu uitvoerbaar met chmod +x kubectl-img en verplaats het naar een willekeurige map in uw PATH. Direct hierna kun je de plugin gebruiken kubectl img.

Zoals gezegd kunnen kubectl-plug-ins in elke programmeer- of scripttaal worden geschreven. Als u shell-scripts gebruikt, heeft u het voordeel dat u kubectl eenvoudig vanuit de plug-in kunt aanroepen. U kunt echter complexere plug-ins in echte programmeertalen gebruiken Kubernetes-clientbibliotheek. Als u Go gebruikt, kunt u ook gebruiken cli-runtime-bibliotheek, die specifiek bestaat voor het schrijven van kubectl-plug-ins.

Hoe u uw plug-ins kunt delen

Als u denkt dat uw plug-ins nuttig kunnen zijn voor anderen, deel deze dan gerust op GitHub. Voeg ze zeker toe aan het onderwerp kubectl-plug-ins.

U kunt ook verzoeken dat uw plug-in wordt toegevoegd Krew-lijst. Instructies over hoe je dit moet doen zijn binnen GitHub-opslagplaatsen.

Voltooiing van de opdracht

Plug-ins ondersteunen momenteel geen automatische aanvulling. Dat wil zeggen dat u de volledige naam van de plug-in en de volledige namen van de argumenten moet invoeren.

De GitHub kubectl-repository voor deze functie heeft open verzoek. Het is dus mogelijk dat deze functie ergens in de toekomst wordt geïmplementeerd.

Succes!!!

Wat nog meer te lezen over het onderwerp:

Bron: www.habr.com

Hoe u kubectl effectiever kunt gebruiken: een gedetailleerde handleiding