🥇Com utilitzar kubectl de manera més eficaç: una guia detallada

Si treballeu amb Kubernetes, probablement kubectl és una de les utilitats que més feu servir. I sempre que passeu molt de temps treballant amb una eina concreta, val la pena estudiar-la bé i aprendre a utilitzar-la de manera eficaç.

Equip Kubernetes aaS de Mail.ru va traduir un article de Daniel Weibel en el qual trobareu consells i trucs per treballar eficaçment amb kubectl. També us ajudarà a obtenir una comprensió més profunda de Kubernetes.

Segons l'autor, l'objectiu de l'article és fer que el vostre treball diari amb Kubernetes no només sigui més eficient, sinó també més agradable!

Introducció: Què és kubectl

Abans que pugueu aprendre a utilitzar kubectl de manera més eficaç, heu d'obtenir una comprensió bàsica de què és i com funciona.

Des de la perspectiva de l'usuari, kubectl és un tauler de control que us permet realitzar operacions de Kubernetes.

Tècnicament parlant, kubectl és un client d'API de Kubernetes.

L'API de Kubernetes és una API REST HTTP. Aquesta API és la veritable interfície d'usuari de Kubernetes, a través de la qual es controla completament. Això vol dir que cada operació de Kubernetes s'exposa com a punt final de l'API i es pot fer amb una sol·licitud HTTP a aquest punt final.

Per tant, la tasca principal de kubectl és fer sol·licituds HTTP a l'API de Kubernetes:

Kubernetes és un sistema completament orientat als recursos. Això vol dir que manté l'estat intern dels recursos i totes les operacions de Kubernetes són operacions CRUD.

Tens el control total de Kubernetes gestionant aquests recursos i Kubernetes descobreix què ha de fer en funció de l'estat actual dels recursos. Per aquest motiu, la referència de l'API de Kubernetes s'organitza com una llista de tipus de recursos amb les seves operacions associades.

Vegem-ne un exemple.

Suposem que voleu crear un recurs ReplicaSet. Per fer-ho, descriu el ReplicaSet en un fitxer pel seu nom replicaset.yamli, a continuació, executeu l'ordre:

$ kubectl create -f replicaset.yaml

Això crearà un recurs ReplicaSet. Però què passa entre bastidors?

Kubernetes té una operació de creació de ReplicaSet. Com qualsevol altra operació, s'exposa com a punt final de l'API. El punt final de l'API específic per a aquesta operació és el següent:

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

Els punts finals de l'API per a totes les operacions de Kubernetes es poden trobar a Referència de l'API (incloent el punt final anterior). Per fer una sol·licitud real a un punt final, primer heu d'afegir l'URL del servidor de l'API als camins del punt final que s'enumeren a la referència de l'API.

Per tant, quan executeu l'ordre anterior, kubectl envia una sol·licitud HTTP POST al punt final de l'API anterior. La definició de ReplicaSet que heu proporcionat al fitxer replicaset.yaml, s'envia al cos de la sol·licitud.

Així és com funciona kubectl per a totes les ordres que interactuen amb el clúster de Kubernetes. En tots aquests casos, kubectl simplement fa sol·licituds HTTP als punts finals de l'API de Kubernetes adequats.

Tingueu en compte que podeu gestionar Kubernetes completament mitjançant una utilitat com ara curlenviant manualment sol·licituds HTTP a l'API de Kubernetes. Kubectl simplement facilita l'ús de l'API de Kubernetes.

Aquests són els conceptes bàsics del que és kubectl i com funciona. Però hi ha alguna cosa més sobre l'API de Kubernetes que tots els usuaris de kubectl haurien de conèixer. Fem una ullada ràpida al món interior de Kubernetes.

El món interior de Kubernetes

Kubernetes consta d'un conjunt de components independents que s'executen com a processos separats als nodes del clúster. Alguns components s'executen en nodes mestres, altres en nodes de treball, cada component realitza la seva pròpia tasca específica.

Aquests són els components més importants dels nodes principals:

Volta - emmagatzema definicions de recursos (normalment és etcd).
Servidor API — proporciona una API i gestiona l'emmagatzematge.
Gestor del controlador — Assegura que els estats dels recursos compleixen les especificacions.
Programador — programa pods als nodes de treball.

I aquí hi ha un component més important dels nodes de treball:

Kubelet — gestiona el llançament de contenidors al node de treball.

Per entendre com funcionen junts aquests components, mirem un exemple.

Suposem que acabeu de completar kubectl create -f replicaset.yaml, després del qual kubectl va fer una sol·licitud HTTP POST a Punt final de l'API ReplicaSet (passant la definició de recurs ReplicaSet).

Què està passant al clúster?

