ソフトウェアエンジニアの視点から見たKubernetes管理フロントエンドの内部

このブログ記事では、Kubernetes 管理フロントエンドを確認し、これらのツールがどのように構築されたかについて説明しました。

Christoph Enne 著「Kubernetes 管理フロントエンドの内部動作 - ソフトウェア エンジニアの視点」からの翻訳です。

近年の Kubernetes の台頭により、多数のオープンソース Kubernetes 管理ツールがどこからともなく登場するようになりました。この記事の調査の目的は、これらのツールのアーキテクチャを理解し、独自の Kubernetes フロントエンド開発を始めようとしている開発者に簡単な概要と選択肢を提供することです。ここではツール自体やツールが解決しようとする問題について詳しく説明するのではなく、ソフトウェア エンジニアリングの側面に焦点を当てます。また、ここではオープンソースおよびセルフホスト型ツールのみを調査しており、クラウド プロバイダーの PaaS/IaaS プラットフォームについては説明していません。これについては、まったく別の記事で説明します。

最初のクラスターの設定と操作は大変な場合があります。おそらく私と同じように、あなたも悪名高い kubernetes/dashboard に遭遇し、インストール手順に従い、「今何をしたのか、なぜこのように動作するのか」と自問したことでしょう。クラスターを少し調整した後、クラスターの特定の側面を管理するために CLI または Web UI を提供する外部ツールもインストールした可能性があります。

ここ数年間、主に Web 開発に携わってきたソフトウェア エンジニアとして、これらのツールがどのように構築され、展開されるのか興味があります。

まず、さまざまな Kubernetes UI を調べるために必要な基本的な知識を明確にしましょう。その後、それらの共通点と、この種のソフトウェアが特別な理由を確認し、最後に Kubernetes Web UI を自分で構築する方法に関する推奨事項を紹介します。

いずれにしても、公式ドキュメントは非常に役立ちます。覚えておくべき重要なことが 1 つあります。クラスターと対話するときはいつでも、Kubernetes API を介して行うということです。少なくともこの記事の範囲ではそうですが、他のユースケースもあるかもしれません。

この API の消費者として、この API がホストされている場所と、この API に対して認証する方法を知っておく必要があります。 Kubernetes API には、クラスター内 (つまり、ポッド上で実行されているアプリケーション) からも、クラスター外 (たとえば、コマンド ライン) からもアクセスできます。ただし、場合によっては、API にアクセスできるのは VPN 内からのみです。

ここでは Web UI を備えたツールを検討しているので、ユーザーがアクセスできるように UI とそのバックエンドを公開する必要があります。オプションは次のとおりです:

• kubectl proxy を使用して、ローカル マシンからクラスターへのプロキシを開きます (クラスターへのアクセスを参照)。
• kubectl port-forward を使用して、ローカル ポートをクラスター内の特定のポッドに転送します (「ポート転送を使用したクラスター内のアプリケーションへのアクセス」を参照)。
• LoadBalancer タイプの Kubernetes サービスを使用して、クラスターのアプリケーションにアクセスします (「サービスを使用したクラスター内のアプリケーションへのアクセス」を参照)。

あるいは、Web サーバーがユーザーのローカル マシン上で実行されている場合、これらのオプションについて心配する必要はありません。ただし、どちらの方法でも、ユーザーのマシン上で有効な kube 構成が必要です。

管理フロントエンド

それでは、よく使われるフロントエンドとその構築方法を見てみましょう。

Kubernetesダッシュボード

Kubernetes ダッシュボードは、クラスター内のさまざまな Kubernetes リソースを表示および管理するための一般的な Web UI です。最新の安定バージョン 2.7 では、バックエンドとフロントエンドの両方が同じコンテナーの一部になります。 Go バックエンドは、API と Angular UI アセットの両方を提供します。このデプロイメント戦略では、ユーザーは kubectl プロキシを使用して Web アプリケーションにアクセスする必要があります。

まだアルファ段階にある新しい 3.0 バージョンでは、デプロイメント戦略が変更され、バックエンドとフロントエンドはそれぞれ専用のコンテナーで実行されます。したがって、UI は別のポッドとポートで実行されているバックエンドにアクセスする必要があるため、kubectl プロキシ経由でのアクセスは機能しなくなります。代わりに、ここで説明するポート転送方法を使用する必要があります。

アルゴCD

ArgoCD は、Kubernetes 用の GitOps 継続的デリバリー ツールです。独自の API サーバーや Web UI など、複数のコンポーネントで構成されています。すべてのバックエンド コンポーネントは Go で記述されており、UI は React アプリケーションです。

Kubernetes ダッシュボードと同様に、サーバー (UI アセットを含む) はクラスター内にデプロイされるため、ユーザーはポート転送を実行するか、LoadBalancer を使用する必要があります。これについてはドキュメントに記載されています。

レンズ

Lens はデスクトップ UI ですが、それでも試してみるのは楽しかったです。 Electron、React、Typescript を使用して開発されています。 Lens アプリは Typescript Kubernetes クライアントを使用してクラスターに接続します。デスクトップ アプリケーションは明らかにクラスターの外部で実行されているため、ローカルで提供される kubeconfig を使用して接続します。

グラスキューブ

はい、かなり生意気な幕間ですが（私はそこで働いています）、楽しい代替案でもあります。 Glasskube パッケージ マネージャーの UI については、CLI コマンドを使用してローカルで Web サーバーを起動し、そこから UI アセットを提供します。私たちのユースケースではこの方法の方が理にかなっているため、この方法を採用することにしました。ユーザーが Glasskube UI を必要とするときはいつでも、長期的または短期的にオンデマンドでホストします。クラスター内で 24 時間 365 日実行する必要はありません。

発見する

多くのオープンソースの Kubernetes 管理 UI は、強力な Kubernetes-go クライアントを使用する Go バックエンドと、フロントエンドとしての JavaScript のシングルページ アプリケーションを使用して、同様にコーディングされています。ほとんどの場合、Web リソース (JS ファイルなど) はバックエンドと一緒に提供されます。つまり、1 つのコンテナーがバックエンドとフロントエンドの両方を提供します。実際、このように構築されていないものを見つけるのは難しいです。

クラスター内とクラスター外

このような Web ツールを展開する場合、選択肢は 2 つしかありません。

• Web サーバーはクラスター内のポッドにデプロイされ、プロキシ、ポート転送、またはイングレスを介してアクセスできます。
• Web サーバーはクラスターの外部、ユーザーのマシン上に直接 (ローカルに) デプロイされます。

Kubernetes クライアント (Go クライアントなど) は、次の例に示すように、開発者がクラスターに接続するための両方の方法をサポートしています。

依存するコード スニペット:

これらの簡略化された例は、こことここに示されている公式の例に大きく基づいています。

