🥇Como usar kubectl de forma máis eficaz: unha guía detallada

Se traballas con Kubernetes, entón kubectl é probablemente unha das utilidades que máis usas. E sempre que pasas moito tempo traballando cunha ferramenta en particular, paga a pena estudala ben e aprender a usala de forma eficaz.

Equipo Kubernetes aaS de Mail.ru traduciu un artigo de Daniel Weibel no que atoparás consellos e trucos para traballar eficazmente con kubectl. Tamén axudarache a coñecer máis a fondo Kubernetes.

Segundo o autor, o obxectivo do artigo é facer que o teu traballo diario con Kubernetes non só sexa máis eficiente, senón tamén máis agradable.

Introdución: que é kubectl

Antes de poder aprender a usar kubectl de forma máis eficaz, cómpre obter unha comprensión básica de que é e como funciona.

Desde a perspectiva do usuario, kubectl é un panel de control que che permite realizar operacións de Kubernetes.

Tecnicamente falando, kubectl é un cliente da API de Kubernetes.

A API de Kubernetes é unha API REST HTTP. Esta API é a verdadeira interface de usuario de Kubernetes, a través da cal se controla completamente. Isto significa que cada operación de Kubernetes exponse como un punto final da API e pódese facer cunha solicitude HTTP a ese punto final.

Polo tanto, o traballo principal de kubectl é facer solicitudes HTTP á API de Kubernetes:

Kubernetes é un sistema completamente orientado aos recursos. Isto significa que mantén o estado interno dos recursos e todas as operacións de Kubernetes son operacións CRUD.

Tes o control total de Kubernetes xestionando estes recursos e Kubernetes descobre que facer en función do estado actual dos recursos. Por este motivo, a referencia da API de Kubernetes organízase como unha lista de tipos de recursos coas súas operacións asociadas.

Vexamos un exemplo.

Digamos que quere crear un recurso ReplicaSet. Para iso, describe o ReplicaSet nun ficheiro polo seu nome replicaset.yaml, despois executa o comando:

$ kubectl create -f replicaset.yaml

Isto creará un recurso ReplicaSet. Pero que pasa detrás das escenas?

Kubernetes ten unha operación de creación de ReplicaSet. Como calquera outra operación, exponse como un punto final da API. O punto final específico da API para esta operación ten o seguinte aspecto:

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

Os puntos finais da API para todas as operacións de Kubernetes pódense atopar en Referencia da API (incluíndo o punto final anterior). Para facer unha solicitude real a un punto final, primeiro debes engadir o URL do servidor API ás rutas do punto final que aparecen na referencia da API.

Polo tanto, cando executas o comando anterior, kubectl envía unha solicitude HTTP POST ao punto final da API anterior. A definición de ReplicaSet que proporcionou no ficheiro replicaset.yaml, envíase no corpo da solicitude.

Así funciona kubectl para todos os comandos que interactúan co clúster de Kubernetes. En todos estes casos, kubectl simplemente fai solicitudes HTTP aos puntos finais da API de Kubernetes adecuados.

Ten en conta que podes xestionar completamente Kubernetes mediante unha utilidade como curlenviando manualmente solicitudes HTTP á API de Kubernetes. Kubectl simplemente facilita o uso da API de Kubernetes.

Estes son os conceptos básicos do que é kubectl e como funciona. Pero hai algo máis sobre a API de Kubernetes que todo usuario de kubectl debería saber. Imos dar unha rápida ollada ao mundo interior de Kubernetes.

O mundo interior de Kubernetes

Kubernetes consiste nun conxunto de compoñentes independentes que se executan como procesos separados nos nodos do clúster. Algúns compoñentes execútanse en nodos mestres, outros en nodos de traballo, cada compoñente realiza a súa propia tarefa específica.

Aquí están os compoñentes máis importantes dos nodos principais:

Bóveda - almacena definicións de recursos (normalmente é etcd).
Servidor API — proporciona unha API e xestiona o almacenamento.
Xestor controlador — Asegura que os estados dos recursos cumpren as especificacións.
Programador — programa pods en nodos de traballo.

E aquí está un compoñente máis importante nos nodos de traballo:

kubelet — xestiona o lanzamento de contedores no nodo de traballo.

Para comprender como funcionan estes compoñentes, vexamos un exemplo.

Supoñamos que acaba de rematar kubectl create -f replicaset.yaml, despois de que kubectl realizou unha solicitude HTTP POST a Punto final da API ReplicaSet (pasando a definición de recurso ReplicaSet).

Que está pasando no clúster?

