KuView: Webベースのリアルタイム Kubernetes ダッシュボード
(github.com/iwanhae)個人的に Kubernetes はかなり好きなのですが、それでもいくつか物足りない点があるとすれば、抽象化が行き届きすぎているあまり、実際の物理的な要素が隠れてしまい確認しづらいという点です。
たとえば
- ある Pod で障害が発生している状況で、同じノードにデプロイされた他の Pod たちの状態はどうか
- 現在 Service に接続されている Pod はすべて正常に動作しているか?
- 現在のノードの CPU、メモリ使用量はどうなっているか? その中で個々の Pod が占める割合はどうか?
- 現在のノードに接続されている PV の一覧は?
もちろん、情報がまったくないわけではなく、kubectl の組み合わせや Prometheus などの監視ツールを使って一つひとつ可視化する方法はありますが、かなり煩雑なのも事実です。
そうした状況の助けになればと思い、手頃に作ってみた Web ベースのリアルタイム Kubernetes ダッシュボードです。別途何かをインストールする必要はなく、kubectl proxy コマンドさえ使えれば、WASM 形式で Web ブラウザ内から Kubernetes のすべてのリソースを WATCH する形で動作します。
7件のコメント
Running/Terminatingの数値が、1秒単位でもなく 0.00x秒単位で変わっているように見えるのですが、どういう仕組みで継続的に更新されているのでしょうか？ ずっと k8s API を叩いているのでしょうか？使ってみたいのですが、k8s API の Read Request にものすごい負荷をかけるのではないかと少し心配で、質問してみました！
K8s の WATCH API を使っています。
https://kubernetes.io/docs/reference/…
変更点だけを protobuf、SSE で受け取る方式なので、かなり効率的で、負荷もごく軽微なレベルです。（kubelet が kube apiserver にかける程度の負荷です）
ただし、複数人が同時に使うのであれば、wasm よりもサーバーモードをおすすめします。サーバーが代わりにリクエストを受け取り、インメモリに保持しているものを返す仕組みなので、kube apiserver の負荷を抑えられます。
WASMファイルが90MBほどと、かなり大きいですね。
サイズは大きいですが、エントロピーが高いようには見えません。現時点で
curlでダウンロードすると、gzip されたものでも容量は 14MB 程度しかありません。実際に WASM を配信する際も、最近はたいてい gzip、zstd、brotli のようなエンコーディングアルゴリズムが適用されるので、実際に転送されるトラフィックはそれほど多くないと予想されます。そのバイナリをzstdで圧縮した場合も気になります。
少し話はそれますが、WASM への変換や利用はスムーズだったのか（不便さはなかったのか）気になります！
最初にWASMでざっくり作って、後から共通ロジックだけをまとめてServer側のコードを別に切り出した形だったので、特に不便さはありませんでした。むしろ今はコードをざっくり修正してもServerとWASMの両方に反映されているので、それなりに満足しながら使っています。haha