Já
escrevemos sobre “assistentes de console” para o Kubernetes há um ano e, ainda mais cedo,
fizemos uma visão geral de outros utilitários úteis. No entanto, com o desenvolvimento dos K8s e de sua comunidade, o ecossistema associado também passa por mudanças. Portanto, novamente temos algo a dizer aos fãs do console. Vamos lá!
kubebox
- GitHub (mais de 400 estrelas)
- Idioma: JavaScript (Node.js)
- Licença: MIT
Este projeto foi o motivo para escrever a revisão. Por um lado, ele é um brilhante representante da categoria de software "geeks do para geeks", mas, por outro, cresceu a ponto de não apenas agradar aos olhos, mas também traz benefícios práticos ...
Portanto, o objetivo do kubebox é trabalhar totalmente com o Kubernetes dentro da estrutura de uma conveniente interface de console apresentada no estilo pseudo-gráfico:
Trabalho significa recursos como navegação através de pods através de namespaces, visualização de logs e até gráficos de consumo dos principais recursos (CPU, memória, rede), execução remota de comandos em contêineres. As configurações para conectar-se aos clusters podem ser obtidas na variável de ambiente
KUBECONFIG ou em
$HOME/.kube .
Os planos adicionais dos desenvolvedores incluem suporte para editar configurações e executar operações CRUD, bem como uma
reformulação significativa
da interface para oferecer suporte a novos tipos de primitivos (Serviços, Implantações, etc.) e navegação conveniente sobre eles com a saída de informações adicionais (em particular,
kubectl describe pod ).
Um recurso importante é a disponibilidade de uma
versão online (para conectar-se ao servidor da API do Kubernetes, você precisará
cors-allowed-origins permitidas por
cors-allowed-origins ). Além disso, o kubebox pode ser iniciado como um arquivo executável separado, como um cliente
em cluster (via kubectl), bem como a partir de um serviço implantado em um cluster Kubernetes ou OpenShift (o
Xterm.js é usado para emular o terminal).
Há quase dois anos, um funcionário da Red Hat da França desenvolve o kubebox (para ser exato, menos de 10% dos commits foram feitos por seu colega). O projeto recebeu publicidade suficientemente ampla apenas no mês passado (no
Reddit e em vários outros recursos), portanto, pode-se esperar que isso dê um novo impulso ao seu desenvolvimento.
kube-shell e kube-prompt
kube-shell
- GitHub (mais de 950 estrelas)
- Idioma: Python
- Licença: Apache 2.0
(Atenção, este ~ 2 Mb GIF!)prompt do kube
- GitHub (mais de 700 estrelas)
- Idioma: Ir
- Licença: MIT
Já
escrevemos sobre esses projetos há um ano e, na época, eles eram favoritos incondicionais entre os shells completos de console para trabalhar com o Kubernetes. Ambos estão posicionados como interfaces aprimoradas (mais convenientes de usar) para o kubectl. No kube-shell, eles usam a biblioteca
prompt-toolkit para Python e, para o kube-prompt, eles pegaram e desenvolveram uma biblioteca semelhante no Go (
go-prompt ).
Se você compará-los com o kubebox, a interface não se baseia em pseudográficos, mas no console comum para digitar comandos
(veja as capturas de tela acima) , que, no entanto, é acompanhado por "efeitos especiais" muito interessantes: dicas de ferramentas usando comandos, adição automática conveniente e etc.
Apesar da ampla variedade de recursos suportados (incluindo o sistema de dicas e o preenchimento automático já mencionados, uma pesquisa pelo histórico de comandos e um modo de edição semelhante ao vi), o
histórico de confirmações no kube-shell indica uma clara desaceleração no projeto. Apenas sete confirmações foram registradas este ano, duas das quais são modificações
README . Embora existam alguns úteis, por exemplo, o
tão esperado suporte para a variável
KUBECONFIG . De uma forma ou de outra, a contínua falta de reação dos desenvolvedores às consultas relevantes ao usuário (consulte os
problemas ) não inspira perspectivas adequadas.
A situação com o desenvolvimento do kube-prompt parece um pouco melhor. Embora este projeto tenha tido menos estrelas no GitHub (se um ano atrás estava um pouco à frente de seu concorrente Python, agora está visivelmente atrasado), os commits aparecem mais ou menos regularmente e a versão mais recente (
1.0.5 ) é de 18 de outubro. No entanto, não houve muitas mudanças significativas no ano passado - observamos o suporte para o Kubernetes versão 1.11 e a possibilidade de preenchimento automático para o espaço para nome. O principal é que o próprio autor
admite a impossibilidade de dedicar tempo suficiente ao desenvolvimento do kube-prompt e está procurando por ajudantes.
Resumindo os resultados desses dois projetos, podemos dizer que o kube-shell manteve sua liderança em termos de recursos suportados e avançou em popularidade, mas com as perspectivas de ambos os shells, tudo não está claro. No entanto, se você se sentir confortável com a forma como eles funcionam agora, não há motivo para não colocá-los em serviço, pois outras alternativas em um design semelhante não apareceram.
Clique em
- GitHub (mais de 750 estrelas)
- Idioma: Ferrugem
- Licença: Apache 2.0
O Click é um projeto bastante jovem: na versão beta, foi
apresentado no final de março - e muito interessante à sua maneira. Seu conceito se resume ao uso do kubectl em um
loop REPL , o que facilita a vida, mantendo um ambiente constante. O último é que o clique "lembra" o contexto atual, o espaço de nomes, o etc., solicitando que o usuário execute o comando desejado para esse recurso sem precisar especificar novamente o "caminho" inteiro.
A idéia do projeto teve origem na empresa Databricks, onde eles usam ativamente o Kubernetes e estão cansados de observar o mesmo cenário de trabalho com o kubectl, o que requer a constante introdução de dados anteriores. Ao mesmo tempo, o próprio utilitário kubectl - como o console em geral - é muito popular entre os engenheiros. Portanto, esse suplemento apareceu, não alegando substituir o kubectl, mas apenas ajudando a trabalhar com ele. Um exemplo de caso de uso para Click é:
pods //
2 //
describe //
events //
logs -c foo > /tmp/podfoo.log //
delete // ( )Se você estiver interessado, veja também um
pequeno screencast demonstrando o trabalho de Click com comentários de texto.
Trabalhar com logs
Como um bônus - não conchas, mas ferramentas de console para trabalhar com logs no Kubernetes. Há um ano, mencionamos apenas o
k8stail como tal, mas o tempo passado mostrou que o problema é relevante e existem outras soluções dignas de atenção para resolvê-lo.
Stern
- GitHub (~ 1300 estrelas)
- Idioma: Ir
- Licença: Apache 2.0
Stern é o favorito indiscutível da cauda na categoria Kubernetes. Para maior clareza, ao exibir registros, diferentes códigos de cores são usados:
Outro recurso importante é o uso de expressões regulares para filtragem conveniente de lareiras sem a necessidade de conhecer IDs específicos (por exemplo, selecione tudo com o nome
web-\w+ ). Da mesma forma (ou seja, regexpams), você pode filtrar contêineres específicos para os pods solicitados. Entre outras características da popa:
- suporte para modelos Go personalizados para logs de saída (existem vários predefinidos por padrão);
- suporte para seletores de etiquetas;
- restrição da saída do log para um valor de tempo especificado -
--since e / ou um número especificado de linhas; - suporte para preenchimento automático para bash e zsh, bem como substituição dinâmica de valores para namespaces e contextos.
Kubetail
- GitHub (~ 950 estrelas)
- Idioma: Shell
- Licença: Apache 2.0
Uma solução semelhante, escrita em Bash regular e um pouco mais ativamente desenvolvida no ano passado. Como na popa, ele suporta destacar os nomes das lareiras (ou toda a linha personalizável):
Também permite filtrar pods e contêineres por nomes completos e expressões regulares, além de usar seletores, limitar a saída ao tempo e ao número de linhas, além de oferecer suporte ao preenchimento automático para Bash, zsh e fish. Entre outros recursos:
- desativar modo -
--follow para atualizar dados de logs em tempo real (como em tail -f ); --dry-run para exibir uma lista de pods e contêineres adequados sem executar nenhuma outra ação;- Suporte ao seletor jq para analisar a saída em JSON.
Kail
- GitHub (~ 500 estrelas)
- Idioma: Ir
- Licença: MIT
Outra implementação que teve menos atividade na base de código no ano passado. No entanto, possui características funcionais interessantes que diferem dos concorrentes, a saber:
- restrição a pedido de lareiras pelos nomes de seus Serviços, Controlador de Replicação, Conjunto de Réplicas, Implantação, Nó e / ou Ingresso (ou seja, lareiras pertencentes aos serviços aos quais o ingresso especificado leva) ;
- a capacidade de não apenas selecionar por seletores, mas também excluí-los;
- determinação do nível de registro (
--log-level ).
Mas também há desvantagens: o kail não destaca os pods com cores, não suporta expressões regulares para filtros.
PS
Obrigado pelo seu interesse e, é claro, teremos o maior prazer em ouvir suas descobertas nos comentários!
Leia também em nosso blog: