🥇Como usar o kubectl de forma mais eficaz: um guia detalhado

Se você trabalha com Kubernetes, então kubectl é provavelmente um dos utilitários que você mais usa. E sempre que você passa muito tempo trabalhando com uma determinada ferramenta, vale a pena estudá-la bem e aprender como utilizá-la de forma eficaz.

Equipe Kubernetes aaS de Mail.ru traduziu um artigo de Daniel Weibel no qual você encontrará dicas e truques para trabalhar de forma eficaz com o kubectl. Também o ajudará a obter uma compreensão mais profunda do Kubernetes.

Segundo o autor, o objetivo do artigo é tornar o seu trabalho diário com o Kubernetes não só mais eficiente, mas também mais agradável!

Introdução: O que é kubectl

Antes de aprender a usar o kubectl de maneira mais eficaz, você precisa obter uma compreensão básica do que ele é e como funciona.

Da perspectiva do usuário, kubectl é um painel de controle que permite realizar operações do Kubernetes.

Tecnicamente falando, kubectl é um cliente API do Kubernetes.

A API Kubernetes é uma API HTTP REST. Esta API é a verdadeira interface de usuário do Kubernetes, por meio da qual é totalmente controlada. Isso significa que cada operação do Kubernetes é exposta como um endpoint de API e pode ser feita com uma solicitação HTTP para esse endpoint.

Portanto, a principal tarefa do kubectl é fazer solicitações HTTP para a API Kubernetes:

Kubernetes é um sistema totalmente orientado a recursos. Isso significa que ele mantém o estado interno dos recursos e todas as operações do Kubernetes são operações CRUD.

Você tem controle total do Kubernetes gerenciando esses recursos, e o Kubernetes descobre o que fazer com base no estado atual dos recursos. Por esse motivo, a referência da API Kubernetes é organizada como uma lista de tipos de recursos com suas operações associadas.

Vejamos um exemplo.

Digamos que você queira criar um recurso ReplicaSet. Para fazer isso, você descreve o ReplicaSet em um arquivo por nome replicaset.yamle execute o comando:

$ kubectl create -f replicaset.yaml

Isso criará um recurso ReplicaSet. Mas o que acontece nos bastidores?

Kubernetes possui uma operação de criação de ReplicaSet. Como qualquer outra operação, ela é exposta como um endpoint de API. O endpoint de API específico para esta operação é assim:

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

Os endpoints da API para todas as operações do Kubernetes podem ser encontrados em Referência da API (incluindo o ponto final acima). Para fazer uma solicitação real a um terminal, primeiro você deve adicionar a URL do servidor API aos caminhos do terminal listados na referência da API.

Portanto, quando você executa o comando acima, kubectl envia uma solicitação HTTP POST para o endpoint da API acima. A definição de ReplicaSet fornecida no arquivo replicaset.yaml, é enviado no corpo da solicitação.

É assim que o kubectl funciona para todos os comandos que interagem com o cluster Kubernetes. Em todos esses casos, o kubectl simplesmente faz solicitações HTTP para os endpoints apropriados da API do Kubernetes.

Observe que você pode gerenciar totalmente o Kubernetes usando um utilitário como curlenviando manualmente solicitações HTTP para a API Kubernetes. Kubectl simplesmente facilita o uso da API Kubernetes.

Este é o básico do que é kubectl e como funciona. Mas há algo mais sobre a API Kubernetes que todo usuário do kubectl deve saber. Vamos dar uma olhada rápida no mundo interior do Kubernetes.

O mundo interior do Kubernetes

Kubernetes consiste em um conjunto de componentes independentes que são executados como processos separados em nós de cluster. Alguns componentes são executados em nós mestres, outros em nós trabalhadores, cada componente executando sua tarefa específica.

Aqui estão os componentes mais importantes nos nós principais:

Armazenamento - armazena definições de recursos (geralmente é etcd).
Servidor API — fornece uma API e gerencia o armazenamento.
Gerente de Controlador — Garante que os status dos recursos estejam em conformidade com as especificações.
Agendador — agenda pods em nós de trabalho.

E aqui está um componente mais importante nos nós de trabalho:

KubeletGenericName — gerencia o lançamento de contêineres no nó de trabalho.

Para entender como esses componentes funcionam juntos, vejamos um exemplo.

Vamos supor que você acabou de concluir kubectl create -f replicaset.yaml, após o qual o kubectl fez uma solicitação HTTP POST para Ponto de extremidade da API ReplicaSet (passando a definição de recurso ReplicaSet).

O que está acontecendo no cluster?

