Kubernetesマルチテナンシー:モデル・分離レイヤー・ベストプラクティス

TL;DR

• Kubernetesのマルチテナンシーとは、チーム・プロジェクト・顧客ごとに専用クラスタを用意するのではなく、1つの共有クラスタ上で複数のテナントを稼働させることです。そして、分離は何ひとつ自動では行われません。
• 分離を支えるのは4つの中核レイヤー、すなわちネームスペース、RBAC、ネットワークポリシー、リソースクォータ(LimitRangeを含む)に加え、ワークロードレベルを守るPod Security Standardsです。ひとつでも欠けると、分離されているはずのテナントが他のテナント全体に影響を及ぼし始めます。
• 分離モデルは3つあります。ソフト(ネームスペースベース、最も低コスト、論理分離のみ)、ハード(vClusterやCapsuleなどの仮想クラスタ)、物理(専用ノードプールまたは専用クラスタ、最も強力な分離、最も高コスト)です。多くの組織は1つに統一するのではなく、3つを組み合わせて使っています。
• 障害の多くは初期設定のミスではなくドリフトに起因します。クォータやRBACを一度正しく設定した後、ワークロードの変化に合わせて見直さないことが原因です。

1つのKubernetesクラスタに10チームを載せた場合、デフォルトでは、チームAがチームBのシークレットを読んだり、チームBのCPUを食い潰したり、チームBも依存するコントロールプレーンをダウンさせたりすることを防ぐ仕組みは何もありません。Kubernetesのマルチテナンシーは、ネームスペース、RBAC、ネットワークポリシー、リソースクォータという4つの設定可能なレイヤーでこのギャップを埋めます。

マルチテナンシーを導入すれば、何十ものアイドル状態のコントロールプレーンに費用を払い続ける必要はなくなり、チーム・プロジェクト・顧客(「テナント」)間でインフラを共有できるようになります。ただしそれは、これらのレイヤーのすべてが実際に設定され、その状態が維持されている場合に限られます。Kubernetesはデフォルトではマルチテナントではありません。ネームスペースが引くのは論理的な境界であり、セキュリティ境界ではありません。レイヤーをひとつでも省略すると、分離されているはずのテナントがクラスタ上の他の全員に影響を及ぼし始めます。それがセキュリティ境界の問題であれ、単にあるワークロードが別のワークロードのCPUを食い潰す問題であれ、です。

なぜチームはクラスタを共有するのか

ほぼすべてのケースに共通する理由は、コスト、運用負荷、開発スピードの3つです。

10個のクラスタを運用するということは、10個のコントロールプレーン、10セットの過剰プロビジョニングされたノードプール、1日の大半をアイドル状態で過ごす10個のロードバランサーを抱えるということです。2〜3個の共有クラスタに集約すれば、このオーバーヘッドを直接削減できます。運用負荷も減ります。パッチを当てるクラスタは1つ、etcdの健全性を監視する場所も1つ、一貫性を保つべきポリシーも1セットで済み、運用するすべてのクラスタで同じ作業を繰り返す必要がなくなります。

開発スピードも同じくらい重要ですが、注目されることは多くありません。プラットフォームチームによる新規クラスタのプロビジョニングを待つチームは、数日待たされます。一方、既存のマルチテナントクラスタ上でネームスペースをリクエストするチームは、クォータとネットワークポリシーが最初から付与された状態で、セルフサービスで数分以内に取得できます。プラットフォームチームはこれを「Namespace-as-a-Service」と呼び、そもそもマルチテナンシーを構築する動機そのものになることも少なくありません。

3つのマルチテナンシーモデル

すべてのテナントが同じレベルの分離を必要とするわけではありません。どのモデルを選ぶかは、影響範囲(ブラストラディウス)と、コストおよび自ら引き受ける運用の複雑さとのトレードオフです。

多くの組織は1つのモデルを選んで終わりにはしません。信頼できる社内チームにはソフトマルチテナンシーを使い、ハードまたは物理分離は、それを必要とする一握りのテナント(外部顧客、GPUを多用するMLチーム、規制対象のワークロード)のために確保します。「マルチテナンシー」を単一のオン/オフ設定として扱うと、こうしたプロジェクトの多くが最初から過剰設計または過少設計になってしまいます。

ソフトマルチテナンシーを成立させる分離レイヤー

多くのチームはまずソフトマルチテナンシーから始めます。これは4つのレイヤーで構成され、そのすべてを自分で設定しなければなりません。デフォルトで有効になっているものは1つもありません。

ネームスペースは、他のすべてが紐づく境界を提供します。RBAC、クォータ、ネットワークポリシーのスコープを定める場所です。ただし単体で分離できるのは名前であって、挙動ではありません。ネームスペースAのPodはネームスペースBのPodと通信できますし、リソース制限のないワークロードは、ネームスペースBのPodも使うノードを食い潰すことができます。

RBACは、誰が何に対して操作できるかを決めます。デフォルト拒否から始め、各テナントのチームが実際に必要とする最小限のロールだけを付与し、個々のユーザーではなくグループにバインドすることで、人の入れ替わりに伴ってアクセス権が形骸化するのを防ぎます。テナントRBACの無秩序な増殖(ほぼ重複した何十ものRoleとRoleBindingが同期を失っていく状態)は、マルチテナントクラスタの監査が時間とともに難しくなる最大の原因のひとつです。

NetworkPolicyは、RBACとネームスペースだけでは防げない、テナント同士のネットワーク経由の到達を遮断します。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: team-a

多くのチームは、ネームスペースごとのデフォルト拒否ポリシーから始め、実際にネームスペースをまたいで通信が必要なものにだけ明示的な許可ルールを追加します。これがなければ、クラスタ上のどのPodもデフォルトで他のあらゆるPodに到達できます。ネームスペース自体はネットワーク境界を強制しません。

ResourceQuotaとLimitRangeは、1つのテナントがCPU、メモリ、オブジェクト数の面でクラスタの残りを枯渇させるのを防ぎます。ResourceQuotaはネームスペースが合計で消費できる量に上限を設け、LimitRangeはその内部でコンテナ単位の妥当なデフォルト値と最大値を設定します。マルチテナンシーとノイジーネイバー問題が直接交わるのがここです。クォータがクラスタを守れるのは、チームがその背後にあるrequestsとlimitsを正しく、実際の使用量に近い値で設定している場合だけです。緩すぎるクォータはノイジーネイバーを止められず、厳しすぎるクォータはチームの過剰なリソース要求を招き、マルチテナンシーが約束したはずの集約による節約を無駄にします。

Pod Security Standardsは、ワークロードレベルでこれを補完します。ネームスペース単位で特権コンテナ、ホストネットワーク、root権限を制限し、あるテナントのPodを侵害した攻撃者がノードやクラスタの他の部分へ権限昇格できないようにします。