ヘッドランプは、Kubernetesを操作するための新しいGUIです

約transl。：1か月前、KinvolkはKubernetesクラスターを管理するためのインターフェイスをリリースしました。すでに多数の同様のソリューションのシリーズを拡張した新しいオープンソースプロジェクトは、インターフェイスデザインへの古典的なアプローチ、ローカルおよびクラスター内で実行する機能、および高い拡張性を組み合わせており、かなり豊富な機能セットとともに、少なくともプライマリーにとって興味深いものになっています。デート。今回の発表では、なぜヘッドランプがそのようになったのかを説明します。







Kubernetesの資料を読んでいると、さまざまなkubectlコマンドやトリッキーなYAML構成の例に繰り返し出くわしたことでしょう。 K8に精通している人にとって、このアプローチは間違いなく拒絶を引き起こしません。しかし、Webインターフェイスが普及している時代では、一般ユーザーにとって使いやすいとは言えません。それは初心者のための学習プロセスを複雑にし、Kubernetesにあまり精通していない人々のための障壁として機能します。



もちろん、Kubernetesアップストリーム自体の一部であるKubernetesダッシュボードを含むK8用のさまざまなGUIがあり ます。 （注の翻訳：この比較では、既存のソリューションの多くについてすでに説明しました。） しかし、さまざまなオプションをすべて調べたところ、完全に適したソリューションを見つけることができませんでした。 私はインターフェースが欲しかった：

• 100％オープンソースでした。
• コミュニティによって積極的にサポートされています。
• 特定のベンダーのKubernetesディストリビューションに関連付けられていないという意味で普遍的でした。
• モジュール式で拡張可能でした。
• きちんとしたモダンな外観でした。
• 開発者に馴染みのあるスタック（Go、JavaScript / TypeScript、React）に実装されました。
• インタラクティブでした（つまり、収集されたデータだけでなく、クラスターで特定のアクションを許可しました）。
• マルチクラスターモードをサポートしました。

かなり豊富な選択肢にもかかわらず、テストしたソリューションのいずれも、上記のすべての基準を満たしていませんでした（または、新しいソリューションを作成するための優れた基盤として役立つ可能性があります）。したがって、昔ながらの伝統に従って、私たちはそれを自分たちで作ることにしました...

ヘッドランプのご紹介

本日、ヘッドランプと呼ばれるKubernetesの新しいUIが広く利用可能になったことを発表できることを誇りに思います 。



ヘッドランプは、上記の基準を満たす多用途で拡張可能なKubernetesユーザーインターフェイスです。もちろん、Kinvolkの発案によるものであり、100％オープンソースです。Kubernetesコミュニティの多くのメンバーがヘッドランプを高く評価するだけでなく、プロジェクトに貢献することを願っています。



その主な特徴を簡単に見てみましょう。

拡張可能なUI

ヘッドランプができるだけ多くのユースケースに適していることを確認するよう努めています。プロジェクトの対象者は、Kubernetesの初心者だけでなく、非常に異なるニーズを持つ経験豊富な管理者やK8sベンダーでもあります。多くの場合（特にUIプロジェクトの場合）、このようなさまざまなユースケースは、多数のフォークを作成することによって実装され、各フォークは独自のダウンストリームチームによって維持されます。ただし、フォークを最新の状態に保つことは、フォークの変更が大きいほど難しくなります。



プラグインシステムはこの問題を解決します。そのため、Headlampはツリー外のUIプラグインをサポートしています。これらは、ヘッドランプバックエンドによってロードされ、クライアントに渡されるJavaScriptファイルであり、クライアントはそれらを動的にロードします。



このアプローチは革新の大きな機会を開き、多くの新機能の出現に貢献します。たとえば、ポッドの詳細ブロックにボタンを作成して、そのポッドの財務コストを表示するサービスにユーザーをリダイレクトするのは簡単です。



ヘッドランププラグインメカニズムは、コミュニティに大きなチャンスをもたらします。そして、Headlampの新しいプラグインの開発に参加したいすべての人と協力し、メカニズム自体を開発して、新しいユースケースに適応させる準備ができています。

Traceloop

プラグインメカニズム（およびツール自体）の能力を実証するために、プロジェクトInspektor Gadget （Kubernetesのアプリケーションをデバッグおよび検査するためのツールのセット-ca。Perevi..）に含まれるガジェットtraceloop用のヘッドランププラグインを開発し ました 。



Inspektorガジェットをインストールし、traceloopガジェットを有効にすると、ポッドから循環バッファーへのすべてのシステム呼び出しの書き込みが開始されます。このバッファは、ポッドの実行中にリアルタイムで表示できます。言い換えると、traceloopを使用すると、ポッドが現在実行していることを確認できます。さらに、バッファ内のデータは、終了したポッド用に保存されます。このようにして、障害が発生した後の障害の原因を特定できます。これは、Kubernetesアプリケーションの一種の「ブラックボックス」です。

選択的なUI