クラスター内でアプリケーションを実行するときに Kubernetes API に接続する方法を見てみましょう。

 import ( "context" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/client-go/kubernetes" "k8s.io/client-go/rest" ) func main() { // retreive the config for the cluster we are currently in: config, err := rest.InClusterConfig() if err != nil { panic(err.Error()) } // create the clientset for this config: clientset, err := kubernetes.NewForConfig(config) if err != nil { panic(err.Error()) } // do something with the clientset, eg getting all pods in the cluster: // pods, err := clientset.CoreV1().Pods("").List(context.TODO(), metav1.ListOptions{}) }

Go クライアント実装では、ポッドのサービス アカウントと環境変数 KUBERNETES_SERVICE_HOST および KUBERNETES_SERVICE_PORT を使用して、そのポッドが存在するクラスターを識別します。次に、クライアント セットを取得できる REST 構成オブジェクトを作成します。

同様に、クラスターの外部で実行する場合は、構成オブジェクトを作成する必要がありますが、この構成はローカルの kube-config から読み取られます。

 import ( "context" "flag" "path/filepath" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/client-go/kubernetes" "k8s.io/client-go/tools/clientcmd" "k8s.io/client-go/util/homedir" ) func main() { // get the passed (or default) kube config file path var kubeconfig *string if home := homedir.HomeDir(); home != "" { kubeconfig = flag.String("kubeconfig", filepath.Join(home, ".kube", "config"), "(optional) absolute path to the kubeconfig file") } else { kubeconfig = flag.String("kubeconfig", "", "absolute path to the kubeconfig file") } flag.Parse() config, err := clientcmd.BuildConfigFromFlags("", *kubeconfig) if err != nil { panic(err.Error()) } clientset, err := kubernetes.NewForConfig(config) if err != nil { panic(err.Error()) } // do something with the clientset, eg getting all pods in the cluster: // pods, err := clientset.CoreV1().Pods("").List(context.TODO(), metav1.ListOptions{}) }

同様に、Kubernetes Go クライアントは、kubeconfig ファイルを解析して構成を取得する簡単な関数を提供しており、その後、その構成を使用してクライアントセットを作成できます。

これらの単純な例を実行しようとすると、2 つのアプローチの間に 1 つの違いがあることに気付くでしょう。それは、イメージをビルドしてレジストリにプッシュし、クラスターにプルする必要がないため、ローカル ツールを実行する方が簡単だということです。

どれを選ぶべきでしょうか？

同様の方法で独自の Kubernetes UI を構築したいとします。ツールの Web サーバーをどこで実行するかを決める際には、考慮すべき点がいくつかあります。

• 配布: クラスター内でツールを実行するには、Docker イメージをビルドして配布する必要があります。代わりに、ユーザーに自分のマシンにインストールしてもらいたい場合は、ネイティブ バイナリを配布する必要があります。どちらの場合も、オンライン上には豊富なツールとリソースが存在します。
• 可用性: 何らかの理由でクラスターがダウンすると、ユーザーはクラスター内でホストされているツールにアクセスできなくなる可能性があります。これが次のポイントにつながります。
• ユーザー オンボーディング エクスペリエンス: これは例外的なケースかもしれませんが、すべてのコンポーネントがクラスターにインストールされる前に、ローカルでホストされている Web ツールを使用できます。つまり、新しいユーザー向けに何らかの UI オンボーディング フローを実装できるため、ツールのインストールとセットアップが容易になります。
• 互換性: 同じクラスターの複数のユーザーには、(ローカルでホストされている) ツールの異なるバージョンがインストールされている場合があります。クラスター内で実行されている Web サーバーが 1 つしかない場合、これは発生しません。
• 永続性: ツール固有のデータ (Kubernetes 以外のリソースなど) を保存する必要がある場合は、クラスター内 (たとえば、ConfigMap) に保存できます。ローカルに展開された変数の場合、設定などのユーザー固有のデータをユーザーのマシンに保存することもできます。この決定はユースケースによって大きく異なります。
• 開発者エクスペリエンス: 目立った違いはないと思われるかもしれませんが、クラスター内 Web サーバーを開発する場合、このサーバーは開発中に何らかの方法でクラスター外の構成方法をサポートする必要があることに注意してください。それ以外の場合は、変更のたびにイメージを構築してクラスターにデプロイする必要があります。

最終的には、ツールをクラスターの内側にデプロイするか外側にデプロイするかは完全にユーザー次第ですが、常にユースケースを考慮し、ツールが使用されるコンテキストを認識することが重要です。ユーザーに両方のオプションを提供することもできます。

Glasskube にとって、Glasskube クラスター コンポーネントをまだすべてセットアップしていない可能性のある新しいユーザー (特に Kubernetes の世界に不慣れなユーザー) 向けに、使いやすいインターフェースを提供したいのは当然のことです。これらのユーザーは、CLI コマンドと、ローカル Web サーバーをホストするサポート Web UI を提供することでサポートされます。

要約する

この記事では、Web UI を提供する Kubernetes ツールのいくつかを調査し、ソフトウェア エンジニアの観点からこれらのツールの Web 側面を分析しました。このようなツールを設計および開発するための万能のソリューションがないのは明らかですが、上記のリストが正しい方向へのヒントを与えてくれることを願っています。ソフトウェア エンジニアリングのあらゆる事柄と同様に、それは状況によって異なります。

最後にもう一つ宣伝します。私は Glasskube で働いており、不足している Kubernetes パッケージ マネージャーを構築しています。私たちの仕事に興味を持っていただけたら、ぜひスターを付けてください: glasskube/glasskube。コマンドラインを好む方のために、さまざまな CLI フレームワークを比較する記事も作成中です。それだけでは十分ではないかもしれませんが、HTML の使用はトレンドであり、皆さんの注目が必要なため、近いうちに HTML の使用に関する記事を書くかもしれません。タイトルがもう目に浮かびます。「一見旧式の技術を使ってコードベースを 95% 削減した方法」 - これまでにこのようなことは行われていないと思います ;)