Després de fer kubectl create -f replicaset.yaml El servidor API emmagatzema la vostra definició de recurs ReplicaSet a l'emmagatzematge:
A continuació, s'inicia el controlador ReplicaSet al gestor del controlador, que gestiona la creació, modificació i supressió dels recursos de ReplicaSet:
El controlador ReplicaSet crea una definició de pod per a cada rèplica de ReplicaSet (segons la plantilla de pod a la definició de ReplicaSet) i les emmagatzema a l'emmagatzematge:
S'inicia el planificador, fent un seguiment dels pods que encara no s'han assignat a cap node de treball:
El planificador selecciona un node de treball adequat per a cada pod i afegeix aquesta informació a la definició de pod a la botiga:
Al node de treball al qual està assignat el pod, s'inicia Kubelet, fa un seguiment dels pods assignats a aquest node:
El Kubelet llegeix la definició del pod des de l'emmagatzematge i indica a un temps d'execució del contenidor, com ara Docker, que llanci contenidors al node:

A continuació es mostra una versió de text d'aquesta descripció.

La sol·licitud de l'API al punt final de creació de ReplicaSet la processa el servidor de l'API. El servidor de l'API autentica la sol·licitud i emmagatzema la definició del recurs ReplicaSet a l'emmagatzematge.

Aquest esdeveniment inicia el controlador ReplicaSet, que és un subprocés del gestor del controlador. El controlador ReplicaSet supervisa la creació, l'actualització i la supressió de recursos de ReplicaSet a la botiga i rep una notificació d'esdeveniment quan això succeeix.

La feina del controlador ReplicaSet és assegurar-se que existeix el nombre necessari de pods ReplicaSet. Al nostre exemple, encara no existeixen pods, de manera que el controlador ReplicaSet crea aquestes definicions de pods (segons la plantilla de pods a la definició de ReplicaSet) i les emmagatzema a l'emmagatzematge.

La creació de nous pods s'activa mitjançant un planificador que fa un seguiment de les definicions de pods que encara no estan programades per als nodes de treball. El planificador selecciona un node de treball adequat per a cada pod i actualitza les definicions de pod al dipòsit.

Tingueu en compte que fins aquest moment, no s'executava cap codi de càrrega de treball en cap lloc del clúster. Tot el que s'ha fet fins ara - es tracta de la creació i actualització de recursos al repositori del node mestre.

L'últim esdeveniment activa Kubelets, que supervisen els pods programats per als seus nodes de treball. El Kubelet del node de treball on s'instal·len els vostres pods de ReplicaSet ha d'indicar al temps d'execució del contenidor, com ara Docker, que baixi les imatges del contenidor necessàries i les executi.

En aquest punt, la vostra aplicació ReplicaSet finalment s'està executant!

Funció de l'API de Kubernetes

Com heu vist a l'exemple anterior, els components de Kubernetes (excepte el servidor de l'API i l'emmagatzematge) miren els canvis als recursos a l'emmagatzematge i canvien la informació sobre els recursos a l'emmagatzematge.

Per descomptat, aquests components no interactuen directament amb l'emmagatzematge, sinó només a través de l'API de Kubernetes.

Considereu els exemples següents:

El controlador ReplicaSet utilitza el punt final de l'API llista ReplicaSets amb paràmetre watch per supervisar els canvis als recursos de ReplicaSet.
El controlador ReplicaSet utilitza el punt final de l'API crear Pod (crear pod) per crear pods.
El programador utilitza el punt final de l'API patch pod (editar pod) per actualitzar els pods amb informació sobre el node de treball seleccionat.

Com podeu veure, aquesta és la mateixa API a la qual accedeix kubectl. L'ús de la mateixa API per a components interns i usuaris externs és un concepte fonamental en el disseny de Kubernetes.

Ara podem resumir com funciona Kubernetes:

L'estat de les botigues d'emmagatzematge, és a dir, els recursos de Kubernetes.
El servidor d'API proporciona una interfície per a l'emmagatzematge en forma de l'API de Kubernetes.
La resta de components i usuaris de Kubernetes llegeixen, observen i manipulen l'estat (recursos) de Kubernetes mitjançant l'API.

Conèixer aquests conceptes t'ajudarà a entendre millor kubectl i a treure'n el màxim profit.

Ara mirem alguns consells i trucs específics que us ajudaran a millorar la vostra productivitat amb kubectl.

1. Accelera l'entrada mitjançant la finalització d'ordres

Una de les tècniques més útils, però sovint passats per alt, per millorar el rendiment amb kubectl és la finalització d'ordres.

La finalització d'ordres us permet completar automàticament parts de les ordres kubectl mitjançant la tecla Tab. Això funciona per a subordres, opcions i arguments, inclòs alguna cosa tan complexa com els noms de recursos.

Vegeu com funciona la finalització de l'ordre de kubectl:

La finalització d'ordres funciona per a les shells Bash i Zsh.

Guia oficial conté instruccions detallades per configurar l'emplenament automàtic, però a continuació us proporcionarem un breu extracte.

Com funciona la finalització d'ordres