Despois de facer kubectl create -f replicaset.yaml O servidor API almacena a súa definición de recurso ReplicaSet no almacenamento:
A continuación, lánzase o controlador ReplicaSet no xestor do controlador, que se encarga da creación, modificación e eliminación dos recursos de ReplicaSet:
O controlador ReplicaSet crea unha definición de pod para cada réplica de ReplicaSet (segundo o modelo de pod na definición de ReplicaSet) e gárdaas no almacenamento:
O programador lánzase, facendo un seguimento dos pods que aínda non foron asignados a ningún nodo traballador:
O programador selecciona un nodo de traballo axeitado para cada pod e engade esta información á definición do pod na tenda:
No nodo de traballo ao que está asignado o pod, lánzase Kubelet, fai un seguimento dos pods asignados a este nodo:
O Kubelet le a definición do pod desde o almacenamento e indica a un tempo de execución do contenedor, como Docker, para que lance contedores no nodo:

A continuación móstrase unha versión de texto desta descrición.

O servidor de API procesa a solicitude de API ao punto final de creación de ReplicaSet. O servidor API autentica a solicitude e almacena a definición do recurso ReplicaSet no almacenamento.

Este evento inicia o controlador ReplicaSet, que é un subproceso do xestor do controlador. O controlador ReplicaSet supervisa a creación, actualización e eliminación de recursos de ReplicaSet na tenda e recibe unha notificación de evento cando isto ocorre.

O traballo do controlador ReplicaSet é asegurarse de que exista o número necesario de pods ReplicaSet. No noso exemplo, aínda non existen pods, polo que o controlador ReplicaSet crea estas definicións de pod (segundo o modelo de pod na definición de ReplicaSet) e gárdaas no almacenamento.

A creación de novos pods é desencadeada por un programador que fai un seguimento das definicións de pods que aínda non están programadas para os nodos de traballo. O planificador selecciona un nodo de traballo axeitado para cada pod e actualiza as definicións de pod no repositorio.

Teña en conta que ata este momento, non se estaba executando ningún código de carga de traballo en ningún lugar do clúster. Todo o que se fixo ata agora - esta é a creación e actualización de recursos no repositorio no nodo mestre.

O último evento activa Kubelets, que supervisan os pods programados para os seus nodos de traballo. O Kubelet do nodo de traballo no que están instalados os pods de ReplicaSet debe indicarlle ao tempo de execución do contedor, como Docker, que descargue as imaxes do contedor necesarias e que as execute.

Neste punto, a súa aplicación ReplicaSet finalmente está a executarse.

Papel da API de Kubernetes

Como viches no exemplo anterior, os compoñentes de Kubernetes (excepto o servidor API e o almacenamento) observan cambios nos recursos almacenados e cambian a información sobre os recursos almacenados.

Por suposto, estes compoñentes non interactúan directamente co almacenamento, senón só a través da API de Kubernetes.

Considere os seguintes exemplos:

O controlador ReplicaSet usa o punto final da API lista ReplicaSets con parámetro watch para supervisar os cambios nos recursos de ReplicaSet.
O controlador ReplicaSet usa o punto final da API crear Pod (crear vaina) para crear vainas.
Scheduler usa o punto final da API vaina de parche (editar pod) para actualizar os pods con información sobre o nodo de traballo seleccionado.

Como podes ver, esta é a mesma API á que accede kubectl. Usar a mesma API para compoñentes internos e usuarios externos é un concepto fundamental no deseño de Kubernetes.

Agora podemos resumir como funciona Kubernetes:

O estado das tendas de almacenamento, é dicir, os recursos de Kubernetes.
O servidor API proporciona unha interface para o almacenamento en forma da API de Kubernetes.
Todos os demais compoñentes e usuarios de Kubernetes len, observan e manipulan o estado (recursos) de Kubernetes a través da API.

Coñecer estes conceptos axudarache a comprender mellor kubectl e sacarlle o máximo proveito.

Agora vexamos algúns consellos e trucos específicos que axudarán a mellorar a túa produtividade con kubectl.

1. Acelera a entrada usando a finalización do comando

Unha das técnicas máis útiles, pero que moitas veces se pasa por alto, para mellorar o rendemento con kubectl é a realización de comandos.

A finalización de comandos permítelle completar automaticamente partes dos comandos de kubectl usando a tecla Tab. Isto funciona para subcomandos, opcións e argumentos, incluíndo algo tan complexo como os nomes de recursos.

Vexa como funciona a finalización do comando kubectl:

A finalización de comandos funciona para as shells Bash e Zsh.

Guía oficial contén instrucións detalladas para configurar o autocompletado, pero a continuación proporcionaremos un pequeno extracto.