Depois de fazer kubectl create -f replicaset.yaml O servidor API armazena sua definição de recurso ReplicaSet no armazenamento:
Em seguida, o controlador ReplicaSet é iniciado no gerenciador do controlador, que trata da criação, modificação e exclusão de recursos ReplicaSet:
O controlador ReplicaSet cria uma definição de pod para cada réplica do ReplicaSet (de acordo com o modelo de pod na definição do ReplicaSet) e as armazena no armazenamento:
O planejador é iniciado, rastreando pods que ainda não foram designados a nenhum nó do trabalhador:
O planejador seleciona um nó de trabalho adequado para cada pod e adiciona essas informações à definição do pod no armazenamento:
No nó de trabalho ao qual o pod está atribuído, o Kubelet é iniciado e rastreia os pods atribuídos a este nó:
O Kubelet lê a definição do pod do armazenamento e instrui um tempo de execução de contêiner, como o Docker, para iniciar contêineres no nó:

Abaixo está uma versão em texto desta descrição.

A solicitação de API para o endpoint de criação do ReplicaSet é processada pelo servidor API. O servidor API autentica a solicitação e armazena a definição de recurso ReplicaSet no armazenamento.

Este evento inicia o controlador ReplicaSet, que é um subprocesso do gerenciador do controlador. O controlador ReplicaSet monitora a criação, atualização e exclusão de recursos ReplicaSet no armazenamento e recebe uma notificação de evento quando isso ocorre.

A tarefa do controlador ReplicaSet é garantir que exista o número necessário de pods ReplicaSet. Em nosso exemplo, ainda não existem pods, portanto, o controlador ReplicaSet cria essas definições de pod (de acordo com o modelo de pod na definição ReplicaSet) e as armazena no armazenamento.

A criação de novos pods é acionada por um planejador que controla as definições de pod que ainda não estão planejadas para nós do trabalhador. O planejador seleciona um nó de trabalho adequado para cada pod e atualiza as definições de pod no repositório.

Observe que até esse ponto, nenhum código de carga de trabalho estava em execução em qualquer lugar do cluster. Tudo o que foi feito até agora - esta é a criação e atualização de recursos no repositório do nó mestre.

O último evento aciona Kubelets, que monitoram os pods agendados para seus nós de trabalho. O Kubelet do nó do trabalhador no qual seus pods ReplicaSet estão instalados deve instruir o tempo de execução do contêiner, como o Docker, para fazer download das imagens de contêiner necessárias e executá-las.

Neste ponto, seu aplicativo ReplicaSet está finalmente em execução!

Função da API Kubernetes

Como você viu no exemplo anterior, os componentes do Kubernetes (exceto o servidor API e o armazenamento) observam alterações nos recursos no armazenamento e alteram informações sobre os recursos no armazenamento.

É claro que esses componentes não interagem diretamente com o armazenamento, mas apenas por meio da API Kubernetes.

Considere os seguintes exemplos:

O controlador ReplicaSet usa o endpoint da API listar conjuntos de réplicas com parâmetro watch para monitorar alterações nos recursos do ReplicaSet.
O controlador ReplicaSet usa o endpoint da API criar pod (criar pod) para criar pods.
O agendador usa o endpoint da API módulo de patch (editar pod) para atualizar pods com informações sobre o nó do trabalhador selecionado.

Como você pode ver, esta é a mesma API que o kubectl acessa. Usar a mesma API para componentes internos e usuários externos é um conceito fundamental no design do Kubernetes.

Agora podemos resumir como funciona o Kubernetes:

O armazenamento armazena o estado, ou seja, recursos do Kubernetes.
O servidor API fornece uma interface para o armazenamento na forma da API Kubernetes.
Todos os outros componentes e usuários do Kubernetes leem, observam e manipulam o estado (recursos) do Kubernetes por meio da API.

Conhecer esses conceitos ajudará você a entender melhor o kubectl e a tirar o máximo proveito dele.

Agora vamos dar uma olhada em algumas dicas e truques específicos que ajudarão a melhorar sua produtividade com o kubectl.

1. Acelere a entrada usando a conclusão de comandos

Uma das técnicas mais úteis, mas muitas vezes esquecidas, para melhorar o desempenho com kubectl é a conclusão de comandos.

A conclusão de comandos permite concluir automaticamente partes dos comandos kubectl usando a tecla Tab. Isso funciona para subcomandos, opções e argumentos, incluindo algo tão complexo como nomes de recursos.

Veja como funciona a conclusão do comando kubectl:

A conclusão do comando funciona para shells Bash e Zsh.

Guia Oficial contém instruções detalhadas para configurar o preenchimento automático, mas a seguir forneceremos um pequeno trecho.

Como funciona a conclusão do comando

