はじめに

体感でここ1-2年、Kubernetes に Workspace という概念を導入し、マルチテナント環境を構成する方法が模索されています。今回は KubeCon + CloudNativeCon NA 2024 で紹介されていた、Kubernetes の Workspace（マルチテナント機能）に関する実装を 2 つほど紹介したいと思います。概要の紹介に留めるため、詳細については各セッションを確認してください。 ※なお、ここで紹介していないマルチテナント Kubernetes に関する技術は他にもたくさん（Open Cluster Management、vCluster、e.g.）あります。

Kubernetes API の前段に Proxy を配置することによる Workspace の実現
kcp-dev/kcp を用いた Workspace の実現

1. Kubernetes API の前段に Proxy を配置することによる Workspace の実現

Kubernetes に対して、複数の Namespace を束ねた Workspace という概念を導入し、クラスタをマルチテナント利用ができるようにする方法です。 Workspaceの概念を導入すると、Cluster-scoped/Workspace-scoped/Namespace-scopedの3種類の階層となるため、あるユーザーが従来の「（クラスタ上の）全てのリソースの一覧を取得する」リクエストを送った場合には、該当Workspaceに合致するリソース一覧が取得される形になります。そのため、単一のクラスタ上でNamespaceも利用可能な複数のテナントを払い出すことができるようになります。

実現方法としては、Kubernetes APIの全台にProxyサーバーを配置し、リクエストを中継する際に適切なSelectorを配置することで環境の分離を行います。例えば、下記の図では my-workspace には Namespace a、b、c が含まれているため、 my-workspace の全ての Namespace 上の Pod の list リクエスト（ユーザーからすると kubectl get pods -A）を行うと、後段の kube-apiserver に対するリクエストを行う際には Namespace に対する Selector が設定された状態でリクエストが行われます。これらの処理を実現するために、field selector での In/NotIn などの operator が利用できるようにする修正 #128154 などが検討されています。

この Proxy パターンの良いところとしては、HTTPリクエストをシンプルに書き換える構成であること、kube-apiserverやetcdに対する実装の変更の必要はないため高コストなencoding/decodingなどの処理が必要ないことが挙げられています。

また、 my-workspace Workspace を使っているユーザーが workspace-scoped なリソースを作成する場合には、現在は特定のNamespaceにリソースを作成することで擬似的に実現しています。（Kubernetes 自体が Workspace 自体をネイティブにサポートしているわけではないため。実際にCluster-scopeなリソースを作成しない。）

また、認証ついては Proxy では行わず、ExtraInfo として Workspace の情報を持った状態でkube-apiserver 側に処理を委譲します。そのため、Proxy 側はシンプルな状態を保ちます。実際に認証処理を行う kube-apiserver 側では、Workspace 用に実装された　Authorization Plugin を利用して認証処理を行います。そのため、kube-apiserver 側のオプションを変更する必要があります。

詳細については、Kubernetes Workspaces: Enhancing Multi-Tenancy with Intelligent Apiserver Proxying - James Munnelly & Andrea Tosatto, Apple のセッションを確認してください。

2. kcp-dev/kcp を用いた Workspace の実現

Kubernetes のコントロールプレーンの仕組みを汎用的に利用できるようにする kcp-dev/kcp プロジェクトがあります。kcp にはPodやDeploymentなどのAPIリソースは存在せず、軽量なコントロールプレーンの部分のみを提供します。kcpではこのコントロールプレーンの部分のみを用いて、Kubernetesライクな形でシステムを管理する手段や、マルチクラスタ/テナント向けの仕組みを実現することを目指しています。なお、合わせて KEP-4080 で kube-apiserver のコア部分に関してはgeneric control planeとしてパッケージが分離され、再利用しやすい形になっています。

kcpではetcdとgeneric control planeを利用して、単一etcd上に複数のcontrol plane（logical cluster）を構築します。つまり、複数のkube-apiserver相当の仕組みを単一クラスタ上で実現することができます（≒単一のシステム上で軽量なkube-apiserverを大量に立てることができる）。

このkcpでも workspace の概念が実現されています。仕組みとしては、Linux の directory/file と同じような概念を導入し、directoryがfileへのエントリを持てるのと同じように階層化された構造にlogical clusterを紐づけるような形となっています。

kcpも前述の Proxy を使った実装と同じように、パスベースでクラスタのエンドポイントが払い出されるような形になっています。

kcpでは、Linux がファイルシステムに対してボリュームをマウントできるのと同じように、この仕組みを利用して外部のクラスタを特定のworkspaceにマウントする機能なども提供されています。

kcpでは他にもcontroller-runtimeを拡張した複数のコントロールプレーン（マルチクラスタ）に対するコントローラーの例が公開されています。弊社でも複数のKubernetes Clusterに対するコントローラーなどが存在しているため、マルチクラスタ向けの拡張がcontroller-runtimeに導入されるきっかけになればと思い期待しています。

詳細については、Deep Dive Into Generic Control Planes and Kcp - Stefan Schimanski, Upbound & Mangirdas Judeikis, Cast AI のセッションを確認してください。

まとめ

Kubernetes Workspace を使いたいケースは、Kubernetes ベースにした Platform やサービスを提供するケースやマルチクラスタ・マルチクラウド/ハイブリッドクラウドなど、そこまで多くはないかもしれません。一方でそうしたシステムを実装する際には、柔軟に管理する手法として検討してみるのも良さそうです。また、kcpに関しては発表直後から個人的にはKubernetes 2.0や将来的な影響も大きいプロジェクトだと思っており、継続して追っています。今回の発表ではcontroller-runtimeに対するProgramming Modelの提案なども行われており、より将来に期待しています。