La finalització d'ordres és una característica de l'intèrpret d'ordres que funciona mitjançant un script de finalització. Un script d'extensió és un script d'intèrpret d'ordres que defineix el comportament d'una extensió per a una ordre específica.

Kubectl genera i genera automàticament scripts d'extensió per a Bash i Zsh mitjançant les ordres següents:

$ kubectl completion bash

$ kubectl completion zsh

En teoria, n'hi ha prou amb connectar la sortida d'aquestes ordres a l'intèrpret d'ordres adequat perquè kubectl pugui complementar les ordres.

A la pràctica, el mètode de connexió és diferent per a Bash (incloses les diferències entre Linux i MacOS) i Zsh. A continuació veurem totes aquestes opcions.

Bash a Linux

L'script de finalització de Bash depèn del paquet bash-completion, de manera que primer heu d'instal·lar-lo:

$ sudo apt-get install bash-completion

$ yum install bash-completion

Podeu provar que el paquet s'ha instal·lat correctament mitjançant l'ordre següent:

$ type _init_completion

Si això genera el codi de funció de l'intèrpret d'ordres, llavors bash-completion s'instal·la correctament. Si l'ordre dóna un error "No trobat", heu d'afegir la línia següent al fitxer ~ / .bashrc:

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

És necessari afegir aquesta línia al fitxer ~ / .bashrc o no depèn del gestor de paquets que heu utilitzat per instal·lar bash-completion. Això és necessari per a APT, però no per a YUM.

Després d'instal·lar bash-completion, heu de configurar-ho tot perquè l'script de finalització de kubectl estigui habilitat a totes les sessions de l'intèrpret d'ordres.

Una manera de fer-ho és afegir la línia següent al fitxer ~ / .bashrc:

source <(kubectl completion bash)

Una altra manera és afegir l'script d'extensió kubectl al directori /etc/bash_completion.d (creeu-lo si no existeix):

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

Tots els scripts de complements del catàleg /etc/bash_completion.d s'inclouen automàticament a bash-completion.

Les dues opcions són igualment aplicables.

Després de reiniciar l'intèrpret d'ordres, la finalització de l'ordre kubectl funcionarà.

Bash a MacOS

A MacOS, la configuració és una mica més complicada. El fet és que, de manera predeterminada, MacOS utilitza Bash versió 3.2, i l'script d'autocompleció de kubectl requereix una versió Bash d'almenys 4.1 i no funciona a Bash 3.2.

Hi ha problemes de llicència associats amb l'ús d'una versió obsoleta de Bash a MacOS. La versió 4 de Bash té la llicència GPLv3, que no és compatible amb Apple.

Per configurar l'emplenament automàtic de kubectl a MacOS, heu d'instal·lar una versió més recent de Bash. També podeu configurar el Bash actualitzat com a intèrpret d'ordres predeterminat, cosa que us estalviarà molts problemes en el futur. No és difícil, els detalls es donen a l'article "S'està actualitzant Bash a MacOS».

Abans de continuar, assegureu-vos que feu servir una versió recent de Bash (comproveu la sortida bash --version).

L'script de finalització de Bash varia segons el projecte finalització de bash, així que primer cal instal·lar-lo.

Podeu instal·lar bash-completion utilitzant homebrew:

$ brew install bash-completion@2

Aquí @2 significa bash-completion versió 2. Kubectl autocompletion requereix bash-completion v2 i bash-completion v2 requereix un mínim de la versió 4.1 de Bash.

Sortida d'ordres brew-install conté una secció Advertències, que especifica què cal afegir al fitxer ~/.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"

Tanmateix, us recomano que no afegiu aquestes línies ~/.bash_profilei en ~/.bashrc. En aquest cas, la compleció automàtica estarà disponible no només a les intèrprets d'ordres principals, sinó també a les intèrprets d'ordres secundaris.

Després de reiniciar l'intèrpret d'ordres, podeu verificar que la instal·lació és correcta mitjançant l'ordre següent:

$ type _init_completion

Si veieu una funció de shell a la sortida, tot està configurat correctament.

Ara hem d'assegurar-nos que l'emplenament automàtic de kubectl estigui habilitat a totes les sessions.

Una manera és afegir la línia següent al vostre ~/.bashrc:

source <(kubectl completion bash)

La segona manera és afegir un script d'autocompletar a la carpeta /usr/local/etc/bash_completion.d:

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

Aquest mètode només funcionarà si heu instal·lat bash-completion mitjançant Homebrew. En aquest cas, bash-completion carrega tots els scripts d'aquest directori.

Si heu instal·lat kubectl utilitzant Homebrew, aleshores no cal fer el pas anterior, ja que l'script d'autocompleció es col·locarà automàticament a la carpeta /usr/local/etc/bash_completion.d durant la instal·lació. En aquest cas, l'autocompleció de kubectl començarà a funcionar tan bon punt instal·leu bash-completion.

Com a resultat, totes aquestes opcions són equivalents.

Zsh

Els scripts d'autocompleció per a Zsh no requereixen cap dependència. Tot el que heu de fer és activar-los quan carregueu l'intèrpret d'ordres.

Podeu fer-ho afegint una línia al vostre ~/.zshrc dossier:

source <(kubectl completion zsh)

Si rebeu un error not found: compdef després de reiniciar el vostre shell, heu d'habilitar la funció integrada compdef. Podeu activar-lo afegint-lo al començament del fitxer ~/.zshrc el següent:

autoload -Uz compinit
compinit

2. Visualitza ràpidament les especificacions dels recursos

Quan creeu definicions de recursos YAML, heu de conèixer els camps i el seu significat per a aquests recursos. Un lloc per buscar aquesta informació és a la referència de l'API, que conté especificacions completes per a tots els recursos.

Tanmateix, canviar al navegador web cada vegada que necessiteu cercar alguna cosa és inconvenient. Per tant, kubectl proporciona l'ordre kubectl explain, que mostra les especificacions de tots els recursos directament al vostre terminal.

El format de l'ordre és el següent:

$ kubectl explain resource[.field]...

L'ordre mostrarà l'especificació del recurs o camp sol·licitat. La informació que es mostra és idèntica a la que conté el manual de l'API.

Per defecte kubectl explain mostra només el primer nivell de nidificació dels camps.

Mira com es veu pot ser aquí.

Podeu mostrar tot l'arbre si afegiu l'opció --recursive:

$ kubectl explain deployment.spec --recursive

Si no sabeu exactament quins recursos es necessiten, podeu mostrar-los tots amb l'ordre següent:

$ kubectl api-resources

Aquesta ordre mostra els noms dels recursos en plural, p. deployments en comptes de deployment. També mostra el nom curt, per exemple deploy, per aquells recursos que en tenen. No us preocupeu per aquestes diferències. Totes aquestes opcions de nom són equivalents per a kubectl. És a dir, podeu utilitzar qualsevol d'ells kubectl explain.

Totes les ordres següents són equivalents:

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

3. Utilitzeu un format de sortida de columna personalitzat

Format de sortida de comanda predeterminat 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

Aquest format és convenient, però conté una quantitat limitada d'informació. En comparació amb el format de definició de recursos complet, aquí només es mostren alguns camps.

En aquest cas, podeu utilitzar un format de sortida de columna personalitzat. Us permet determinar quines dades voleu sortir. Podeu mostrar qualsevol camp de recurs com a columna separada.

L'ús d'un format personalitzat es determina mitjançant les opcions:

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

Podeu definir cada columna de sortida com a parell <header>:<jsonpath>On <header> és el nom de la columna i <jsonpath> — una expressió que defineix un camp de recurs.

Vegem un exemple senzill:

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

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

La sortida conté una columna amb els noms dels pods.

L'expressió d'opció selecciona els noms dels pods del camp metadata.name. Això es deu al fet que el nom del pod es defineix al camp del nom del fill metadata a la descripció del recurs del pod. Es poden trobar més detalls a Guia de l'API o escriviu l'ordre kubectl explain pod.metadata.name.

Ara suposem que voleu afegir una columna addicional a la sortida, per exemple mostrant el node en què s'executa cada pod. Per fer-ho, només podeu afegir l'especificació de columna adequada a l'opció de columnes personalitzades:

$ 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

L'expressió selecciona el nom del node spec.nodeName — quan s'assigna un pod a un node, el seu nom s'escriu al camp spec.nodeName especificació de recursos de pod. Podeu trobar informació més detallada a la sortida kubectl explain pod.spec.nodeName.

Tingueu en compte que els camps de recursos de Kubernetes distingeixen entre majúscules i minúscules.

Podeu veure qualsevol camp de recurs com a columna. Només cal que reviseu l'especificació del recurs i proveu-ho amb els camps que vulgueu.

Però primer, mirem més de prop les expressions de selecció de camps.

Expressions JSONPath

Es basen les expressions per seleccionar camps de recursos JSONPath.

JSONPath és un llenguatge per recuperar dades dels documents JSON. La selecció d'un sol camp és el cas d'ús més senzill de JSONPath. Té molt més possibilitats, inclosos selectors, filtres, etc.

L'explicació de Kubectl admet un nombre limitat de funcions JSONPath. Les possibilitats i exemples del seu ús es descriuen a continuació:

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

L'operador [] és especialment important. Molts camps de recursos de Kubernetes són llistes i aquest operador us permet seleccionar membres d'aquestes llistes. Sovint s'utilitza amb un comodí com [*] per seleccionar tots els elements d'una llista.

Exemples d'aplicació

Les possibilitats d'utilitzar un format de sortida de columna personalitzat són infinites, ja que podeu mostrar qualsevol camp o combinació de camps de recursos a la sortida. Aquí teniu algunes aplicacions de mostra, però no dubteu a explorar-les vosaltres mateixos i trobar aplicacions que us funcionin.