A conclusão de comando é um recurso de shell que funciona usando um script de conclusão. Um script de extensão é um script de shell que define o comportamento de uma extensão para um comando específico.

Kubectl gera e gera automaticamente scripts de extensão para Bash e Zsh usando os seguintes comandos:

$ kubectl completion bash

Или:

$ kubectl completion zsh

Em teoria, basta conectar a saída desses comandos ao shell de comando apropriado para que o kubectl possa complementar os comandos.

Na prática, o método de conexão é diferente para Bash (incluindo diferenças entre Linux e MacOS) e Zsh. A seguir veremos todas essas opções.

Bash no Linux

O script de conclusão do Bash depende do pacote bash-completion, então você precisa instalá-lo primeiro:

$ sudo apt-get install bash-completion

Или:

$ yum install bash-completion

Você pode testar se o pacote foi instalado com sucesso usando o seguinte comando:

$ type _init_completion

Se isso gerar o código de função do shell, o bash-completion será instalado corretamente. Se o comando apresentar um erro "Não encontrado", você precisará adicionar a seguinte linha ao seu arquivo ~ / .bashrc:

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

É necessário adicionar esta linha ao arquivo ~ / .bashrc ou não depende do gerenciador de pacotes que você usou para instalar o bash-completion. Isto é necessário para o APT, mas não para o YUM.

Depois de instalar o bash-completion, você precisa configurar tudo para que o script de conclusão kubectl seja habilitado em todas as sessões do shell.

Uma maneira de fazer isso é adicionar a seguinte linha ao arquivo ~ / .bashrc:

source <(kubectl completion bash)

Outra maneira é adicionar o script de extensão kubectl ao diretório /etc/bash_completion.d (crie-o se não existir):

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

Todos os scripts complementares no catálogo /etc/bash_completion.d são incluídos automaticamente na conclusão do bash.

Ambas as opções são igualmente aplicáveis.

Depois de reiniciar o shell, a conclusão do comando kubectl funcionará.

Bash no MacOS

No MacOS a configuração é um pouco mais complicada. O fato é que, por padrão, o MacOS usa o Bash versão 3.2, e o script de preenchimento automático kubectl requer uma versão Bash de pelo menos 4.1 e não funciona no Bash 3.2.

Existem problemas de licenciamento associados ao uso de uma versão desatualizada do Bash no MacOS. A versão 4 do Bash é licenciada sob GPLv3, que não é suportada pela Apple.

Para configurar o preenchimento automático do kubectl no MacOS, você precisa instalar uma versão mais recente do Bash. Você também pode definir o Bash atualizado como seu shell padrão, o que evitará muitos problemas no futuro. Não é difícil, os detalhes são fornecidos no artigo “Atualizando Bash no MacOS".

Antes de continuar, certifique-se de estar usando uma versão recente do Bash (verifique a saída bash --version).

O script de conclusão do Bash varia de acordo com o projeto conclusão bash, então você precisa instalá-lo primeiro.

Você pode instalar o bash-completion usando Homebrew:

$ brew install bash-completion@2

é @2 significa bash-completion versão 2. kubectl autocompletion requer bash-completion v2, e bash-completion v2 requer no mínimo Bash versão 4.1.

Saída de comando brew-install contém uma seção Advertências, que especifica o que precisa ser adicionado ao arquivo ~/.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"

No entanto, recomendo adicionar estas linhas para não ~/.bash_profilee em ~/.bashrc. Nesse caso, o preenchimento automático estará disponível não apenas no shell de comando principal, mas também no shell de comando filho.

Após reiniciar o shell de comando, você pode verificar se a instalação está correta usando o seguinte comando:

$ type _init_completion

Se você vir uma função shell na saída, tudo está configurado corretamente.

Agora precisamos garantir que o preenchimento automático do kubectl esteja habilitado em todas as sessões.

Uma maneira é adicionar a seguinte linha ao seu ~/.bashrc:

source <(kubectl completion bash)

A segunda maneira é adicionar um script de preenchimento automático à pasta /usr/local/etc/bash_completion.d:

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

Este método só funcionará se você instalou o bash-completion usando o Homebrew. Nesse caso, o bash-completion carrega todos os scripts deste diretório.

Se você instalou kubectl usando Homebrew, então não há necessidade de realizar a etapa anterior, pois o script de preenchimento automático será colocado automaticamente na pasta /usr/local/etc/bash_completion.d Durante a instalação. Nesse caso, o preenchimento automático do kubectl começará a funcionar assim que você instalar o bash-completion.

Como resultado, todas estas opções são equivalentes.

Zsh

Os scripts de preenchimento automático para Zsh não requerem nenhuma dependência. Tudo que você precisa fazer é ativá-los ao carregar o shell de comando.

Você pode fazer isso adicionando uma linha ao seu ~/.zshrc arquivo:

source <(kubectl completion zsh)

Se você receber um erro not found: compdef depois de reiniciar seu shell, você precisa habilitar a função interna compdef. Você pode habilitá-lo adicionando-o ao início do seu arquivo ~/.zshrc O seguinte:

autoload -Uz compinit
compinit

2. Visualize rapidamente as especificações dos recursos

Ao criar definições de recursos YAML, você precisa conhecer os campos e seu significado para esses recursos. Um local para procurar essas informações é na referência da API, que contém especificações completas para todos os recursos.

No entanto, mudar para o navegador sempre que precisar pesquisar algo é inconveniente. Portanto kubectl fornece o comando kubectl explain, que mostra as especificações de todos os recursos diretamente no seu terminal.

O formato do comando é o seguinte:

$ kubectl explain resource[.field]...

O comando produzirá a especificação do recurso ou campo solicitado. As informações exibidas são idênticas às contidas no manual da API.

Por padrão kubectl explain mostra apenas o primeiro nível de aninhamento de campos.

Veja como é Você pode, então,.

Você pode exibir a árvore inteira se adicionar a opção --recursive:

$ kubectl explain deployment.spec --recursive

Se você não sabe exatamente quais recursos são necessários, você pode exibi-los todos com o seguinte comando:

$ kubectl api-resources

Este comando exibe nomes de recursos no plural, por ex. deployments ao invés de deployment. Ele também exibe o nome abreviado, por exemplo deploy, para os recursos que o possuem. Não se preocupe com essas diferenças. Todas essas opções de nomenclatura são equivalentes para kubectl. Ou seja, você pode usar qualquer um deles para kubectl explain.

Todos os comandos a seguir são equivalentes:

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

3. Use um formato de saída de coluna personalizado

Formato de saída de comando padrão 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, mas contém uma quantidade limitada de informações. Em comparação com o formato completo de definição de recursos, apenas alguns campos são exibidos aqui.

Nesse caso, você pode usar um formato de saída de coluna personalizado. Ele permite que você determine quais dados serão gerados. Você pode exibir qualquer campo de recurso como uma coluna separada.

O uso de um formato personalizado é determinado usando as opções:

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

Você pode definir cada coluna de saída como um par <header>:<jsonpath>Onde <header> é o nome da coluna e <jsonpath> — uma expressão que define um campo de recurso.

Vejamos um exemplo simples:

$ 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ém uma coluna com os nomes dos pods.

A expressão de opção seleciona os nomes dos pods no campo metadata.name. Isso ocorre porque o nome do pod é definido no campo de nome filho metadata na descrição do recurso do pod. Mais detalhes podem ser encontrados em Guia de API ou digite o comando kubectl explain pod.metadata.name.

Agora, digamos que você queira adicionar uma coluna extra à saída, por exemplo, mostrando o nó em que cada pod está sendo executado. Para fazer isso, você pode simplesmente adicionar a especificação de coluna apropriada à opção de colunas 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 expressão seleciona o nome do nó de spec.nodeName — quando um pod é atribuído a um nó, seu nome é escrito no campo spec.nodeName especificação de recurso de pod. Informações mais detalhadas podem ser encontradas na saída kubectl explain pod.spec.nodeName.

Observe que os campos de recursos do Kubernetes diferenciam maiúsculas de minúsculas.

Você pode visualizar qualquer campo de recurso como uma coluna. Basta revisar a especificação do recurso e experimentá-la com os campos que desejar.

Mas primeiro, vamos dar uma olhada mais de perto nas expressões de seleção de campo.

Expressões JSONPath

As expressões para selecionar campos de recursos são baseadas em JSONPathName.

JSONPath é uma linguagem para recuperar dados de documentos JSON. Selecionar um único campo é o caso de uso mais simples para JSONPath. Ele tem muito mais possibilidades, incluindo seletores, filtros e assim por diante.

A explicação do Kubectl oferece suporte a um número limitado de recursos JSONPath. As possibilidades e exemplos de sua utilização estão descritos a seguir:

# Выбрать все элементы списка
$ 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. Muitos campos de recursos do Kubernetes são listas e esse operador permite selecionar membros dessas listas. Geralmente é usado com um curinga como [*] para selecionar todos os elementos de uma lista.

Exemplos de aplicação

As possibilidades de usar um formato de saída de coluna personalizado são infinitas, pois você pode exibir qualquer campo ou combinação de campos de recursos na saída. Aqui estão alguns exemplos de aplicativos, mas fique à vontade para explorá-los e encontrar aplicativos que funcionem para você.

