実稼働環境で Kubernetes を実行している人々から最も頻繁に寄せられる不満の 1 つは、マルチテナントがいかに難しいかということです。

企業は主に、名前空間ベースのマルチテナントとクラスターベースのマルチテナントという 2 つのモデルを使用して、Kubernetes クラスターを複数のテナントと共有します。

最初に普及するマルチテナントモデルは、名前空間の分離に基づいています。このモデルでは、単一のテナント（マイクロサービスを開発するチームなど）は、クラスター内の1つまたは少数の名前空間のみを使用できます。このモデルは一部のチームには有効ですが、欠点もあります。

まず、チームメンバーが名前空間内のリソースのみにアクセスできるように制限すると、カスタムリソース定義（CRD）などのクラスター内のグローバルオブジェクトを管理できなくなります。これは、KubeflowやArgo Pipelines上で構築するチームなど、CRDを直接的または間接的に操作するチームにとって大きな問題となります。

第二に、長期的なメンテナンスにおけるより大きな問題は、名前空間分離ルールに継続的に例外を追加する必要があることです。例えば、ネットワークポリシーを使用して単一の名前空間をロックダウンする場合、管理者は最終的に一部のチームが複数の相互接続されたマイクロサービスを実行する必要があることに気付く可能性があります。クラスター管理者は、このような状況に備えて例外を追加し、追跡し、これらの特殊なケースをすべて管理する必要があります。さらに、Kubernetesを採用するチームが増えるにつれて、この複雑さは時間とともに増大します。

もう一つの標準的なマルチテナントモデルでは、クラスタレベルでの分離を採用していますが、これはさらに大きな問題を引き起こします。この場合、各チームは独自のクラスタを持ち、複数のクラスタ（開発、テスト、UAT、ステージングなど）が存在する場合もあります。

クラスター分離を使用する場合の直接的な問題は、最終的には多くのクラスターを管理する必要があり、それが複雑になる可能性があることです。これらのクラスターはすべて、夜間や週末などのオフピーク時であっても、高価なクラウドコンピューティングリソースを必要とします。

Holly Cummins 氏が KubeCon 2021 の基調講演で指摘したように、このクラスターの増殖が環境に及ぼす影響は危険です。

つい最近まで、クラスタ管理者は2つの不十分なモデルから、ユースケースと予算に適したモデルを選択する必要がありました。しかし、Kubernetesは仮想クラスタという新しいコンセプトを提供し、多くのユースケースに適しています。

仮想クラスタの概要

仮想クラスターは、テナントに対してプライベートクラスターとして表示される共有Kubernetesクラスターです。2020年、Loft Labsチームは、仮想Kubernetesクラスターのオープンソース実装であるvclusterをリリースしました。

vclusterを使用すると、エンジニアは共有Kubernetesクラスタ上に仮想クラスタを構成できます。これらの仮想クラスタは、基盤となるクラスタの通常の名前空間内で実行されます。そのため、管理者は仮想クラスタを起動し、テナントに配布することができます。

組織がすでに名前空間ベースのマルチテナントを使用しているものの、ユーザーが単一の名前空間に制限されている場合、テナント ユーザーは名前空間内でこれらの仮想クラスターを自分で起動することもできます。

これは、前述の 2 つのマルチテナント アプローチの利点を組み合わせたものです。テナントは単一の名前空間に限定され、仮想クラスター内で完全な制御権を持っているため例外は必要ありませんが、仮想クラスター外部へのアクセスは非常に制限されています。

クラスタ管理者と同様に、ユーザーは仮想クラスタ内で完全な制御権を持ちます。これにより、基盤となる共有ホストクラスタ上の他のテナントに影響を与えることなく、仮想クラスタ内であらゆる操作を実行できます。

vcluster は、ホストクラスタ上の名前空間内のポッド内で Kubernetes API サーバーとその他のコンポーネントを実行することで、この仕組みを実現しています。ユーザーは、基盤となるクラスタの API サーバーではなく、名前空間内の仮想クラスタ API サーバーにリクエストを送信します。仮想クラスタの状態は、基盤となるクラスタから完全に独立しています。仮想クラスタ内で作成されたデプロイメントや Ingress などのリソースは、仮想クラスタのデータストアにのみ存在し、基盤となるクラスタの etcd には永続的に保存されません。

名前空間分離モデルやクラスター分離モデルと比較すると、このアーキテクチャには大きな利点があります。

1. ユーザーは仮想クラスターの管理者であるため、クラスター全体のオブジェクト (CRD など) を管理でき、名前空間の分離による大きな制限を克服できます。

2. ユーザーは個別のAPIサーバーと通信するため、一般的な共有クラスターよりもトラフィックの分離性が向上します。また、高トラフィックのクラスターにおけるAPIリクエストのスケーリングを支援するフェデレーションメカニズムも提供されます。

3. 仮想クラスターは構成と解体が迅速に行えるため、ユーザーは完全に一時的な環境を活用でき、必要に応じて多数の一時環境を開始できます。

仮想クラスターを使用するにはどうすればいいですか?

仮想クラスタには様々なユースケースがあります。以下は、多くのvclusterユーザーが採用しているユースケースの一部です。

開発環境

開発環境の設定と管理は、現在vclusterの最も一般的なユースケースです。Kubernetesクラスターで実行されるサービスを開発する場合、開発中にアプリケーションをどこかで実行する必要があります。Docker Composeなどのツールは開発環境向けのコンテナのオーケストレーションに使用できますが、Kubernetesクラスター専用にコードを作成する開発者は、本番環境でのサービス実行に近いエクスペリエンスを得ることができます。

ローカル開発の別のオプションとして、Minikube や Docker Desktop などのツールを使用して Kubernetes クラスターを構成することもできますが、これにはいくつかの欠点があります。

開発者は、このローカル クラスター アーキテクチャを所有して管理する必要がありますが、これは簡単ではなく、時間がかかります。

さらに、これらのローカルクラスターには相当なコンピューティング能力が必要になる可能性があり、ローカル開発マシンでそれを実現するのは困難です。開発中にラップトップがかなり熱くなることは周知の事実ですから、Kubernetesを追加するのは得策ではないかもしれません。

これらの問題は、共有開発クラスター内で仮想クラスターを開発環境として実行することで解決できます。さらに、前述のように、vcluster は迅速に設定および削除できます。

管理者は、単一の「kubetctl」コマンドを使用して基盤となるホスト名前空間を削除するか、コマンドラインインターフェースツールが提供する「vcluster delete」コマンドを実行してvclusterを削除できます。インフラストラクチャとツールのスピードは開発ワークフローにおいて非常に重要です。開発者のサイクルタイムを短縮することで、生産性と健全性が向上します。

•CI/CDパイプライン

継続的インテグレーション/継続的開発（CI/CD）は、仮想クラスタのもう一つの主要なユースケースです。パイプラインは通常、テスト対象システム（SUT）をテストスイートを実行するように構成します。チームは、テストの妨げとなる可能性のある負担のない、新しいシステムを好む傾向があります。

チームが多数のテストを含む長いパイプラインを実行する場合、テスト実行中にシステム基盤テスト（SUT）が複数回構成および破棄される可能性があります。クラスターの構成に多くの時間を費やすユーザーは、Kubernetesクラスターの起動に時間がかかることに気付いているかもしれません。最先端のパブリッククラウドでさえ、20分以上かかることがあります。

vcluster を使用すると、仮想クラスターを迅速かつ簡単に構成できます。新しい仮想クラスターを構成するために `vcluster create` コマンドを実行する際、舞台裏で必要なのは Helm グラフの実行といくつかのポッドのインストールだけです。このプロセスは通常、わずか数秒で完了します。長時間実行されるテストスイートを実行している人なら誰でも、このプロセスを短縮することで QA チームとエンジニアがフィードバックを受け取る速度が大幅に向上することをご存知でしょう。

さらに、企業は vcluster のスピードを活用して、ワークショップや顧客トレーニング用の環境の作成など、大規模クラスターを構成するその他のプロセスを改善できます。

• 異なるKubernetesバージョンのテスト

前述の通り、vcluster は基盤となるホスト名前空間で Kubernetes API サーバーを実行します。デフォルトでは K3s (Lightweight Kubernetes) A​​PI サーバーを使用しますが、k0s、Amazon Elastic Kubernetes Service、または通常のアップストリーム Kubernetes API サーバーも使用できます。

vcluster を構成する際に、Kubernetes のバージョンを指定して実行できるため、さまざまな可能性が広がります。ユーザーは以下のことが可能です。

• 仮想クラスターで新しいバージョンの Kubernetes を実行し、新しい API サーバーでアプリケーションがどのように動作するかを確認します。

• 開発中またはエンドツーエンドのテスト中に、異なるバージョンの Kubernetes を使用して複数の仮想クラスターを実行し、さまざまな Kubernetes ディストリビューションとバージョンのセットにわたってオペレーターをテストします。

補充する

Kubernetesのマルチテナンシーに完璧なソリューションは存在しないかもしれませんが、仮想クラスタは現在のテナントモデルの多くの問題を解決します。共有クラスタを必要としながらも、柔軟な管理も求めるユーザーにとって、vclusterのスピードと使いやすさは多くのシナリオに最適です。この記事で説明した例外以外にも、vclusterは数多くのユースケースをサポートしています。

詳細については、vcluster.com をご覧ください。また、コードについて詳しく知りたい場合は、GitHub リポジトリ (https://github.com/loft-sh/vcluster) からダウンロードできます。

原題:仮想 Kubernetes クラスター: マルチテナントのための新しいモデル、著者: Lukas Gentele