多くのCRUDユーザーインターフェイスの問題は、アクセス制御の内部構成について何も知らないことです。たとえば、編集/削除ボタンの存在は、ユーザーが実際にリソースを変更する権限を持っていない場合、ユーザーを誤解させます。ヘッドランプはRBACKubernetes設定をチェックし、ユーザーが使用できるアクションのコントロールのみを表示します。たとえば、ユーザーにリソースを編集する権限がない場合、「編集」ボタンは表示されません。



これはすべて、ユーザーエクスペリエンスに非常に有益な効果をもたらします。結局のところ、オペレーターは、現在の権利を考慮して、自分が利用できるアクションをすぐに確認できます。これは、時間制限のあるアクセス許可（リソースを削除するための一時的なアクセス許可など）が付与されている状況に最適です。





ユーザーが編集/削除権限を持っている場合のポッドでのアクションに使用できるボタンユーザーが編集/削除権限を





持っていない場合に使用できるボタン

デザイン/ユーザーインターフェース

「従来の」KubernetesUIまたはダッシュボードスタイルを維持しながら、ヘッドランプのデザインを可能な限り簡潔でモダンにすることを目指しました。たとえば、おなじみの表形式のビューは作業に最適であると確信しており、プラグインを使用して他のタイプの視覚化（たとえば、グラフ形式でのクラスターの表現）を実装できることを期待しています。



フロントエンドは、React with Material UIライブラリに実装されています （最新で、きちんとしていて、大規模なユーザーコミュニティによってサポートされています）。さらに、他のプロジェクトであるNebraska （Flatcar Container Linuxの更新マネージャー-約Transl。）の技術スタックに含まれています 。経験とリソースを共有し、すべての製品で一貫したUIを確保できます。

ローカルまたはクラスター内

ほとんどのKubernetesUIは、Kubernetes Dashboardのようなリモート（バックエンドは多くの場合クラスター内にあります）またはVMwareのOctantのようなローカル（アプリケーションはコンピューターにインストールされます）の2つのグループに分類されます 。



これらのアプローチにはそれぞれ長所と短所があります。たとえば、リモートアプリケーションの場合、URLを他のユーザーと共有し、OIDCを介してログインを実装するのは非常に簡単です。 「どこでも」利用でき、最新の状態に保つのは簡単です。逆に、デスクトップ版の場合、UIの配置を考える必要はありません。このアプローチはより良い分離を提供しますが、アプリケーションを最新の状態に保つのはユーザー次第です。



ヘッドランプを使用すると、これら2つのアプローチのどちらかを選択する必要がなくなります。両方がサポートされます。ヘッドランプは、YAMLファイルを使用して簡単にクラスター化（およびそれらを適応させる）することも、Linux、macOS、またはWindowsマシンにローカルにインストールすることもできます。

マルチクラスターモード

ほとんどのKubernetesデプロイメントは、いくつかのクラスターで構成されています（少なくとも、開発環境と製品環境を分離するため）。ヘッドランプは、これらすべてのクラスターへのアクセスを提供します。具体的な方法は、ローカルで実行するかリモートで実行するかによって異なります。



ローカルで実行している場合、Headlampはkubeconfigを読み取り、そこで使用可能なコンテキストを表示します。ユーザーは、ローカル環境変数を適切なクラスターに設定するだけで、必要に応じてコンテキストを変更できます。



マルチクラスターモードは非常に単純です。構成されたクラスターごとにプロキシが作成され、UIからの要求（Kubernetes APIへの呼び出しを含む）が目的のクラスターのアドレスにリダイレクトされます。K8dashプロジェクトはここで言及されるべき です、ヘッドランプの開発時に使用したリクエスト/ APIを管理するためのモジュール。



このアプローチは、クラスター内での実行と組み合わせることもできますが、そのためには、アプリケーションが実行されているクラスターで、指定された他のクラスターへのAPIアクセスが必要になります。

LokomotiveKubernetes接続

ご存知かもしれませんが、Kubernetesの独自のディストリビューションであるLokomotiveもあります 。LokomotiveではHeadlampを本来の目的で使用していますが、これらは独立した独立したプロジェクトであることを強調したいと思います。HeadlampをK8sサービスプロバイダーに結び付けるつもりはなく、一般的なKubernetesクラスターで動作するように設計しています。

クラスターでヘッドランプを試してください！

これを行うのは非常に簡単です。クラスターにデプロイメントをデプロイしてブラウザーで対応するアドレスに移動するか、Windows、macOS、またはLinux用のデスクトップバージョンをダウンロードしてインストールします。詳細はドキュメントにあり ます。



ヘッドランプは、Apache2.0ライセンスの下でリリースされた完全にオープンソースのツールです。前述のように、Kubernetesサービスプロバイダーから独立し、用途が広い（多数のユースケースをカバー）ようにしました。本日は、プロジェクトの開発にぜひご参加ください。これを行うには、関連するガイドラインをお読み ください。



ヘッドランプをお楽しみください！

翻訳者からのPS

私たちのブログも読んでください：

• "概要k9s-Kubernetesの高度な端末インターフェイス»;
• " Kubernetesのグラフィカルインターフェイスの概要»;
• 「KubernetesWebView Webインターフェイス（およびKubernetesの他のWeb UIの概要）を発表しました。」