Exibindo imagens de contêiner para pods:

$ 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 exibe os nomes das imagens do contêiner para cada pod.

Lembre-se que um pod pode conter vários containers, então os nomes das imagens serão exibidos em uma linha, separados por vírgulas.

Exibindo zonas de disponibilidade de nós:
```
$ 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 será útil se o seu cluster estiver hospedado em uma nuvem pública. Ele exibe a zona de disponibilidade de cada nó.

A zona de disponibilidade é um conceito de nuvem que limita a zona de replicação a uma região geográfica.

As zonas de disponibilidade para cada nó são obtidas através de uma etiqueta especial - failure-domain.beta.kubernetes.io/zone. Se o cluster estiver rodando em uma nuvem pública, esse rótulo será criado automaticamente e preenchido com os nomes das zonas de disponibilidade de cada nó.

Os rótulos não fazem parte da especificação de recursos do Kubernetes, portanto você não encontrará informações sobre eles em Guia de API. No entanto, eles podem ser vistos (como qualquer outro rótulo) se você solicitar informações sobre os nós no formato YAML ou JSON:
```
$ kubectl get nodes -o yaml
# или
$ kubectl get nodes -o json
```
Essa é uma ótima maneira de aprender mais sobre os recursos, além de aprender as especificações dos recursos.

4. Alterne facilmente entre clusters e namespaces

Quando o kubectl faz uma solicitação à API do Kubernetes, ele primeiro lê o arquivo kubeconfig para obter todos os parâmetros necessários para a conexão.

Por padrão, o arquivo kubeconfig é ~/.kube/config. Normalmente este arquivo é criado ou atualizado por um comando especial.

Ao trabalhar com vários clusters, seu arquivo kubeconfig contém configurações para conexão com todos esses clusters. Você precisa informar ao comando kubectl com qual cluster você está trabalhando.

Dentro de um cluster, você pode criar vários namespaces — um tipo de cluster virtual dentro de um cluster físico. Kubectl também determina qual namespace usar com base no arquivo kubeconfig. Isso significa que você também precisa informar ao comando kubectl com qual namespace trabalhar.

Neste capítulo explicaremos como funciona e como fazê-lo funcionar de forma eficaz.

Observe que você pode ter vários arquivos kubeconfig listados na variável de ambiente KUBECONFIG. Neste caso, todos esses arquivos serão combinados em uma configuração comum em tempo de execução. Você também pode alterar o arquivo kubeconfig padrão executando kubectl com o parâmetro --kubeconfig. Ver documentação oficial.

arquivos kubeconfig

Vamos ver o que exatamente o arquivo kubeconfig contém:

Como você pode ver, o arquivo kubeconfig contém um conjunto de contextos. O contexto consiste em três elementos:

Cluster — URL da API do servidor do cluster.
Usuário – credenciais de autenticação do usuário no cluster.
Namespace - o namespace usado ao ingressar no cluster.

Na prática, eles costumam usar um contexto por cluster em seu kubeconfig. No entanto, você pode ter vários contextos por cluster, diferenciados por usuário ou namespace. No entanto, esta configuração multicontexto é incomum, portanto geralmente há um mapeamento um-para-um entre clusters e contextos.

A qualquer momento, um dos contextos é atual:

Quando o kubectl lê um arquivo de configuração, ele sempre obtém informações do contexto atual. No exemplo acima, o kubectl se conectará ao cluster Hare.

Da mesma forma, para mudar para outro cluster, você precisa alterar o contexto atual no arquivo kubeconfig:

Agora o kubectl se conectará ao cluster Fox.

Para mudar para um namespace diferente no mesmo cluster, é necessário alterar o valor do elemento namespace para o contexto atual:

No exemplo acima, kubectl usará o namespace Prod do cluster Fox (anteriormente o namespace Test era definido).

Observe que o kubectl também oferece opções --cluster, --user, --namespace и --context, que permite substituir elementos individuais e o próprio contexto atual, independentemente do que estiver definido no kubeconfig. Olhar kubectl options.

Em teoria, você pode alterar manualmente as configurações no kubeconfig. Mas é inconveniente. Para simplificar estas operações, existem vários utilitários que permitem alterar os parâmetros automaticamente.

Usar kubectx

Um utilitário muito popular para alternar entre clusters e namespaces.

O utilitário fornece comandos kubectx и kubens para alterar o contexto e o namespace atuais, respectivamente.

Conforme mencionado, alterar o contexto atual significa alterar o cluster se você tiver apenas um contexto por cluster.

Aqui está um exemplo de execução desses comandos:

Essencialmente, esses comandos simplesmente editam o arquivo kubeconfig conforme descrito acima.

para instalar kubectx, siga as instruções em Github.

Ambos os comandos suportam o preenchimento automático de nomes de contexto e namespace, o que elimina a necessidade de digitá-los completamente. Instruções para configurar o preenchimento automático aqui.

Outro recurso útil kubectx é modo interativo. Funciona em conjunto com o utilitário fzf, que deve ser instalado separadamente. A instalação do fzf disponibiliza automaticamente o modo interativo em kubectx. Interativamente, você pode selecionar o contexto e o namespace por meio da interface de pesquisa interativa gratuita fornecida pelo fzf.

Usando aliases de shell

Você não precisa de ferramentas separadas para alterar o contexto e o namespace atuais porque o kubectl também fornece comandos para isso. Sim, equipe kubectl config fornece subcomandos para edição de arquivos kubeconfig.

Aqui estão algumas delas:

kubectl config get-contexts: exibe todos os contextos;
kubectl config current-context: obtém o contexto atual;
kubectl config use-context: mudar o contexto atual;
kubectl config set-context: altere o elemento de contexto.

No entanto, usar esses comandos diretamente não é muito conveniente porque são longos. Você pode criar aliases de shell para eles que sejam fáceis de executar.

Criei um conjunto de aliases com base nesses comandos que fornecem funcionalidade semelhante ao kubectx. Aqui você pode vê-los em ação:

Observe que os aliases usam fzf para fornecer uma interface de pesquisa interativa gratuita (como o modo interativo do kubectx). Isso significa que você precisa instalar fzfpara usar esses apelidos.

Aqui estão as definições dos próprios aliases:

# Получить текущий контекст
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 definir esses aliases você precisa adicionar as definições acima ao seu arquivo ~/.bashrc ou ~/.zshrc e reinicie seu shell.

Usando plug-ins

Kubectl permite carregar plug-ins que são executados da mesma forma que comandos básicos. Você pode, por exemplo, instalar o plugin kubectl-foo e executá-lo executando o comando kubectl foo.

Seria conveniente alterar o contexto e o namespace desta forma, por exemplo, executando kubectl ctx mudar o contexto e kubectl ns para alterar o espaço para nome.

Eu escrevi dois plugins que fazem isso:

O trabalho dos plugins é baseado nos aliases da seção anterior.

Veja como eles funcionam:

Observe que os plug-ins usam fzf para fornecer uma interface de pesquisa interativa gratuita (como o modo interativo do kubectx). Isso significa que você precisa instalar fzfpara usar esses apelidos.

Para instalar plug-ins, você precisa baixar scripts de shell chamados kubectl-ctx и kubectl-ns para qualquer diretório em sua variável PATH e torná-los executáveis, por exemplo. chmod +x. Imediatamente depois disso você poderá usar kubectl ctx и kubectl ns.

5. Reduza a entrada com aliases automáticos

Aliases de shell são uma boa maneira de acelerar a entrada. Projeto aliases de kubectl contém cerca de 800 atalhos para comandos básicos do kubectl.

Você deve estar se perguntando - como você se lembra de 800 aliases? Mas você não precisa se lembrar de todos eles, pois eles são construídos de acordo com um esquema simples, que é apresentado a seguir:

Por exemplo:

kgpooyaml - kubectl obtém pods oyaml
ksysgsvcw — kubectl -n kube-system obtém svc w
ksysrmcm -kubectl -n sistema kube rm cm
kgdepallsl - kubectl obtém implantação de todos os sl

Como você pode ver, os aliases são compostos de componentes, cada um representando um elemento específico do comando kubectl. Cada alias pode ter um componente para o comando, operação e recurso base e vários componentes para parâmetros. Você simplesmente “preenche” esses componentes da esquerda para a direita de acordo com o diagrama acima.

O diagrama detalhado atual está em GitHub. Lá você também pode encontrar lista completa de aliases.

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

A ordem relativa das opções não é importante: comando kgpooyamlall é equivalente ao comando kgpoalloyaml.

Você não precisa usar todos os componentes como aliases. Por exemplo k, kg, klo, ksys, kgpo também pode ser usado. Além disso, você pode combinar aliases e comandos ou opções regulares na linha de comando:

Por exemplo:

Em vez de kubectl proxy você pode escrever k proxy.
Em vez de kubectl get roles você pode escrever kg roles (atualmente não há alias para o recurso Funções).
Para obter dados de um pod específico, você pode usar o comando kgpo my-pod — kubectl get pod my-pod.

Observe que alguns aliases requerem um argumento de linha de comando. Por exemplo, alias kgpol meios kubectl get pods -l. Opção -l requer um argumento - uma especificação de rótulo. Se você usar um alias, será parecido kgpol app=ui.

Como alguns aliases exigem argumentos, os aliases a, f e l devem ser usados por último.

Em geral, depois de pegar o jeito desse esquema, você pode derivar intuitivamente aliases dos comandos que deseja executar e economizar muito tempo de digitação.

Instalação

Para instalar kubectl-aliases, você precisa baixar o arquivo .kubectl_aliases do GitHub e inclua-o no arquivo ~/.bashrc ou ~/.zshrc:

source ~/.kubectl_aliases

Preenchimento automático

Como dissemos antes, muitas vezes você adiciona palavras adicionais a um alias na linha de comando. Por exemplo:

$ kgpooyaml test-pod-d4b77b989

Se você usa o preenchimento do comando kubectl, provavelmente já usou o preenchimento automático para itens como nomes de recursos. Mas isso pode ser feito quando aliases são usados?

Esta é uma questão muito importante porque se o preenchimento automático não funcionar, você perderá alguns dos benefícios dos aliases.

A resposta depende de qual shell você está usando:

Para Zsh, a conclusão do alias funciona imediatamente.
Para o Bash, infelizmente, é necessário algum trabalho para que o preenchimento automático funcione.

Habilitando o preenchimento automático para aliases no Bash

O problema com o Bash é que ele tenta completar (cada vez que você pressiona Tab) o alias, não o comando ao qual o alias se refere (como o Zsh faz, por exemplo). Como você não possui scripts de conclusão para todos os 800 aliases, o preenchimento automático não funciona.

Projeto alias completo fornece uma solução geral para este problema. Ele se conecta ao mecanismo de conclusão para aliases, expande internamente o alias para um comando e retorna opções de conclusão para o comando concluído. Isso significa que o preenchimento de um alias se comporta exatamente da mesma forma que o de um comando completo.

A seguir, explicarei primeiro como instalar o alias completo e, em seguida, como configurá-lo para permitir a conclusão de todos os aliases do kubectl.

Instalando o alias completo

Primeiro de tudo, o alias completo depende de conclusão bash. Portanto, antes de instalar o alias completo, você precisa ter certeza de que o bash-completion está instalado. As instruções de instalação foram fornecidas anteriormente para Linux e MacOS.

Nota importante para usuários MacOS: assim como o script de preenchimento automático kubectl, complete-alias não funciona com Bash 3.2, que é o padrão no MacOS. Em particular, complete-alias depende do bash-completion v2 (brew install bash-completion@2), que requer pelo menos Bash 4.1. Isso significa que para usar o alias completo no MacOS você precisa instalar uma versão mais recente do Bash.

Você precisa baixar o script bash_completion.sh de Repositório GitHub e inclua-o em seu arquivo ~/.bashrc:

source ~/bash_completion.sh

Após reiniciar o shell, o alias completo será totalmente instalado.

Habilitando o preenchimento automático para aliases do kubectl

Tecnicamente complete-alias fornece uma função wrapper _complete_alias. Esta função verifica o alias e retorna dicas de conclusão para o comando alias.

Para associar uma função a um alias específico, você precisa usar o mecanismo Bash integrado completar, para instalar _complete_alias como uma função de conclusão de alias.

Como exemplo, tomemos o alias k, que significa o comando kubectl. para instalar _complete_alias Como função complementar para este alias, você deve executar o seguinte comando:

$ complete -F _complete_alias k

O resultado disso é que sempre que você preenche automaticamente um alias k, a função é chamada _complete_alias, que verifica o alias e retorna dicas de conclusão para o comando kubectl.

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

$ complete -F _complete_alias kg

Assim como no exemplo anterior, ao preencher automaticamente kg, você obtém as mesmas dicas de conclusão que obteria para kubectl get.

Observe que você pode usar complete-alias para qualquer alias em seu sistema.

Portanto, para habilitar o preenchimento automático para todos os aliases do kubectl, você precisa executar o comando acima para cada um deles. O trecho a seguir faz exatamente isso, desde que você tenha definido kubectl-aliases como ~/.kubectl-aliases:

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

Este pedaço de código precisa ser colocado em seu ~/.bashrc, reinicie o shell de comando e o preenchimento automático ficará disponível para todos os 800 aliases do kubectl.

6. Estendendo o kubectl com plug-ins

Desde versão 1.12, kubectl suporta mecanismo de plug-in, que permite expandir suas funções com comandos adicionais.

Se você está familiarizado com Mecanismos de plug-in Git, então os plug-ins kubectl são construídos com base no mesmo princípio.

Neste capítulo, abordaremos como instalar plug-ins, onde encontrá-los e como criar seus próprios plug-ins.

Instalando plug-ins

Os plug-ins Kubectl são distribuídos como arquivos executáveis simples com o nome como kubectl-x. Prefixo kubectl- é necessário, seguido por um novo subcomando kubectl que permite chamar o plugin.

Por exemplo, o plugin hello será distribuído como um arquivo chamado kubectl-hello.

Para instalar o plugin, você precisa copiar o arquivo kubectl-x para qualquer diretório em seu PATH e torne-o executável, por exemplo com chmod +x. Imediatamente depois disso você pode chamar o plugin com kubectl x.

Você pode usar o seguinte comando para listar todos os plug-ins atualmente instalados em seu sistema:

$ kubectl plugin list

Este comando também exibirá avisos se você tiver vários plugins com o mesmo nome ou se houver um arquivo de plugins que não seja executável.

Encontrar e instalar plug-ins usando Krew

Os plug-ins Kubectl podem ser compartilhados ou reutilizados como pacotes de software. Mas onde você pode encontrar plug-ins que outras pessoas compartilharam?

Equipe do Projeto tem como objetivo fornecer uma solução unificada para compartilhamento, pesquisa, instalação e gerenciamento de plug-ins kubectl. O projeto se autodenomina um "gerenciador de pacotes para plug-ins kubectl" (Krew é semelhante a fermentação).

Krew é uma lista de plug-ins kubectl que você pode selecionar e instalar. Ao mesmo tempo, Krew também é um plugin para kubectl.

Isso significa que a instalação do Krew funciona essencialmente como a instalação de qualquer outro plugin kubectl. Você pode encontrar instruções detalhadas em Página do GitHub.

Os comandos Krew mais importantes são:

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

Observe que a instalação de plug-ins usando o Krew não interfere na instalação de plug-ins usando o método padrão descrito acima.

Observe que o comando kubectl krew list exibe apenas plug-ins que foram instalados usando Krew, enquanto o comando kubectl plugin list lista todos os plugins, ou seja, aqueles instalados usando Krew e aqueles instalados por outros métodos.

Encontrando plug-ins em outro lugar

Krew é um projeto jovem, atualmente em fase de listar apenas cerca de 30 plug-ins. Se não conseguir encontrar o que precisa, você pode encontrar plug-ins em outro lugar, como o GitHub.

Eu recomendo olhar a seção GitHub Plug-ins kubectl. Lá você encontrará dezenas de plugins disponíveis que vale a pena conferir.

Escrevendo seus próprios plug-ins

você pode você mesmo criar plug-ins - Não é difícil. Você precisa criar um executável que faça o que você precisa, nomeie-o como kubectl-x e instale conforme descrito acima.

O arquivo pode ser um script bash, um script python ou um aplicativo GO compilado - não importa. A única condição é que possa ser executado diretamente no sistema operacional.

Vamos criar um plugin de exemplo agora. Na seção anterior, você usou o comando kubectl para listar os contêineres de cada pod. É fácil transformar este comando em um plugin que você pode usar, por exemplo. kubectl img.

Crie um arquivo kubectl-img o seguinte conteúdo:

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

Agora torne o arquivo executável com chmod +x kubectl-img e mova-o para qualquer diretório em seu PATH. Imediatamente depois disso você pode usar o plugin kubectl img.

Conforme mencionado, os plug-ins kubectl podem ser escritos em qualquer linguagem de programação ou script. Se você estiver usando scripts de shell, a vantagem de poder chamar facilmente o kubectl de dentro do plugin. No entanto, você pode escrever plugins mais complexos em linguagens de programação reais usando Biblioteca cliente Kubernetes. Se você estiver usando Go, também poderá usar biblioteca cli-runtime, que existe especificamente para escrever plug-ins kubectl.

Como compartilhar seus plug-ins

Se você acha que seus plug-ins podem ser úteis para outras pessoas, sinta-se à vontade para compartilhá-los no GitHub. Certifique-se de adicioná-los ao tópico Plug-ins kubectl.

Você também pode solicitar que seu plugin seja adicionado ao Lista de tripulação. As instruções sobre como fazer isso estão em Repositórios GitHub.

Conclusão do comando

Atualmente, os plug-ins não suportam o preenchimento automático. Ou seja, você deve inserir o nome completo do plugin e os nomes completos dos argumentos.

O repositório GitHub kubectl para esta função tem solicitação aberta. Portanto, é possível que esse recurso seja implementado em algum momento no futuro.

Удачи !!!

O que mais ler sobre o assunto:

Fonte: habr.com

Como usar o kubectl de forma mais eficaz: um guia detalhado