Mostrant imatges de contenidors per a beines:

$ 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

Aquesta ordre mostra els noms de les imatges del contenidor per a cada pod.

Recordeu que un pod pot contenir diversos contenidors, llavors els noms de les imatges es mostraran en una línia, separats per comes.

Es mostren les zones de disponibilitat de nodes:
```
$ 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
```
Aquesta ordre és útil si el vostre clúster està allotjat en un núvol públic. Mostra la zona de disponibilitat per a cada node.

La zona de disponibilitat és un concepte de núvol que limita la zona de replicació a una regió geogràfica.

Les zones de disponibilitat per a cada node s'obtenen mitjançant una etiqueta especial: failure-domain.beta.kubernetes.io/zone. Si el clúster s'executa en un núvol públic, aquesta etiqueta es crea automàticament i s'omple amb els noms de les zones de disponibilitat per a cada node.

Les etiquetes no formen part de l'especificació de recursos de Kubernetes, de manera que no hi trobareu informació sobre elles Guia de l'API. Tanmateix, es poden veure (com qualsevol altra etiqueta) si sol·liciteu informació sobre els nodes en format YAML o JSON:
```
$ kubectl get nodes -o yaml
# или
$ kubectl get nodes -o json
```
Aquesta és una bona manera d'aprendre més sobre els recursos, a més d'aprendre les especificacions dels recursos.

4. Canvia fàcilment entre clústers i espais de noms

Quan kubectl fa una sol·licitud a l'API de Kubernetes, primer llegeix el fitxer kubeconfig per obtenir tots els paràmetres necessaris per a la connexió.

Per defecte, el fitxer kubeconfig és ~/.kube/config. Normalment, aquest fitxer es crea o s'actualitza mitjançant una ordre especial.

Quan treballeu amb diversos clústers, el vostre fitxer kubeconfig conté la configuració per connectar-vos a tots aquests clústers. Necessiteu una manera de dir a l'ordre kubectl amb quin clúster esteu treballant.

Dins d'un clúster, podeu crear diversos espais de noms, un tipus de clúster virtual dins d'un clúster físic. Kubectl també determina quin espai de noms utilitzar en funció del fitxer kubeconfig. Això vol dir que també necessiteu una manera de dir a l'ordre kubectl amb quin espai de noms heu de treballar.

En aquest capítol explicarem com funciona i com fer-lo funcionar de manera eficaç.

Tingueu en compte que és possible que tingueu diversos fitxers kubeconfig llistats a la variable d'entorn KUBECONFIG. En aquest cas, tots aquests fitxers es combinaran en una configuració comuna en temps d'execució. També podeu canviar el fitxer kubeconfig predeterminat executant kubectl amb el paràmetre --kubeconfig. Vegeu documentació oficial.

fitxers kubeconfig

Vegem què conté exactament el fitxer kubeconfig:

Com podeu veure, el fitxer kubeconfig conté un conjunt de contextos. El context consta de tres elements:

Clúster: URL de l'API del servidor del clúster.
Usuari - credencials d'autenticació d'usuari al clúster.
Espai de noms: l'espai de noms utilitzat en unir-se al clúster.

A la pràctica, sovint utilitzen un context per clúster al seu kubeconfig. Tanmateix, podeu tenir diversos contextos per clúster, diferenciats per usuari o espai de noms. No obstant això, aquesta configuració multicontext és poc freqüent, de manera que normalment hi ha un mapeig un a un entre clústers i contextos.

En un moment donat, un dels contextos és actual:

Quan kubectl llegeix un fitxer de configuració, sempre pren informació del context actual. A l'exemple anterior, kubectl es connectarà al clúster Hare.

En conseqüència, per canviar a un altre clúster, heu de canviar el context actual al fitxer kubeconfig:

Ara kubectl es connectarà al clúster Fox.

Per canviar a un espai de noms diferent al mateix clúster, heu de canviar el valor de l'element de l'espai de noms per al context actual:

A l'exemple anterior, kubectl utilitzarà l'espai de noms Prod del clúster Fox (anteriorment s'havia establert l'espai de noms de prova).

Tingueu en compte que kubectl també ofereix opcions --cluster, --user, --namespace и --context, que us permeten sobreescriure elements individuals i el propi context actual, independentment del que s'estableixi al kubeconfig. Mira kubectl options.

En teoria, podeu canviar manualment la configuració al kubeconfig. Però és inconvenient. Per simplificar aquestes operacions, hi ha diverses utilitats que permeten canviar els paràmetres automàticament.

Utilitzeu kubectx

Una utilitat molt popular per canviar entre clústers i espais de noms.

La utilitat proporciona ordres kubectx и kubens per canviar el context i l'espai de noms actuals respectivament.

Com s'ha esmentat, canviar el context actual significa canviar el clúster si només teniu un context per clúster.

Aquí teniu un exemple d'execució d'aquestes ordres:

