Temos o prazer de anunciar um novo desenvolvimento de código aberto da empresa Flant para especialistas em DevOps e não apenas no
kubedog . Esta é uma biblioteca Go-escrita e uma CLI baseada nela para rastrear eventos de recursos do Kubernetes e coletar seus logs.
Atualmente, a biblioteca oferece suporte ao rastreamento dos seguintes recursos: Pod (e Contêiner), Trabalho, Implantação, StatefulSet e DaemonSet. Eventos e logs são transmitidos através de retornos de chamada.
A CLI do kubedog possui dois modos de operação:
- pista de lançamento - rastreando o recurso até que o estado Pronto seja atingido e saia em caso de erro para uso conveniente no CI / CD;
- follow - imprime eventos e logs na tela sem sair, semelhante ao
tail -f .
O problema
Por que começamos a escrever uma nova biblioteca se já existem projetos semelhantes
(consulte “Trabalhando com logs” nesta revisão ) ? O Kubedog é usado em nosso
utilitário dapp DevOps para rastrear
a distribuição dos gráficos Helm. O próprio Helm não sabe como monitorar o estado dos recursos que ele adiciona e a transferência de logs não é fornecida no nível da interação GRPC entre o Helm e o leme. Nesta ocasião, existe o
nosso problema 3481 , no qual implementamos o rastreamento de recursos adicionais ... No entanto, o projeto Helm agora reluta em adicionar novos recursos ao Helm 2, pois todos os esforços estão concentrados na nova versão do
Helm 3 . Por esse motivo, decidimos separar o kubedog em um projeto separado.
O que a biblioteca de rastreamento de recursos
precisa ?
- Obtenha logs de Pods que pertencem a um recurso - por exemplo, Implantação.
- Responda a alterações na composição dos Pods que pertencem ao recurso: adicione logs de recebimento de novos Pods, desative os logs dos Pods de ReplicaSets antigos.
- Acompanhamento de eventos em que descriptografam vários erros. Por exemplo, um Pod não pode ser criado devido a uma imagem desconhecida ou um Pod foi criado, mas o comando especificado no modelo não está na imagem.
- E mais um requisito é acompanhar a transição de um recurso do modo de
rollout para o modo ready . E cada recurso tem suas próprias condições para isso.
Como você deve imaginar, no kubedog, tentamos
levar em conta todas as opções
acima .
De uma maneira boa, no início do trabalho em algo novo, eles analisam as soluções existentes. Porém, apesar de existirem muitas soluções na forma da CLI, simplesmente não existe uma biblioteca Go. Portanto, podemos apenas fazer uma pequena comparação dos principais recursos dos utilitários CLI existentes para rastrear os recursos do Kubernetes.
Soluções existentes
kubespy
→
GitHub- Capaz de monitorar apenas a Implantação e o Serviço, reage aos novos Pods.
- Existe um modo de rastreamento para a descrição do recurso e seu status e a saída de alterações na forma de json diff.
- Há uma representação tabular em cores das alterações, mostrando o status de ReplicaSets e condições.
- Não mostra os logs do Pod.
- Está escrito em Go, mas não pode ser usado como uma biblioteca.
kubetail
→
GitHub- Um script bash que chama kubectl.
- Capaz de mostrar registros de Pods existentes.
- Ele não detecta novos Pods; se ocorrer uma reversão, o kubetail precisará ser reiniciado.
popa
→
GitHub- Mostra os logs dos Pods filtrados por consulta de pod.
- Descubra novos pods.
- As linhas de log são coloridas para melhor percepção.
- Mostra os eventos de adição e remoção de Pods com os nomes dos contêineres.
- Ele não segue os Eventos, portanto, não mostra a causa dos erros do Pod.
- Está escrito em Go, mas não pode ser usado como uma biblioteca.
kail
→
GitHub- Capaz de mostrar logs simultaneamente de diferentes namespaces para diferentes recursos.
- Não monitora Eventos, não mostra a causa dos erros, por exemplo, para Implantação.
- Não pinta logs de pods.
- Está escrito em Go, mas não pode ser usado como uma biblioteca.
k8stail
→
GitHub- Uma seleção de Pods por namespace e rótulos.
- Mantém o controle de novos, exclusão.
- Não segue Eventos, não mostrará erros.
- On Go, mas não uma biblioteca.
kubedog
→
GitHub- A CLI opera em dois modos: rastreamento sem fim e rastreamento até que o recurso mude para o status READY.
- Mantém o controle de um recurso.
- Reage às alterações de recursos, assina os logs dos novos Pods.
- Capaz de monitorar Deployment, StatefulSet, DaemonSet, Job ou um Pod separado.
- Escrito no Go, você pode usá-lo como uma biblioteca para adicionar recursos ao seu programa para monitorar o status dos recursos e receber logs de contêineres.
Se você der uma olhada mais de perto, pode dizer que cada utilitário de alguma forma supera seus rivais e não há um único vencedor que possa fazer todo o resto.
Então kubedog!
A essência do trabalho do kubedog é a seguinte: para o recurso especificado, execute Observadores em Eventos e Pods pertencentes ao recurso e, quando o Pod aparecer, execute seu criador de logs. Tudo o que acontece com o recurso é transmitido para o cliente chamando retornos de chamada.
Vejamos um exemplo do DaemonSet, disponível para código que usa a biblioteca. A interface de retorno de chamada para Deployment, StatefulSet e DaemonSet é a mesma * - este é
ControllerFeed :
type ControllerFeed interface { Added(ready bool) error Ready() error Failed(reason string) error EventMsg(msg string) error AddedReplicaSet(ReplicaSet) error AddedPod(ReplicaSetPod) error PodLogChunk(*ReplicaSetPodLogChunk) error PodError(ReplicaSetPodError) error }
* A exceção é
AddedReplicaSet , que faz sentido apenas para Implantação (você não pode definir esse método para rastrear DaemonsSet).
Explicações para outros métodos de interface:
Added corresponde ao evento watch.Added do observador para o recurso selecionado;Ready é chamado quando o recurso entra no estado Ready (por exemplo, para DaemonSet, este é o momento em que o número de Pods atualizados e disponíveis coincide com o número "desejado" de Pods);Failed - esse método é chamado quando um recurso é excluído ou no caso de um evento ser recebido com a causa e a descrição do erro (por exemplo, FailedCreate );EventMsg é chamado para cada Evento recebido do recurso ou de seus Pods: são eventos sobre a criação do recurso, sobre o upload de imagens, etc. Incluindo mensagens de erro;AddedPod - um método pelo qual você pode capturar os momentos da criação de novos Pods;PodLogChunk é chamado quando outro pedaço de logs vem da API do Kubernetes;PodError será PodError se o Pod falhar.
Cada retorno de chamada pode retornar um
StopTrack tipo
StopTrack e o rastreamento será concluído. Assim, por exemplo, feito no rastreador de lançamentos -
Ready StopTrack e a CLI termina seu trabalho.
Para facilitar a definição de retornos de chamada, existe uma estrutura
ControllerFeedProto , ao criar um objeto do qual você pode determinar o método de retorno de chamada desejado.
É assim que, por exemplo, a
saída interminável dos logs do DaemonSet se parece sem informações adicionais sobre eventos e status:
A última chamada é de
bloqueio : inicia um loop infinito de eventos de recebimento do Kubernetes e chama os retornos de chamada correspondentes. Você pode interromper programaticamente esse ciclo retornando
StopTrack partir do retorno de chamada.
Exemplos de aplicação
O uso do kubedog como uma biblioteca
pode ser visto no utilitário dapp. É aqui que os rastreadores de lançamento prontos são executados para verificar os recursos que o Helm cria ou atualiza.
O Kubedog CLI pode
ajudar na implementação no sistema de CI / CD e independentemente de ser usado: kubectl, Helm ou qualquer outra coisa. Afinal, você pode executar o
kubectl apply e, em seguida, a
kubedog rollout track , e você verá um erro nos logs de
kubedog rollout track se algo estiver errado com o recurso. Esse uso do kubedog ajudará a reduzir o tempo para diagnosticar problemas de implementação.
O que vem a seguir?
Planejamos desenvolver a biblioteca no sentido de oferecer mais recursos - por exemplo, eu realmente quero seguir o Service and Ingress. Além disso, deve-se realizar um trabalho sobre a classificação da
reason em Event'ah, para determinar com mais precisão o momento em que podemos assumir que a implementação do recurso falhou. Outro vetor de desenvolvimento de biblioteca está rastreando vários recursos de uma só vez, por exemplo, por
labelSelector ou por namespace de nome. Também quero oferecer suporte a várias anotações que podem alterar a natureza do rastreamento, por exemplo, para ganchos de leme, mas isso ainda é mais relevante para o dapp.
Num futuro próximo, o foco estará na biblioteca, mas também serão planejadas melhorias para a CLI: comandos e sinalizadores mais convenientes, coloração de logs, mensagens sobre a remoção de Pods, como na popa. Também estamos considerando a possibilidade de criar um modo interativo com uma tabela de status de implantação e eventos em uma janela e com logs em outra.
Como tentar?
A CLI do kubedog criada para Linux e macOS estão disponíveis na
bandeja .
Aguardamos ansiosamente seus comentários e problemas no
GitHub !
PS
Leia também em nosso blog: