KuView: Webbasierte Echtzeit-Dashboard für Kubernetes

Ich persönlich mag Kubernetes ziemlich gern, aber wenn es etwas gibt, das ich daran schade finde, dann ist es, dass durch die starke Abstraktion die tatsächlichen physischen Elemente verborgen werden und sich nur schwer überprüfen lassen.

Zum Beispiel:

• Wenn bei einem bestimmten Pod eine Störung auftritt, wie ist dann der Zustand der anderen Pods, die auf demselben Node bereitgestellt sind?
• Arbeiten alle Pods, die aktuell mit dem Service verbunden sind, ordnungsgemäß?
• Wie hoch ist die aktuelle CPU- und Memory-Auslastung des Node? Und welchen Anteil haben die einzelnen Pods daran?
• Welche PVs sind derzeit mit dem Node verbunden?

Natürlich fehlen diese Informationen nicht völlig; es gibt Wege, sie einzeln über Kombinationen von kubectl und Monitoring-Tools wie Prometheus zu visualisieren, aber in der Praxis ist das ziemlich umständlich.

Um in solchen Situationen zu helfen, habe ich ein passendes webbasiertes Echtzeit-Dashboard für Kubernetes gebaut. Ohne dass man zusätzlich etwas installieren muss, funktioniert es in Form von WASM im Webbrowser, sofern lediglich der Befehl kubectl proxy verfügbar ist, und überwacht dabei alle Ressourcen von Kubernetes per WATCH.

[xogns556]

Es sieht so aus, als würden sich die Zahlen für Running / Terminating nicht im Sekundentakt, sondern in Schritten von 0,00x Sekunden ändern. Nach welchem Prinzip aktualisiert sich das fortlaufend? Wird dabei ständig die k8s-API abgefragt?

Ich würde es gern verwenden, frage mich aber vorsichtshalber, ob das nicht eine enorme Last durch Read Requests auf die k8s-API verursacht.

[iwanhae]

Es verwendet die WATCH API von K8s.
https://kubernetes.io/docs/reference/…

Da nur Änderungen per Protobuf und SSE empfangen werden, ist es ziemlich effizient und die Last ist vernachlässigbar. (Sie liegt in etwa auf dem Niveau der Last, die kubelet auf den kube-apiserver ausübt.)

Wenn es jedoch von mehreren Personen gleichzeitig genutzt wird, empfehle ich eher den Server-Modus als wasm. Da der Server die Anfragen stellvertretend abruft und sie im Speicher hält und ausliefert, wird der kube-apiserver weniger belastet.

[taeuk]

Die WASM-Datei ist mit etwa 90 MB ziemlich groß.

[iwanhae]

Es ist zwar ziemlich groß, aber die Entropie scheint nicht besonders hoch zu sein. Wenn man es derzeit mit curl herunterlädt, ist die gzip-komprimierte Datei nur etwa 14 MB groß. Auch wenn das eigentliche WASM ausgeliefert wird, kommen heutzutage in den meisten Fällen Encoding-Algorithmen wie gzip, zstd oder brotoli zum Einsatz, daher ist davon auszugehen, dass der tatsächlich übertragene Traffic nicht besonders hoch sein wird.

[kandk]

Mich würde auch interessieren, wie es ist, wenn die Binärdatei mit zstd komprimiert wurde.

[roxie]

Ein etwas anderes Thema, aber mich würde interessieren, ob die Umwandlung nach WASM und dessen Nutzung reibungslos verliefen (ob es dabei keine Unannehmlichkeiten gab)!

[iwanhae]

Ich habe es zunächst grob mit WASM gebaut und später nur die gemeinsame Logik gebündelt und den serverseitigen Code separat herausgezogen, daher gab es keine besonderen Unannehmlichkeiten. Im Gegenteil: Selbst wenn ich den Code jetzt nur grob anpasse, werden die Änderungen sowohl auf der Server- als auch auf der WASM-Seite übernommen, daher nutze ich es bisher recht zufrieden. Haha