Como funciona a finalización de comandos

A finalización de comandos é unha función de shell que funciona mediante un script de finalización. Un script de extensión é un script de shell que define o comportamento dunha extensión para un comando específico.

Kubectl xera e saca automaticamente scripts de extensión para Bash e Zsh usando os seguintes comandos:

$ kubectl completion bash

Ou:

$ kubectl completion zsh

En teoría, abonda con conectar a saída destes comandos ao shell de comandos apropiado para que kubectl poida complementar os comandos.

Na práctica, o método de conexión é diferente para Bash (incluíndo as diferenzas entre Linux e MacOS) e Zsh. A continuación veremos todas estas opcións.

Bash en Linux

O script de finalización de Bash depende do paquete bash-completion, polo que primeiro debes instalalo:

$ sudo apt-get install bash-completion

Ou:

$ yum install bash-completion

Podes probar que o paquete está instalado correctamente usando o seguinte comando:

$ type _init_completion

Se isto sae o código da función de shell, entón bash-completion está instalado correctamente. Se o comando dá un erro "Non atopado", debes engadir a seguinte liña ao teu ficheiro ~ / .bashrc:

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

É necesario engadir esta liña ao ficheiro ~ / .bashrc ou non depende do xestor de paquetes que utilizaches para instalar bash-completion. Isto é necesario para APT, pero non para YUM.

Despois de instalar bash-completion, cómpre configurar todo para que o script de finalización de kubectl estea activado en todas as sesións de shell.

Unha forma de facelo é engadir a seguinte liña ao ficheiro ~ / .bashrc:

source <(kubectl completion bash)

Outra forma é engadir o script de extensión kubectl ao directorio /etc/bash_completion.d (creao se non existe):

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

Todos os scripts de complementos do catálogo /etc/bash_completion.d inclúense automaticamente en bash-completion.

Ambas opcións son igualmente aplicables.

Despois de reiniciar o shell, a finalización do comando de kubectl funcionará.

Bash en MacOS

En MacOS a configuración é un pouco máis complicada. O feito é que por defecto, MacOS usa a versión 3.2 de Bash e o script de autocompletado de kubectl require unha versión de Bash de polo menos 4.1 e non funciona en Bash 3.2.

Hai problemas de licenza asociados co uso dunha versión desactualizada de Bash en MacOS. A versión 4 de Bash ten licenza GPLv3, que non é compatible con Apple.

Para configurar o autocompletado de kubectl en MacOS, cómpre instalar unha versión máis recente de Bash. Tamén podes configurar o Bash actualizado como o teu shell predeterminado, o que che aforrará moitos problemas no futuro. Non é difícil, os detalles danse no artigo "Actualizando Bash en MacOS».

Antes de continuar, asegúrate de estar a usar unha versión recente de Bash (comproba a saída bash --version).

O script de finalización de Bash varía segundo o proxecto bash-completación, polo que primeiro debes instalalo.

Podes instalar bash-completion usando Homebrew:

$ brew install bash-completion@2

Aquí @2 significa bash-completion versión 2. Kubectl autocompletion require bash-completion v2 e bash-completion v2 require un mínimo de Bash versión 4.1.

Saída do comando brew-install contén unha sección Advertencias, que especifica o que hai que engadir ao ficheiro ~/.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"

Non obstante, recomendo que non engadas estas liñas ~/.bash_profile, e dentro ~/.bashrc. Neste caso, o autocompletado estará dispoñible non só no principal, senón tamén nos shells de comandos fillos.

Despois de reiniciar o shell de comandos, pode verificar que a instalación é correcta usando o seguinte comando:

$ type _init_completion

Se ves unha función de shell na saída, todo está configurado correctamente.

Agora temos que asegurarnos de que o autocompletado de kubectl estea activado en todas as sesións.

Unha forma é engadir a seguinte liña ao teu ~/.bashrc:

source <(kubectl completion bash)

A segunda forma é engadir un script de autocompletar ao cartafol /usr/local/etc/bash_completion.d:

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

Este método só funcionará se instalou bash-completion usando Homebrew. Neste caso, bash-completion carga todos os scripts deste directorio.

Se instalou kubectl usando Homebrew, entón non é necesario realizar o paso anterior, xa que o script de autocompletado colocarase automaticamente no cartafol /usr/local/etc/bash_completion.d durante a instalación. Neste caso, o autocompletado de kubectl comezará a funcionar en canto instales bash-completion.

Como resultado, todas estas opcións son equivalentes.

zsh

Os scripts de finalización Zsh non requiren ningunha dependencia. Todo o que tes que facer é activalos cando cargues o shell de comandos.

