1. namespaceは「境界」ではなく「棚」でしかない
Kubernetesのマルチテナンシーを設計するとき、最初に思いつくのは「テナントごとにnamespaceを分ければいい」という発想だろう。実際、多くのチームがこの方法で複数の事業部やクライアントのワークロードを1つのクラスタに同居させている。
しかし、Kubernetes公式ドキュメントは明確にこう釘を刺している。namespace分離モデルは「他の複数のKubernetesリソース、ネットワークプラグイン、およびセキュリティベストプラクティスの厳格な遵守を必要とする」と。つまりnamespaceそのものは、リソース名を分離し、RBACやNetworkPolicyを適用する「スコープ」を提供するだけであり、それらのポリシーを実際にテナントごとに正しく設定し続ける作業は、依然として運用者の手作業に委ねられている。
テナント数が5、10と増えていくと、この「手作業での一貫性維持」が破綻し始める。あるnamespaceにはNetworkPolicyを設定し忘れ、別のnamespaceにはResourceQuotaの上限が古い値のまま残っている、といったポリシードリフトが典型的に発生する。Sysdigのブログも、コントロールプレーン/API、ホスト、ネットワークという3つの分離境界それぞれで、RBACの最小権限設計やNetworkPolicyの明示的な適用が個別に必要であることを指摘している。
Kubernetesマルチテナンシーは「スペクトラム」である
Kubernetes公式ドキュメントは、マルチテナンシーを「ソフト」と「ハード」の二択ではなく、要件に応じて選べる隔離技術のスペクトラムとして捉えるべきだと説明している。テナント間に一定の信頼関係がある社内の複数チームであればソフトな隔離で十分だが、信頼できない複数顧客を収容するSaaS的な用途では、より強い隔離（ハードマルチテナンシー）が必要になる。この前提を理解しないまま「namespaceを切っただけ」で満足してしまうことが、事故の温床になる。
このポリシー管理の手間は、マネージドKubernetesを選ぶ段階から見直せる部分でもある。Kuboのようにテナント管理を運用の前提として設計された基盤であれば、この後で紹介する仕組みを自前で組み立て直す必要がなくなる。
2. Capsuleという答え — Tenant CRDで「複数namespaceのグループ」を宣言する
この課題に対して、CNCF Sandboxプロジェクトとして採択されたCapsuleは、明快な解決策を提示している。Capsuleは2022年12月13日にCNCF Sandboxレベルで受け入れられた（CNCF Capsuleプロジェクトページ）、Kubernetesクラスタに「マルチテナントかつポリシーベースの環境」を実装するOSSだ。
Capsuleの中核はTenantというカスタムリソース（CRD）だ。GitHubの公式リポジトリによれば、Tenant CRDは複数のnamespaceを「軽量な抽象化」の中に集約する。管理者はテナント単位でNetworkPolicy、Security Policy、ResourceQuota、LimitRange、RBAC設定を定義するだけでよく、それらはそのテナントに属するすべてのnamespaceに自動的に継承される。namespaceを1つ追加するたびにポリシーを再設定する必要がない設計だ。
さらに重要なのが「セルフサービス委譲」という発想だ。テナントに割り当てられた境界の中であれば、開発チームはクラスタ管理者の介入なしにnamespaceの作成やアプリケーションのデプロイを自律的に行える。Capsuleは「upstreamのKubernetesのみを活用する、最小主義的なマイクロサービスベースのエコシステム」として設計されており（CNCF Capsuleプロジェクトページ）、admission webhookとCRDだけで実現している点が特徴だ。クラスタ管理者はテナントの枠組みだけを設計し、日々のnamespace管理は各チームに委ねられる。これにより、運用負荷とガバナンスの両立が可能になる。FinOps系メディアZestyの解説でも、Capsuleは「複数のnamespaceをテナントと呼ばれる軽量な仮想クラスタにグループ化し、効率的で安全なワークロード分離を実現するオペレーター」と位置づけられており、クラスタ管理者権限を渡さずにテナント単位でポリシーを強制できる点が利点として挙げられている。
3. 「ソフト分離」と「ハード分離」— vCluster・HNCとの違いを整理する
Capsule以外にも、Kubernetesのマルチテナンシー課題に取り組むOSSは複数存在する。それぞれ「分離の強さ」と「運用コスト」のトレードオフが異なるため、整理しておきたい。
Capsule — ソフトマルチテナンシー
Capsuleはnamespaceとadmission webhookを軸にした「ソフト」な分離アプローチだ。vClusterの公式ブログ比較記事は、namespace単位の多重テナンシーには「真のテナント分離が欠けており、ClusterRoleやPersistentVolumeといったグローバルに共有されるリソースが残る」という限界があると指摘した上で、Capsuleがこの弱点をポリシーの自動継承によって緩和していると位置づけている。同じAPIサーバー・同じコントロールプレーンを複数テナントで共有するため、リソースオーバーヘッドが小さいことがメリットだ。
vCluster — 仮想コントロールプレーンによるハード分離
一方vClusterは、テナントごとに専用の仮想コントロールプレーン（独自のAPIサーバー・controller-manager・scheduler）をホストクラスタの中に立てるアプローチを取る。ワークロードの実体はホストクラスタに同期されるが、テナントは自分専用のKubernetes APIを持つため、CRDやAPIバージョンの違いをテナントごとに許容できる。その代わり、コントロールプレーンを複数走らせる分、リソース消費と運用の複雑性は増す。金融機関や医療機関のようにテナントごとのデータ主権や完全な閉域運用が求められる場合は、Kubo On-PremiseのようにAir-Gapped環境を前提にした基盤との組み合わせも選択肢になる。
HNC — namespaceの階層継承
Hierarchical Namespace Controller（HNC）は、namespaceに親子関係を持たせることで、RBACのRoleBindingやResourceQuotaを子namespaceへ自動伝播させる仕組みだ。通常はクラスタレベルの権限が必要なnamespace作成を、チームのnamespace配下に委譲できる点はCapsuleと似ている。ただし、vClusterのブログ比較でも指摘されている通り、ClusterRoleやPersistentVolumeのようなクラスタスコープのリソースは階層構造の外側にあり、依然としてグローバルな存在として残る。HNCはあくまで「namespace同士の構造化・管理ツール」であり、Capsuleのような包括的なテナント境界の強制までは踏み込んでいない。
4. どのアプローチを選ぶべきか — 判断基準
3つのアプローチは「分離の強さ」と「運用コスト」という2軸で整理できる。
- HNC: 運用コストは最も低いが、クラスタスコープのリソースは分離できない。社内の同じ信頼レベルのチーム同士でnamespace管理を委譲したい場合に向く
- Capsule: namespace分離の弱点をポリシー自動継承で補い、コストと分離のバランスが良い。信頼関係のある複数事業部・複数チームでのクラスタ共有に適する
- vCluster: 最も強い分離（仮想コントロールプレーン単位）を提供するが、運用の複雑さとリソースオーバーヘッドが増える。信頼できない複数顧客を収容するSaaS的な用途や、テナントごとに異なるK8sバージョン・CRDが必要な場合に向く
Google CloudのGKEマルチテナンシーのベストプラクティスでも、テナントごとの専用namespace作成、NetworkPolicyによる通信制御、Admission Controlによるセキュリティ基準の強制、namespace単位のResourceQuota設定という組み合わせが基本形として推奨されている。つまりCapsuleが自動化している内容は、本来GKEのようなマネージドサービス上でも手動で組み立てなければならない構成要素そのものだ。
自前でこの構成をゼロから設計・運用するのは、決して小さくない工数がかかる。ここに、マネージドKubernetesの基盤機能としてテナント管理を組み込んでおく価値がある。KuboはRancherベースの管理基盤を標準搭載しており、マルチクラスタ・マルチテナントの状態を可視化しながら運用できる。K3sという軽量なKubernetesディストリビューションをベースにしているため、EKS/AKSと比べてコスト効率も高い。テナントごとのポリシー管理を最初から仕組み化したいチームにとって、選択肢の一つになるはずだ。
5. まとめ
namespace分離は、Kubernetesマルチテナンシーの出発点ではあっても、終着点ではない。ポリシーをテナント単位でどう一貫して強制するかという設計問題を解決しない限り、テナント数が増えるたびに事故のリスクは積み上がっていく。
Capsuleは、既存のnamespaceモデルの上にTenant CRDという軽量な抽象化を重ね、NetworkPolicy・ResourceQuota・RBACの自動継承とセルフサービス委譲を実現する現実的な選択肢だ。より強い分離が必要ならvCluster、既存のnamespace構造を階層化したいだけならHNCという選択肢もある。それぞれのトレードオフを理解した上で、自分たちのクラスタに必要な「分離の強さ」を見極めることが、マルチテナント設計の第一歩になる。
複数の事業部やクライアントで1つのKubernetesクラスタを共有する構想があるなら、こうしたテナント分離の仕組みをゼロから構築するのではなく、マネージド基盤に任せるという選択肢も検討する価値がある。Kubo Cloudや、より厳格なデータ主権が求められる環境向けのKubo On-Premiseについて、お問い合わせから相談してみてほしい。