KuView : tableau de bord Kubernetes web en temps réel

Personnellement, j’aime beaucoup Kubernetes, mais s’il y a tout de même quelques points regrettables, c’est que l’abstraction est tellement poussée qu’il devient difficile de voir et de vérifier les éléments physiques réels.

Par exemple :

• Lorsqu’un Pod rencontre un problème, quel est l’état des autres Pods déployés sur le même nœud ?
• Les Pods actuellement connectés au Service fonctionnent-ils tous normalement ?
• Quelle est l’utilisation actuelle du CPU et de la mémoire du nœud ? Et quelle est la part de chaque Pod ?
• Quelle est la liste des PV actuellement connectés au nœud ?

Bien sûr, les informations ne sont pas totalement absentes : il existe des moyens de les visualiser une par une en combinant kubectl avec des outils de supervision comme Prometheus, mais cela reste en réalité assez fastidieux.

Pour aider dans ce genre de situation, j’ai créé un tableau de bord Kubernetes web en temps réel. Il fonctionne en mode WASM dans le navigateur et surveille toutes les ressources de Kubernetes, sans rien avoir à installer séparément, à condition de pouvoir utiliser simplement la commande kubectl proxy.

[xogns556]

On dirait que les chiffres de Running / Terminating changent en continu à l’échelle de 0,00x seconde, et pas seulement toutes les secondes. Par quel mécanisme cela se met-il à jour en permanence ? Est-ce que ça interroge sans arrêt l’API k8s ?

J’aimerais l’utiliser, mais je me demande si cela ne risque pas d’imposer une charge énorme en requêtes de lecture sur l’API k8s, donc je préfère poser la question !

[iwanhae]

Il utilise l’API WATCH de K8s.
https://kubernetes.io/docs/reference/…

Comme il ne reçoit que les changements via protobuf et SSE, c’est assez efficace et la charge reste minime. (C’est à peu près le niveau de charge que kubelet impose à kube apiserver.)

En revanche, si plusieurs personnes l’utilisent en même temps, je recommande le mode serveur plutôt que wasm. Comme le serveur récupère les requêtes à la place et renvoie ce qu’il conserve en mémoire, cela réduit la charge sur kube apiserver.

[taeuk]

Le fichier WASM fait environ 90 Mo, donc il est quand même assez volumineux.

[iwanhae]

La taille est certes importante, mais l’entropie ne semble pas très élevée. Actuellement, lors du téléchargement avec curl, la version compressée en gzip ne fait qu’environ 14 Mo. Même lors du service réel du WASM, des algorithmes d’encodage comme gzip, zstd ou brotli sont aujourd’hui généralement appliqués, donc le trafic effectivement transmis ne devrait pas être élevé.

[kandk]

Je suis aussi curieux de savoir ce qu'il en est lorsque le binaire est compressé avec zstd.

[roxie]

C’est un peu un autre sujet, mais je suis curieux de savoir si la conversion vers WASM et son utilisation se sont déroulées de manière fluide (sans inconfort particulier) !

[iwanhae]

Comme ça a d’abord été bricolé rapidement en WASM, puis que seul le code commun a été regroupé avant d’extraire séparément plus tard le code côté serveur, il n’y a pas eu de gêne particulière. Au contraire, maintenant, même si je modifie le code un peu à la va-vite, les changements s’appliquent à la fois au serveur et au WASM, donc je l’utilise avec une certaine satisfaction. haha