KuView: panel de Kubernetes en tiempo real basado en la web

Personalmente me gusta bastante Kubernetes, pero si tuviera que mencionar algunos puntos decepcionantes, diría que la abstracción está tan bien lograda que los elementos físicos reales quedan ocultos y es difícil verificarlos.

Por ejemplo:

• Si un Pod está teniendo fallas, ¿cómo están los otros Pods desplegados en el mismo nodo?
• ¿Todos los Pods conectados actualmente al Service están funcionando con normalidad?
• ¿Cómo va el uso actual de CPU y memoria del nodo? ¿Y qué proporción corresponde a cada Pod individual?
• ¿Cuál es la lista de PV conectados actualmente al nodo?

Claro, no es que no haya información en absoluto; existe la forma de visualizarla combinando kubectl con herramientas de monitoreo como Prometheus, pero la verdad es que resulta bastante engorroso.

Para ayudar en una situación así, hice una especie de panel web de Kubernetes en tiempo real. Funciona como una aplicación WASM dentro del navegador web y observa todos los recursos de Kubernetes, sin necesidad de instalar nada por separado, siempre que se pueda usar el comando kubectl proxy.

[xogns556]

Parece que los números de Running / Terminating cambian en intervalos de 0.00x segundos, ni siquiera de 1 segundo; ¿qué mecanismo hace que sigan cambiando así? ¿Estará consultando constantemente la API de k8s?

Quiero usarlo, pero me preocupa un poco si no estará generando una carga enorme de solicitudes de lectura sobre la API de k8s, así que pregunto.

[iwanhae]

Usa la WATCH API de K8s.
https://kubernetes.io/docs/reference/…

Como solo recibe los cambios vía protobuf y SSE, es bastante eficiente y la carga es mínima. (Es un nivel de carga similar al que kubelet ejerce sobre kube apiserver.)

Sin embargo, si varias personas lo van a usar al mismo tiempo, recomiendo el modo servidor en lugar de wasm. Como el servidor recibe las solicitudes y entrega lo que mantiene en memoria, reduce la carga sobre kube apiserver.

[taeuk]

El archivo WASM sí es bastante grande, como de unos 90 MB.

[iwanhae]

Es grande, pero no parece tener una entropía muy alta. Actualmente, al descargarlo con curl, el archivo comprimido con gzip pesa apenas unos 14 MB. Incluso al servir WASM en la práctica, hoy en día normalmente se aplican algoritmos de codificación como gzip, zstd o brotli, así que se espera que el tráfico realmente transmitido no sea alto.

[kandk]

También me da curiosidad cuando ese binario se comprime con zstd.

[roxie]

Es un tema un poco distinto, pero me da curiosidad saber si la conversión y el uso con WASM fueron fluidos (si no tuvieron incomodidades).

[iwanhae]

Primero lo hice más o menos rápido con WASM, y luego agrupé solo la lógica común para después separar aparte el código del lado del servidor, así que no hubo ninguna incomodidad en particular. De hecho, ahora incluso si modifico el código así nomás, se aplica tanto al servidor como a WASM, así que lo estoy usando bastante satisfecho. Jaja