Bàsicament, aquestes ordres simplement editen el fitxer kubeconfig tal com es descriu anteriorment.

instal · lar kubectx, seguiu les instruccions a Github.

Ambdues ordres admeten l'emplenament automàtic de noms de context i espai de noms, la qual cosa elimina la necessitat d'escriure'ls completament. Instruccions per configurar l'autocompleció aquí.

Una altra característica útil kubectx és mode interactiu. Funciona conjuntament amb la utilitat fzf, que s'ha d'instal·lar per separat. La instal·lació de fzf fa que el mode interactiu estigui disponible automàticament a kubectx. De manera interactiva, podeu seleccionar context i espai de noms mitjançant la interfície de cerca gratuïta interactiva proporcionada per fzf.

Utilitzant àlies de shell

No necessiteu eines separades per canviar el context actual i l'espai de noms perquè kubectl també proporciona ordres per a això. Sí, equip kubectl config proporciona subordres per editar fitxers kubeconfig.

Aquests són alguns d'ells:

kubectl config get-contexts: mostra tots els contextos;
kubectl config current-context: obtenir el context actual;
kubectl config use-context: canviar el context actual;
kubectl config set-context: Canvia l'element de context.

Tanmateix, utilitzar aquestes ordres directament no és molt convenient perquè són llargues. Podeu fer-los àlies de shell que siguin fàcils d'executar.

Vaig crear un conjunt d'àlies basats en aquestes ordres que proporcionen una funcionalitat similar a la de kubectx. Aquí els podeu veure en acció:

Tingueu en compte que els àlies utilitzen fzf per proporcionar una interfície de cerca lliure interactiva (com el mode interactiu de kubectx). Això vol dir que necessites instal·lar fzfper utilitzar aquests àlies.

Aquí hi ha les definicions dels àlies:

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

Per establir aquests àlies, heu d'afegir les definicions anteriors al vostre fitxer ~/.bashrc o ~/.zshrc i reinicieu el vostre shell.

Ús de connectors

Kubectl us permet carregar connectors que s'executen de la mateixa manera que les ordres bàsiques. Podeu, per exemple, instal·lar el connector kubectl-foo i executar-lo executant l'ordre kubectl foo.

Seria convenient canviar el context i l'espai de noms d'aquesta manera, per exemple executant kubectl ctx canviar de context i kubectl ns per canviar l'espai de noms.

He escrit dos connectors que fan això:

El treball dels connectors es basa en àlies de la secció anterior.

Així és com funcionen:

Tingueu en compte que els connectors utilitzen fzf per proporcionar una interfície de cerca gratuïta interactiva (com el mode interactiu de kubectx). Això vol dir que necessites instal·lar fzfper utilitzar aquests àlies.

Per instal·lar connectors, heu de descarregar els scripts de l'intèrpret d'ordres anomenats kubectl-ctx и kubectl-ns a qualsevol directori de la vostra variable PATH i feu-los executables amb, p. chmod +x. Immediatament després d'això podreu utilitzar kubectl ctx и kubectl ns.

5. Redueix l'entrada amb àlies automàtics

Els àlies de shell són una bona manera d'accelerar l'entrada. Projecte kubectl-àlies conté unes 800 dreceres per a ordres bàsiques de kubectl.

Potser us preguntareu: com recordeu els 800 àlies? Però no cal que els recordeu tots, perquè es construeixen segons un esquema senzill, que es mostra a continuació:

Per exemple:

kgpooyaml - kubectl obtenir pods oyaml
ksysgsvcw — kubectl -n kube-system get svc w
ksysrmcm -kubectl -n kube-system rm cm
kgdepallsl - kubectl obté el desplegament de tot sl

Com podeu veure, els àlies estan formats per components, cadascun dels quals representa un element específic de l'ordre kubectl. Cada àlies pot tenir un component per a l'ordre base, l'operació i el recurs, i diversos components per als paràmetres. Simplement "ompleu" aquests components d'esquerra a dreta segons el diagrama anterior.

El diagrama detallat actual és a GitHub. Allà també hi podeu trobar llista completa d'àlies.

Per exemple, l'àlies kgpooyamlall és equivalent a l'ordre kubectl get pods -o yaml --all-namespaces.

L'ordre relatiu de les opcions no és important: comanda kgpooyamlall és equivalent a l'ordre kgpoalloyaml.

No cal que utilitzeu tots els components com a àlies. Per exemple k, kg, klo, ksys, kgpo també es pot utilitzar. A més, podeu combinar àlies i ordres o opcions habituals a la línia d'ordres:

Per exemple:

En comptes de kubectl proxy pots escriure k proxy.
En comptes de kubectl get roles pots escriure kg roles (actualment no hi ha àlies per al recurs Roles).
Per obtenir dades per a un pod específic, podeu utilitzar l'ordre kgpo my-pod — kubectl get pod my-pod.

Tingueu en compte que alguns àlies requereixen un argument de línia d'ordres. Per exemple, àlies kgpol 1/2 kubectl get pods -l. Opció -l requereix un argument: una especificació d'etiqueta. Si feu servir un àlies semblarà kgpol app=ui.

Com que alguns àlies requereixen arguments, els àlies a, f i l s'han d'utilitzar en darrer lloc.

En general, un cop engegueu aquest esquema, podeu obtenir àlies de manera intuïtiva a partir de les ordres que voleu executar i estalviar molt de temps per escriure.

Instal·lació

Per instal·lar kubectl-aliases, heu de descarregar el fitxer .kubectl_aliases de GitHub i incloure'l al fitxer ~/.bashrc o ~/.zshrc:

source ~/.kubectl_aliases

Autocompleció

Com hem dit abans, sovint afegiu paraules addicionals a un àlies a la línia d'ordres. Per exemple:

$ kgpooyaml test-pod-d4b77b989

Si utilitzeu la finalització d'ordres kubectl, probablement heu utilitzat l'emplenament automàtic per a coses com ara els noms de recursos. Però això es pot fer quan s'utilitzen àlies?

Aquesta és una pregunta molt important perquè si la compleció automàtica no funciona, perdràs alguns dels avantatges dels àlies.

La resposta depèn del shell que utilitzeu:

Per a Zsh, la finalització d'àlies funciona fora de la caixa.
Per a Bash, malauradament, cal una mica de treball perquè funcioni l'autocompleció.

S'està habilitant l'emplenament automàtic per als àlies a Bash

El problema amb Bash és que intenta completar (cada cop que premeu Tab) l'àlies, no l'ordre a què fa referència l'àlies (com fa Zsh, per exemple). Com que no teniu scripts de finalització per als 800 àlies, la compleció automàtica no funciona.

Projecte àlies complet ofereix una solució general a aquest problema. Es connecta al mecanisme de finalització d'àlies, expandeix internament l'àlies a una ordre i retorna opcions de finalització per a l'ordre completada. Això significa que el farciment d'un àlies es comporta exactament igual que per a una ordre completa.

A continuació, primer explicaré com instal·lar l'àlies complet i després com configurar-lo per habilitar la finalització per a tots els àlies de kubectl.

S'està instal·lant l'àlies complet

En primer lloc, depèn de l'àlies complet finalització de bash. Per tant, abans d'instal·lar l'àlies complet, heu d'assegurar-vos que el bash-completion estigui instal·lat. Les instruccions d'instal·lació s'han proporcionat anteriorment per a Linux i MacOS.

Nota important per als usuaris de MacOS: Igual que l'script d'autocompleció de kubectl, l'àlies complet no funciona amb Bash 3.2, que és el predeterminat a MacOS. En particular, l'àlies complet depèn de bash-completion v2 (brew install bash-completion@2), que requereix almenys Bash 4.1. Això vol dir que per utilitzar l'àlies complet a MacOS, heu d'instal·lar una versió més nova de Bash.

Heu de descarregar l'script bash_completion.sh d' Repositori GitHub i incloure'l al vostre fitxer ~/.bashrc:

source ~/bash_completion.sh

Després de reiniciar l'intèrpret d'ordres, complete-alias s'instal·larà completament.

S'està habilitant l'emplenament automàtic per als àlies de kubectl

Tècnicament, l'àlies complet proporciona una funció d'embolcall _complete_alias. Aquesta funció verifica l'àlies i retorna pistes de finalització per a l'ordre d'àlies.

Per associar una funció amb un àlies específic, heu d'utilitzar el mecanisme Bash integrat completar, instal · lar _complete_alias com a funció de finalització d'àlies.

Com a exemple, prenem l'àlies k, que significa l'ordre kubectl. instal · lar _complete_alias Com a funció complementària d'aquest àlies, hauríeu d'executar l'ordre següent:

$ complete -F _complete_alias k

El resultat d'això és que sempre que completeu automàticament un àlies k, es crida la funció _complete_alias, que verifica l'àlies i retorna indicacions de finalització per a l'ordre kubectl.

Com a segon exemple, prenem l'àlies kg, que denota kubectl get:

$ complete -F _complete_alias kg

Igual que a l'exemple anterior, quan completeu kg automàticament, obteniu les mateixes pistes de finalització que obtindríeu per kubectl get.

Tingueu en compte que podeu utilitzar l'àlies complet per a qualsevol àlies del vostre sistema.

Per tant, per habilitar l'emplenament automàtic per a tots els àlies de kubectl, heu d'executar l'ordre anterior per a cadascun d'ells. El fragment següent fa exactament això, sempre que hàgiu establert kubectl-aliases a ~/.kubectl-aliases:

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

Aquest fragment de codi s'ha de col·locar al vostre ~/.bashrc, reinicieu l'intèrpret d'ordres i l'emplenament automàtic estarà disponible per als 800 àlies de kubectl.

6. Estenent kubectl amb connectors