Podes facelo engadindo unha liña ao teu ~/.zshrc ficheiro:

source <(kubectl completion zsh)

Se recibe un erro not found: compdef despois de reiniciar o shell, cómpre activar a función integrada compdef. Podes activalo engadíndoo ao comezo do teu ficheiro ~/.zshrc seguinte:

autoload -Uz compinit
compinit

2. Consulta rapidamente as especificacións dos recursos

Cando crea definicións de recursos YAML, cómpre coñecer os campos e o seu significado para eses recursos. Un lugar para buscar esta información está na referencia da API, que contén especificacións completas para todos os recursos.

Non obstante, cambiar ao navegador web cada vez que necesites buscar algo é un inconveniente. Polo tanto, kubectl proporciona o comando kubectl explain, que mostra as especificacións de todos os recursos directamente no teu terminal.

O formato do comando é o seguinte:

$ kubectl explain resource[.field]...

O comando mostrará a especificación do recurso ou campo solicitado. A información que se mostra é idéntica á contida no manual da API.

Por defecto kubectl explain mostra só o primeiro nivel de anidación dos campos.

Mira como se ve pode estar aquí.

Podes mostrar a árbore enteira se engades a opción --recursive:

$ kubectl explain deployment.spec --recursive

Se non sabe exactamente que recursos son necesarios, pode mostralos todos co seguinte comando:

$ kubectl api-resources

Este comando amosa os nomes dos recursos en plural, p. ex. deployments en vez de deployment. Tamén mostra o nome curto, por exemplo deploy, por aqueles recursos que o teñan. Non te preocupes por estas diferenzas. Todas estas opcións de nomeamento son equivalentes para kubectl. É dicir, podes usar calquera deles para kubectl explain.

Todos os seguintes comandos son equivalentes:

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

3. Use un formato de saída de columna personalizado

Formato de saída do comando predeterminado 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

Este formato é conveniente, pero contén unha cantidade limitada de información. En comparación co formato de definición de recursos completo, aquí só se mostran algúns campos.

Neste caso, pode usar un formato de saída de columna personalizado. Permítelle determinar que datos quere saír. Pode mostrar calquera campo de recurso como unha columna separada.

O uso dun formato personalizado determínase mediante as opcións:

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

Pode definir cada columna de saída como un par <header>:<jsonpath>onde <header> é o nome da columna e <jsonpath> — unha expresión que define un campo de recurso.

Vexamos un exemplo sinxelo:

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

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

A saída contén unha columna cos nomes dos pods.

A expresión de opción selecciona os nomes dos pods do campo metadata.name. Isto débese a que o nome do pod está definido no campo do nome do fillo metadata na descrición do recurso do pod. Podes atopar máis detalles en Guía de API ou escriba o comando kubectl explain pod.metadata.name.

Agora digamos que quere engadir unha columna adicional á saída, por exemplo, mostrando o nodo no que se está a executar cada pod. Para iso, simplemente pode engadir a especificación de columna adecuada á opción de columnas personalizadas:

$ 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

A expresión selecciona o nome do nodo de spec.nodeName — cando se asigna un pod a un nodo, o seu nome escríbese no campo spec.nodeName especificación do recurso pod. Pódese atopar información máis detallada na saída kubectl explain pod.spec.nodeName.

Ten en conta que os campos de recursos de Kubernetes distinguen entre maiúsculas e minúsculas.

Podes ver calquera campo de recurso como unha columna. Só tes que revisar a especificación do recurso e probalo cos campos que che gusten.

Pero primeiro, vexamos máis de cerca as expresións de selección de campo.

Expresións JSONPath

As expresións para seleccionar campos de recursos baséanse JSONPath.

JSONPath é unha linguaxe para recuperar datos de documentos JSON. Seleccionar un só campo é o caso de uso máis sinxelo para JSONPath. Ten moito máis posibilidades, incluíndo selectores, filtros, etc.

Kubectl explica admite un número limitado de funcións JSONPath. A continuación descríbense as posibilidades e exemplos do seu uso:

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

O operador [] é especialmente importante. Moitos campos de recursos de Kubernetes son listas e este operador permíteche seleccionar membros desas listas. Adoita usarse cun comodín como [*] para seleccionar todos os elementos dunha lista.

Exemplos de aplicación

As posibilidades de usar un formato de saída de columna personalizado son infinitas, xa que pode mostrar calquera campo ou combinación de campos de recursos na saída. Aquí tes algunhas aplicacións de mostra, pero non dubides en exploralas ti mesmo e atopar aplicacións que che funcionen.

Mostrando imaxes de contedores para vainas:

$ 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

Este comando mostra os nomes das imaxes do recipiente para cada pod.

Lembra que un pod pode conter varios contedores, entón os nomes das imaxes mostraranse nunha liña, separados por comas.

Mostrando as zonas de dispoñibilidade de nodos:
```
$ 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
```
Este comando é útil se o seu clúster está aloxado nunha nube pública. Mostra a zona de dispoñibilidade para cada nodo.

A zona de dispoñibilidade é un concepto de nube que limita a zona de replicación a unha rexión xeográfica.

As zonas de dispoñibilidade para cada nodo obtéñense mediante unha etiqueta especial: failure-domain.beta.kubernetes.io/zone. Se o clúster está a executarse nunha nube pública, esta etiqueta créase automaticamente e énchese cos nomes das zonas de dispoñibilidade para cada nodo.

As etiquetas non forman parte da especificación de recursos de Kubernetes, polo que non atoparás información sobre elas Guía de API. Non obstante, pódense ver (como calquera outra etiqueta) se solicita información sobre os nós en formato YAML ou JSON:
```
$ kubectl get nodes -o yaml
# или
$ kubectl get nodes -o json
```
Esta é unha boa forma de aprender máis sobre os recursos, ademais de aprender as especificacións dos recursos.

4. Cambia facilmente entre clústeres e espazos de nomes

Cando kubectl fai unha solicitude á API de Kubernetes, primeiro le o ficheiro kubeconfig para obter todos os parámetros necesarios para a conexión.

Por defecto o ficheiro kubeconfig é ~/.kube/config. Normalmente, este ficheiro créase ou actualízase mediante un comando especial.

Cando traballas con varios clústeres, o teu ficheiro kubeconfig contén a configuración para conectarte a todos eses clústeres. Necesitas unha forma de dicir ao comando kubectl con que clúster estás a traballar.

Dentro dun clúster, pode crear varios espazos de nomes, un tipo de clúster virtual dentro dun clúster físico. Kubectl tamén determina que espazo de nomes usar en función do ficheiro kubeconfig. Isto significa que tamén precisa un xeito de dicirlle ao comando kubectl con que espazo de nomes traballar.

Neste capítulo explicaremos como funciona e como facelo funcionar de forma eficaz.

Teña en conta que pode ter varios ficheiros kubeconfig listados na variable de ambiente KUBECONFIG. Neste caso, todos estes ficheiros combinaranse nunha única configuración común no tempo de execución. Tamén pode cambiar o ficheiro kubeconfig predeterminado executando kubectl co parámetro --kubeconfig. Mirar documentación oficial.

ficheiros kubeconfig

Vexamos o que contén exactamente o ficheiro kubeconfig:

Como podes ver, o ficheiro kubeconfig contén un conxunto de contextos. O contexto consta de tres elementos:

Clúster: URL da API do servidor do clúster.
Usuario - credenciais de autenticación do usuario no clúster.
Espazo de nomes: o espazo de nomes usado ao unirse ao clúster.

Na práctica, adoitan usar un contexto por clúster no seu kubeconfig. Non obstante, pode ter varios contextos por clúster, diferenciados por usuario ou espazo de nomes. Non obstante, esta configuración multicontexto é pouco común, polo que adoita existir unha asignación un a un entre clústeres e contextos.

En cada momento, un dos contextos é actual:

Cando kubectl le un ficheiro de configuración, sempre toma información do contexto actual. No exemplo anterior, kubectl conectarase ao clúster Hare.

En consecuencia, para cambiar a outro clúster, cómpre cambiar o contexto actual no ficheiro kubeconfig:

Agora kubectl conectarase ao clúster Fox.

Para cambiar a un espazo de nomes diferente no mesmo clúster, cómpre cambiar o valor do elemento do espazo de nomes para o contexto actual:

No exemplo anterior, kubectl usará o espazo de nomes Prod do clúster Fox (anteriormente estaba definido o espazo de nomes Test).

Teña en conta que kubectl tamén ofrece opcións --cluster, --user, --namespace и --context, que che permiten sobrescribir elementos individuais e o propio contexto actual, independentemente do que estea configurado no kubeconfig. Mirar kubectl options.

En teoría, pode cambiar manualmente a configuración no kubeconfig. Pero é inconveniente. Para simplificar estas operacións, existen varias utilidades que permiten cambiar os parámetros automaticamente.

Use kubectx

Unha utilidade moi popular para cambiar entre clústeres e espazos de nomes.

A utilidade proporciona comandos kubectx и kubens para cambiar o contexto e o espazo de nomes actuais respectivamente.

Como se mencionou, cambiar o contexto actual significa cambiar o clúster se só tes un contexto por clúster.

Aquí tes un exemplo de execución destes comandos:

Esencialmente, estes comandos simplemente editan o ficheiro kubeconfig como se describe anteriormente.

instalar kubectx, siga as instrucións en Github.

Ambos os comandos admiten o autocompletado de nomes de contexto e espazo de nomes, o que elimina a necesidade de teclealos por completo. Instrucións para configurar o autocompletado aquí.

Outra característica útil kubectx é modo interactivo. Funciona en conxunto coa utilidade fzf, que debe instalarse por separado. A instalación de fzf fai que o modo interactivo estea dispoñible automaticamente en kubectx. De forma interactiva, pode seleccionar contexto e espazo de nomes a través da interface de busca gratuíta interactiva proporcionada por fzf.

Usando alias de shell

Non necesitas ferramentas separadas para cambiar o contexto e o espazo de nomes actuais porque kubectl tamén ofrece comandos para iso. Si, equipo kubectl config proporciona subcomandos para editar ficheiros kubeconfig.

Aquí tes algúns deles:

kubectl config get-contexts: mostrar todos os contextos;
kubectl config current-context: obter o contexto actual;
kubectl config use-context: cambiar o contexto actual;
kubectl config set-context: Cambia o elemento de contexto.

Non obstante, usar estes comandos directamente non é moi cómodo porque son longos. Podes facerlles alias de shell que sexan fáciles de executar.

Creei un conxunto de alias baseados nestes comandos que proporcionan unha funcionalidade similar a kubectx. Aquí podes velos en acción:

Teña en conta que os alias usan fzf para proporcionar unha interface de busca gratuíta e interactiva (como o modo interactivo de kubectx). Isto significa que necesitas instalar fzfpara usar estes alias.

Aquí están as definicións dos propios alias:

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

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

Para establecer estes alias, debes engadir as definicións anteriores ao teu ficheiro ~/.bashrc ou ~/.zshrc e reinicia o teu shell.

Usando complementos

Kubectl permítelle cargar complementos que se executan do mesmo xeito que os comandos básicos. Pode, por exemplo, instalar o complemento kubectl-foo e executalo executando o comando kubectl foo.

Sería conveniente cambiar o contexto e o espazo de nomes deste xeito, por exemplo executando kubectl ctx para cambiar o contexto e kubectl ns para cambiar o espazo de nomes.

Escribín dous complementos que fan isto:

O traballo dos complementos baséase nos alias da sección anterior.

Así é como funcionan:

Teña en conta que os complementos usan fzf para proporcionar unha interface de busca gratuíta e interactiva (como o modo interactivo de kubectx). Isto significa que necesitas instalar fzfpara usar estes alias.

Para instalar complementos, cómpre descargar os scripts de shell nomeados kubectl-ctx и kubectl-ns a calquera directorio da súa variable PATH e facelos executables con, p. chmod +x. Inmediatamente despois diso poderás usar kubectl ctx и kubectl ns.

5. Reducir a entrada con alias automáticos

Os alias de shell son unha boa forma de acelerar a escritura. Proxecto alias de kubectl contén uns 800 atallos para comandos básicos de kubectl.

Podes estar a se preguntar: como lembras os 800 alias? Pero non é necesario lembralos todos, porque están construídos segundo un esquema sinxelo, que se indica a continuación:

Por exemplo:

kgpooyaml - kubectl get pods oyaml
ksysgsvcw — kubectl -n kube-system obtén svc w
ksysrmcm -kubectl -n sistema kube rm cm
kgdepallsl - kubectl obtén a implementación de todos os sl

Como podes ver, os alias están formados por compoñentes, cada un dos cales representa un elemento específico do comando kubectl. Cada alias pode ter un compoñente para o comando base, a operación e o recurso, e varios compoñentes para os parámetros. Simplemente "pobo" estes compoñentes de esquerda a dereita segundo o diagrama anterior.

O diagrama detallado actual está en GitHub. Alí tamén podes atopar lista completa de alias.

Por exemplo, o alias kgpooyamlall é equivalente ao comando kubectl get pods -o yaml --all-namespaces.

A orde relativa das opcións non é importante: comando kgpooyamlall é equivalente ao comando kgpoalloyaml.

Non tes que usar todos os compoñentes como alias. Por exemplo k, kg, klo, ksys, kgpo tamén se pode usar. Ademais, pode combinar alias e comandos ou opcións habituais na liña de comandos:

Por exemplo:

