KuView: painel do Kubernetes em tempo real baseado na web
(github.com/iwanhae)Pessoalmente, gosto bastante de Kubernetes, mas, ainda assim, se há alguns pontos decepcionantes, um deles é que a abstração é tão bem feita que os elementos físicos reais ficam ocultos e são difíceis de verificar.
Por exemplo:
- Quando um determinado Pod está com problema, como está o estado dos outros Pods implantados no mesmo nó?
- Todos os Pods atualmente conectados ao Service estão funcionando normalmente?
- Como está o uso atual de CPU e memória do nó? E, dentro disso, qual é a participação de cada Pod?
- Qual é a lista de PVs atualmente conectados ao nó?
Claro, não é que essas informações não existam; há maneiras de visualizá-las uma a uma combinando kubectl com ferramentas de monitoramento como Prometheus, mas também é verdade que isso é bem trabalhoso.
Para ajudar nesse tipo de situação, criei um painel web de Kubernetes em tempo real. Sem precisar instalar nada separadamente, se for possível usar apenas o comando kubectl proxy, ele funciona em forma de WASM dentro do navegador, observando todos os recursos do Kubernetes por meio de WATCH.
7 comentários
Parece que os números de Running / Terminating mudam em intervalos de 0,00x segundo, nem chegam a 1 segundo — qual seria o princípio por trás disso? Será que ele fica consultando a API do k8s o tempo todo?
Quero usar, mas fiquei um pouco preocupado se isso não acabaria gerando uma carga enorme de requisições de leitura na API do k8s, então resolvi perguntar!
Usa a WATCH API do K8s.
https://kubernetes.io/docs/reference/…
Como recebe apenas as mudanças via protobuf e SSE, é bastante eficiente e a carga é mínima. (É um nível de carga parecido com o que o kubelet impõe ao kube apiserver)
Mas, se várias pessoas forem usar ao mesmo tempo, recomendo o modo servidor em vez de wasm. Como o servidor busca as requisições no lugar do cliente e entrega o que mantém em memória, a carga no kube apiserver diminui.
O arquivo WASM tem cerca de 90 MB, então é bem grande mesmo.
É grande, mas não parece ter entropia alta. Atualmente, ao baixar com
curl, o arquivo compactado com gzip tem só cerca de 14 MB. Mesmo ao servir o WASM de fato, hoje em dia normalmente são aplicados algoritmos de codificação como gzip, zstd e brotli, então é de se esperar que o tráfego efetivamente transmitido não seja alto.Também tenho curiosidade sobre quando o binário é compactado com zstd.
Mudando um pouco de assunto, fiquei curioso para saber se a conversão e o uso com WASM foram tranquilos (se vocês não tiveram nenhuma dificuldade)!
Primeiro foi feito mais ou menos em WASM e, depois, apenas a lógica comum foi agrupada para separar o código do lado do servidor mais tarde, então não houve nenhuma inconveniência em particular. Na verdade, agora até que estou satisfeito em usar assim, porque mesmo alterando o código de forma meio improvisada, isso é aplicado tanto no Server quanto no WASM. haha