A partir de versió 1.12, suporta kubectl mecanisme del complement, que us permeten ampliar les seves funcions amb ordres addicionals.

Si coneixeu Mecanismes del complement Git, llavors els connectors de kubectl es construeixen amb el mateix principi.

En aquest capítol, tractarem com instal·lar connectors, on trobar-los i com crear els vostres propis connectors.

Instal·lació de complements

Els connectors de Kubectl es distribueixen com a fitxers executables simples amb el nom com kubectl-x. Prefix kubectl- es requereix, seguit d'una nova subordre kubectl que us permet cridar el connector.

Per exemple, el connector hello es distribuirà com un fitxer anomenat kubectl-hello.

Per instal·lar el connector, heu de copiar el fitxer kubectl-x a qualsevol directori del vostre PATH i feu-lo executable, per exemple amb chmod +x. Immediatament després d'això, podeu trucar al connector amb kubectl x.

Podeu utilitzar l'ordre següent per llistar tots els connectors que estan instal·lats actualment al vostre sistema:

$ kubectl plugin list

Aquesta ordre també mostrarà avisos si teniu diversos connectors amb el mateix nom o si hi ha un fitxer de connectors que no és executable.

Cercar i instal·lar connectors amb Krew

Els connectors de Kubectl es poden compartir o reutilitzar com a paquets de programari. Però, on podeu trobar connectors que altres han compartit?

Projecte Krew té com a objectiu proporcionar una solució unificada per compartir, cercar, instal·lar i gestionar complements de kubectl. El projecte s'anomena "gestor de paquets per a connectors kubectl" (Krew és similar a infusió).

Krew és una llista de connectors de kubectl que podeu seleccionar i instal·lar. Al mateix temps, Krew també és un connector per a kubectl.

Això vol dir que la instal·lació de Krew funciona bàsicament com la instal·lació de qualsevol altre connector de kubectl. Podeu trobar instruccions detallades a Pàgina GitHub.

Les ordres de Krew més importants són:

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

Tingueu en compte que la instal·lació de connectors amb Krew no interfereix amb la instal·lació de connectors mitjançant el mètode estàndard descrit anteriorment.

Tingueu en compte que l'ordre kubectl krew list només mostra connectors que es van instal·lar amb Krew, mentre que l'ordre kubectl plugin list enumera tots els connectors, és a dir, els instal·lats amb Krew i els instal·lats per altres mètodes.

Trobar connectors en altres llocs

Krew és un projecte jove, actualment en el seu la llista només uns 30 connectors. Si no trobeu el que necessiteu, podeu trobar complements en altres llocs, com ara GitHub.

Recomano mirar la secció de GitHub kubectl-plugins. Hi trobareu desenes de connectors disponibles que val la pena comprovar.

Escrivint els vostres propis connectors

pots tu mateix crear connectors - No és difícil. Heu de crear un executable que faci el que necessiteu, nomeneu-lo com kubectl-x i instal·leu tal com es descriu anteriorment.

El fitxer pot ser un script bash, un script Python o una aplicació GO compilada; no importa. L'única condició és que es pugui executar directament al sistema operatiu.

Creem un complement d'exemple ara mateix. A la secció anterior, heu utilitzat l'ordre kubectl per llistar els contenidors de cada pod. És fàcil convertir aquesta ordre en un connector amb el qual podeu trucar, p. kubectl img.

Creeu un fitxer kubectl-img el contingut següent:

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

Ara feu que el fitxer sigui executable amb chmod +x kubectl-img i moveu-lo a qualsevol directori del vostre PATH. Immediatament després d'això, podeu utilitzar el connector kubectl img.

Com s'ha esmentat, els connectors de kubectl es poden escriure en qualsevol llenguatge de programació o script. Si utilitzeu scripts d'intèrpret d'ordres, l'avantatge de poder cridar fàcilment a kubectl des del connector. Tanmateix, podeu escriure connectors més complexos en llenguatges de programació reals Biblioteca client de Kubernetes. Si feu servir Go, també podeu utilitzar-lo biblioteca cli-runtime, que existeix específicament per escriure connectors kubectl.

Com compartir els vostres connectors

Si creieu que els vostres connectors podrien ser útils per a altres, no dubteu a compartir-los a GitHub. Assegureu-vos d'afegir-los al tema kubectl-plugins.

També podeu sol·licitar que s'afegeixi el vostre connector Llista de Krew. Les instruccions sobre com fer-ho es troben a Repositoris GitHub.

Finalització de comandaments

Els connectors no admeten actualment l'emplenament automàtic. És a dir, heu d'introduir el nom complet del connector i els noms complets dels arguments.

El dipòsit kubectl de GitHub per a aquesta funció té sol·licitud oberta. Per tant, és possible que aquesta funció s'implementarà en el futur.

Bona sort!!!

Què més llegir sobre el tema:

Font: www.habr.com

Com utilitzar kubectl de manera més eficaç: una guia detallada