Pola contra kubectl proxy podes escribir k proxy.
Pola contra kubectl get roles podes escribir kg roles (actualmente non hai un alias para o recurso Roles).
Para obter datos para un pod específico, pode usar o comando kgpo my-pod — kubectl get pod my-pod.

Teña en conta que algúns alias requiren un argumento de liña de comandos. Por exemplo, alias kgpol medios kubectl get pods -l. Opción -l require un argumento: unha especificación de etiqueta. Se usas un alias parecerá kgpol app=ui.

Debido a que algúns alias requiren argumentos, os alias a, f e l deben usarse en último lugar.

En xeral, unha vez que entendes este esquema, podes obter alias intuitivamente dos comandos que queres executar e aforrar moito tempo de escritura.

Instalación

Para instalar kubectl-aliases, cómpre descargar o ficheiro .kubectl_aliases desde GitHub e inclúao no ficheiro ~/.bashrc ou ~/.zshrc:

source ~/.kubectl_aliases

Autocompletado

Como dixemos antes, moitas veces engades palabras adicionais a un alias na liña de comandos. Por exemplo:

$ kgpooyaml test-pod-d4b77b989

Se usas a finalización de comandos de kubectl, probablemente utilizaches o autocompletado para cousas como os nomes de recursos. Pero pódese facer isto cando se usan alias?

Esta é unha pregunta moi importante porque se o autocompletado non funciona, perderás algúns dos beneficios dos alias.

A resposta depende do shell que esteas a usar:

Para Zsh, o complemento de alias funciona fóra da caixa.
Para Bash, desafortunadamente, é necesario traballar para que funcione o autocompletado.

Activando o autocompletado para os alias en Bash

O problema con Bash é que tenta completar (cada vez que premes Tab) o alias, non o comando ao que fai referencia o alias (como fai Zsh, por exemplo). Como non tes scripts de finalización para os 800 alias, o autocompletado non funciona.

Proxecto alias completo proporciona unha solución xeral a este problema. Conéctase ao mecanismo de finalización dos alias, expande internamente o alias a un comando e devolve opcións de finalización para o comando completado. Isto significa que o recheo dun alias comporta exactamente o mesmo que para un comando completo.

A continuación, explicarei primeiro como instalar complete-alias e despois como configuralo para habilitar a finalización de todos os alias de kubectl.

Instalación de alias completo

Primeiro de todo, depende o alias completo bash-completación. Polo tanto, antes de instalar complete-alias, cómpre asegurarse de que bash-completion está instalado. Previamente proporcionáronse instrucións de instalación para Linux e MacOS.

Nota importante para usuarios de MacOS: Do mesmo xeito que o script de autocompletado de kubectl, complete-alias non funciona con Bash 3.2, que é o predeterminado en MacOS. En particular, o alias completo depende de bash-completion v2 (brew install bash-completion@2), que require polo menos Bash 4.1. Isto significa que para usar o alias completo en MacOS, cómpre instalar unha versión máis recente de Bash.

Debe descargar o script bash_completion.sh de Repositorio GitHub e inclúao no seu ficheiro ~/.bashrc:

source ~/bash_completion.sh

Despois de reiniciar o shell, complete-alias instalarase completamente.

Activando o autocompletado para os alias de kubectl

Técnicamente o alias completo proporciona unha función de envoltura _complete_alias. Esta función verifica o alias e devolve as suxestións de finalización para o comando alias.

Para asociar unha función cun alias específico, cómpre utilizar o mecanismo Bash integrado completar, para instalar _complete_alias como función de finalización de alias.

Como exemplo, tomemos o alias k, que significa o comando kubectl. para instalar _complete_alias Como función complementaria para este alias, debes executar o seguinte comando:

$ complete -F _complete_alias k

O resultado é que cada vez que completa automaticamente un alias k, chámase á función _complete_alias, que verifica o alias e devolve pistas de finalización para o comando kubectl.

Como segundo exemplo, tomemos o alias kg, que denota kubectl get:

$ complete -F _complete_alias kg

Do mesmo xeito que no exemplo anterior, cando completas automaticamente kg, obtén as mesmas suxestións de finalización que obterías para kubectl get.

Teña en conta que pode usar complete-alias para calquera alias do seu sistema.

Polo tanto, para activar o autocompletado para todos os alias de kubectl, cómpre executar o comando anterior para cada un deles. O seguinte fragmento fai exactamente isto, sempre que teña definido kubectl-aliases ~/.kubectl-aliases:

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

Este anaco de código debe ser colocado no teu ~/.bashrc, reinicie o shell de comandos e o autocompletado estará dispoñible para os 800 alias de kubectl.

6. Estendendo kubectl con complementos

A partir de versión 1.12, soporta kubectl mecanismo de complementos, que lle permiten ampliar as súas funcións con comandos adicionais.

Se estás familiarizado Mecanismos do complemento Git, entón os complementos de kubectl están construídos co mesmo principio.

Neste capítulo, explicaremos como instalar complementos, onde atopalos e como crear os teus propios complementos.

Instalación de complementos

Os complementos de Kubectl distribúense como ficheiros executables simples co nome como kubectl-x. Prefixo kubectl- é necesario, seguido dun novo subcomando kubectl que che permite chamar ao complemento.

Por exemplo, o complemento ola distribuirase como un ficheiro chamado kubectl-hello.

Para instalar o complemento, cómpre copiar o ficheiro kubectl-x a calquera directorio do teu PATH e facelo executable, por exemplo con chmod +x. Inmediatamente despois podes chamar ao complemento con kubectl x.

Podes usar o seguinte comando para listar todos os complementos que están actualmente instalados no teu sistema:

$ kubectl plugin list

Este comando tamén mostrará avisos se tes varios complementos co mesmo nome ou se hai un ficheiro de complementos que non é executable.

Buscar e instalar complementos usando Krew

Os complementos de Kubectl pódense compartir ou reutilizar como paquetes de software. Pero onde podes atopar complementos que outros compartiron?

Proxecto Krew pretende proporcionar unha solución unificada para compartir, buscar, instalar e xestionar complementos de kubectl. O proxecto chámase "xestor de paquetes para complementos kubectl" (Krew é semellante a fermentación).

Krew é unha lista de complementos de kubectl que pode seleccionar e instalar. Ao mesmo tempo, Krew tamén é un complemento para kubectl.

Isto significa que instalar Krew funciona esencialmente como instalar calquera outro complemento de kubectl. Podes atopar instrucións detalladas en Páxina de GitHub.

Os comandos Krew máis importantes son:

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

Teña en conta que a instalación de complementos usando Krew non interfire coa instalación de complementos usando o método estándar descrito anteriormente.

Teña en conta que o comando kubectl krew list só mostra complementos que se instalaron mediante Krew, mentres que o comando kubectl plugin list enumera todos os complementos, é dicir, os instalados mediante Krew e os instalados por outros métodos.

Buscando complementos noutro lugar

Krew é un proxecto novo, actualmente no seu a lista só uns 30 complementos. Se non atopas o que necesitas, podes atopar complementos noutro lugar, como GitHub.

Recomendo mirar a sección de GitHub complementos kubectl. Alí atoparás ducias de complementos dispoñibles que paga a pena comprobar.

Escribindo os teus propios complementos

podes ti mesmo crear plugins - Non é difícil. Debes crear un executable que faga o que necesitas, ponlle o nome kubectl-x e instálelo como se describe anteriormente.

O ficheiro pode ser un script bash, un script Python ou unha aplicación GO compilada; non importa. A única condición é que se poida executar directamente no sistema operativo.

Imos crear un complemento de exemplo agora mesmo. Na sección anterior, utilizaches o comando kubectl para listar os contedores de cada pod. É doado converter este comando nun complemento ao que podes chamar, por exemplo. kubectl img.

Crear un ficheiro kubectl-img o seguinte contido:

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

Agora fai que o ficheiro sexa executable con chmod +x kubectl-img e móveo a calquera directorio do seu PATH. Inmediatamente despois diso podes usar o complemento kubectl img.

Como se mencionou, os complementos de kubectl pódense escribir en calquera linguaxe de programación ou script. Se está a usar scripts de shell, a vantaxe de poder chamar facilmente a kubectl desde o complemento. Non obstante, podes escribir complementos máis complexos en linguaxes de programación reais usando Biblioteca cliente de Kubernetes. Se estás a usar Go, tamén podes usar biblioteca cli-runtime, que existe especificamente para escribir complementos de kubectl.

Como compartir os teus complementos

Se pensas que os teus complementos poden ser útiles para outros, non dubides en compartilos en GitHub. Asegúrate de engadilos ao tema complementos kubectl.

Tamén podes solicitar que se engada o teu complemento Lista de Krew. As instrucións sobre como facelo están en Repositorios GitHub.

Finalización do comando

Os complementos non admiten actualmente o autocompletado. É dicir, debes introducir o nome completo do complemento e os nomes completos dos argumentos.

O repositorio kubectl de GitHub para esta función ten solicitude aberta. Polo tanto, é posible que esta función se implemente nalgún momento no futuro.

Moita sorte!!!

Que máis ler sobre o tema:

Fonte: www.habr.com

Como usar kubectl de forma máis eficaz: unha guía detallada