単一Kubernetesクラスタで実現する AI/ML 向けクラウドサービス

PFNでは、AI/MLワークロード向けのクラウドサービスである「Preferred Computing Platform (PFCP)」をマルチテナントKubernetes基盤として提供しています。これらのワークロードで用いられるMN-CoreやGPUは貴重な計算リソースであるため、それらを無駄なく・効率よく利用することが重要です。クラスタをテナントごとに構築する場合は、個々のクラスタのリソースの空きを他テナントに融通しづらく、計算リソースの利用効率が低下します。PFCPは全テナントが同一のマルチテナント基盤を利用することでこの課題を解決し、より高い利用効率を実現します。一方で、同一の基盤上でテナントを安全かつ公平に収容する様々な仕組みが求められます。

本セッションでは、このようなマルチテナント基盤で重要となる、Kubernetes APIレベルでの権限分離とその強制、同一ホスト上でのプロセス・データの分離、同一ネットワーク内での通信分離等のアイソレーション技術、限られた計算リソースの公平制御、および課金システムについて、その実現のための技術と設計思想について説明します。

イベントサイト: https://event.cloudnativedays.jp/cndw2025/talks/2725

Transcript

1. 単一クラスタで実現する AI/ML 向け マルチテナント基盤への挑戦 2025年11月19日 CloudNative Days Winter 2025 株式会社 Preferred Networks 須田 一輝、小松 享
2. 小松 享 / @utam0k • Preferred Networks, Inc. / エンジニア • エンジニアリングマネージャー • OSS 活動 ◦ youki の作者 ◦ OCI Runtime Specification メンテナ ◦ Kubernetes SIG-Scheduling Reviewer • コミュニティ ◦ CNCJ Board Member ◦ CNCF Ambassador
3. 須田 一輝 / @superbrothers • Preferred Networks, Inc. / エンジニア • Preferred Computing Platform (PFCP) 開発リード • Kubernetes Meetup Tokyo 共同主催者 • オライリー書籍 監訳 ◦ 「Kubernetes で実践する クラウドネイティブ DevOps」 ◦ 「入門 Prometheus」
4. 4 1. PFN の事業 2. PFN の AI・ML ワークロード向けクラウドサービス Preferred Computing Platform (PFCP) 3. 単一クラスタで実現する AI/ML 向けマルチテナント基盤への挑戦 ◦ Kubernetes オブジェクトの操作を制限・強制する ◦ 同一ノード上でのプロセス・データの分離 ◦ 限られた計算リソースの公平制御 アジェンダ
5. 5 PFN の事業
6. 6 Preferred Networks (PFN) 会社概要 設立 本社 代表取締役 従業員数 事業内容 主要子会社 出資企業 (五十音順） 2014年3月26日 東京都千代田区 西川徹（最高経営責任者） 岡野原大輔（最高技術責任者） 約350名（2025年2月） AIチップ、計算基盤、生成AI基盤モデルなどのAI関連技術を 活用したソリューション・製品の開発・販売および研究開発 Matlantis株式会社（2021年6月設立、2025年7月Preferred Computational Chemistryから社名変更） 株式会社Preferred Robotics（2021年11月設立） 株式会社Preferred Computing Infrastructure（2025年1月設立） SBIグループ　NTT株式会社　ENEOSイノベーションパートナーズ合同会社　株式会社講談社 信越化学工業株式会社　SUMISEI INNOVATION FUND　積水ハウス投資事業有限責任組合　中外製薬株式会社 TBSイノベーション・パートナーズ3号投資事業組合　TEL Venture Capital, Inc.　東映アニメーション株式会社 トヨタ自動車株式会社　株式会社日本政策投資銀行　株式会社博報堂DYホールディングス　株式会社日立製作所 ファナック株式会社　株式会社みずほ銀行　三井住友信託銀行株式会社　三井物産株式会社　三菱商事株式会社 三菱UFJ信託銀行株式会社　株式会社ワコム　他 ミッション： 現実世界を計算可能にする https://www.preferred.jp
7. 7 PFNは、チップ、計算基盤、生成AI基盤モデル、ソリューション・製品まで、AI技術のバリュー チェーンを垂直統合し、ソフトウェアとハードウェアを高度に融合することで、競争力の高い技術の 開発および産業応用を進めています。 PFNの事業: AI技術のバリューチェーンを垂直統合 AIソリューション・製品 計算基盤 AIチップ 生成AI基盤モデル 様々な産業向けのAIソリューション・製品 MN-Core MN-Core 2 GPUクラスタ MN-3 (MN-Coreクラスタ) PLaMo Prime（国産LLM） PLaMo Lite（エッジ向けSLM） MN-Core 次世代 MN-Core 2を 計算資源とした クラウドサービス 物質のエネルギー計算モデル PFP 生成AI（推論）向け MN-Core L1000 （2027年提供予定）
8. 8 PFN の AI・ML ワークロード向け クラウドサービス Preferred Computing Platform （PFCP）
9. 9 • PFN が構築、運用する AI・ML ワークロード向けのクラウドサービス ◦ https://pfcomputing.com/ ◦ ユーザガイド: https://docs.pfcomputing.com/ • PFN のエンジニア・リサーチャが使用する環境と同じものを提供 ◦ これまで社内向けに計算基盤を開発運用してきた経験を元に開発 • 強力な計算ボードと高速なネットワーク ◦ 独自開発したアクセラレータ MN-Core™ シリーズ等を提供 ◦ 深層学習に最適化された高速なネットワークで相互に接続 誰もが MN-Core™ シリーズを利用できる AI クラウドサービス Preferred Computing Platform (PFCP)
10. 10 • 実験も学習も推論も ◦ 実験環境としてマネージドな JupyterLab を提供 ◦ 学習だけでなく、推論サーバの運用まで幅広いワークロードをサポート • オープンソースを採用 ◦ コンテナ実行環境にKubernetes を採用 (Linux Foundation / CNCF) ◦ AI・ML ワークロード向けに独自に拡張 • リソース使用状況の可視化 ◦ ワークロード状態を観測するためのモニタリングサービスも付随 誰もが MN-Core™ シリーズを利用できる AI クラウドサービス Preferred Computing Platform (PFCP) 管理コンソール ワークロード・計算資源監視 対話型実験環境 分散学習・LLM 推論
11. 11 2つの利用形態を計算ノードでサポートします。 • 専有ノード: 月額課金でテナントが専有する • 共有ノード: 従量課金で複数のテナントが共有する *1 計算ノードの利用形態: 専有ノードと共有ノード *1: 共有ノードは専有ノードとは異なり、複数の組織のワークロードが同じノード上でカーネルを共有します。 テナント間のセキュリティ境界についてより強固な分離が必要な場合は、専有ノードの利用を推奨します。 共有ノードでは追加のセキュリティ対策として、Linux の User Namespaces の使用を強制し、ホストからコンテナの UID/GID の分離を実施しています。 計算ノードの種類と比較 - Preferred Computing Platform（PFCP）ユーザガイド
12. 12 • GENIAC 第1期 ◦ 1000億パラメータの LLM (PLaMo 100B) を開発 *1 • GENIAC 第2期 ◦ 310億パラメータ規模の LLM (PLaMo 2 31B) を開発 *2 ◦ AWS SQS と連携した大規模な事前学習データセット生成システムを構築 *3 • その他 LLM 評価のための推論サーバを複数実行 • NVIDIA H100 を使用 PFCP 利用事例: Preferred Elements (PFE) 様 大規模データ生成システムの概略 *1 GENIAC第1サイクルの開発成果として 大規模言語モデル PLaMo-100B-Pretrained を公開 - 株式会社Preferred Networks *2 大規模言語モデルの次期バージョン PLaMo 2 31Bの事前学習 - Preferred Networks Research & Development *3 LLMによる大規模な事前学習データセット生成システムの構築と運用 - Preferred Networks Research & Development
13. 13 日本語を入力・出力言語とするテキスト翻訳に特化して PFNが フルスクラッチ開発した大規模言語モデル（LLM） PLaMo™翻訳 のサービス提供*1 PFCP 利用事例: PLaMo 翻訳 *1 日本語の翻訳に特化したPLaMo翻訳のサブスクリプション サービスを正式リリース - 株式会社Preferred Networks PLaMo翻訳 : https://translate.preferredai.jp PLaMo 翻訳 システム構成概略 Google Cloud Cloud Run vLLM スポンサブースに出展中！
14. 14 単一クラスタで実現する AI/ML 向け マルチテナント基盤への挑戦
15. 15 なぜマルチテナントで Kubernetes を使用するのか MN-Core や GPU といった貴重な計算リソース（アクセラレータ）を 無駄なく・効率よく利用するため • テナントごとにクラスタを提供する場合、1つのノード上の 計算リソースをテナント間で共有することが難しい （共有ノードの実現が難しい） ◦ 仮想ノード (Virtual Kubelet 等) の選択肢もあるが経験がない • 社内向けにマルチテナントで計算基盤を提供してきた経験から マルチテナントからはじめることを選択 ◦ 一方でマルチテナントではテナント間の分離が頑張りどころ ◦ 将来的に要望に応じてシングルテナントで提供することもできる
16. 16 1. Kubernetes オブジェクトの操作を制限・強制する ◦ テナント単位でオブジェクト数を制限する ◦ Validating/MutatingAdmissionPolicy (VAP、MAP) の活用 ◦ VAP、MAP のポリシをテストする 2. 同一ノード上でのプロセス・データの分離 ◦ 1ノードに複数のテナントの Pod が動く場合のセキュリティ ◦ UserNamespace の活用 ◦ NRI(Node Resource Interface) の活用 3. 限られた計算リソースの公平制御 ◦ テナント間、テナント内でのリソースの制御 ◦ Kueue の活用 テナント間の分離: 他のテナントの影響を受けないように守る
17. 17 Kubernetes オブジェクトの操作を 制限・強制する
18. 18 PFCP での Kubernetes Namespace の設計 マルチテナントでもユーザが Namespace を作成できるようにしたい • Namespace は Cluster レベルのリソースであり、通常は クラスタ管理者が作成する • マルチテナントクラスタではテナントの管理者は Namespace レベルの 管理者権限しか付与できないため、Namespace を作成できない • 本番用・ステージング用や特定のチーム用・メンバ用など、様々な用途 で Namespace を使い分けることが Kubernetes のベストプラクティス
19. 19 org-pfn.tree.hnc.x-k8s.io/depth=1 org-pfn--stg hierarchical-namespaces (HNC): 階層型の Namespace と操作の委譲 テナント管理者が Namespace を作成できる org-pfn.tree.hnc.x-k8s.io/depth=0 org-pfn • namespace に階層情報をラベルとして付与 ◦ NetworkPolicy、Kubernetes コントローラの分離で活用 • RBAC 等のリソースを subnamespace に自動作成 ◦ テナント管理者に自動的に管理者権限を付与 root namespace subnamespace (テナント管理者が管理) org-pfn.tree.hnc.x-k8s.io/depth=1 org-pfn--prod allow-inside-org org-pfn.tree.hnc.x-k8s. io/depth ラベルを持つ namespaces 内の pods 間の 通信を許可する K8s コントローラ org-pfn.tree.hnc.x-k8s. io/depth ラベルを持つ namespaces 内のリソース を調整する
20. 20 大量の Kubernetes オブジェクト作成の影響（etcd 圧迫）から守る • ビルトインの ResourceQuota で制限 ◦ Namespace 単位でオブジェクト数を制限できる ◦ PFCP ではテナント管理者がセルフで Namespace を作成できる → テナント単位で制限しなければならない • カスタムリソースの HierarchicalResourceQuota (HRQ) で制限 ◦ 自身を含む紐づく Namespaces 内のオブジェクト数を制限できる ◦ root namespace に HRQ を作成してテナント単位で制限する テナント単位でオブジェクト数を制限する
21. 21 subnamespace 名にテナント名のプレフィクスを持たせることで 他のテナントの namespace と名前衝突を避ける • 従来、オブジェクトの検証は Webhook サーバを使用する Validating Admission Webhook で実現していた ◦ Webhook サーバの実装やサードパーティアドオン含め運用が必要 ◦ 外部サーバへのリクエストによるパフォーマンスが課題 ✅ v1.30 で GA した ValidatingAdmissionPolicy (VAP) で解決！ subnamespace 名のプレフィックスを強制する org-pfn--prod
22. 22 apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: org-namespace-must-be-prefixed-by-orgname spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["hnc.x-k8s.io"] apiVersions: ["*"] operations: ["CREATE"] resources: ["subnamespaceanchors"] variables: - name: orgName expression: namespaceObject.metadata.labels['org.preferred.jp/name'] - name: namePrefix expression: "'org-' + variables.orgName + '--'" validations: - expression: "object.metadata.name.startsWith(variables.namePrefix)" messageExpression: "'metadata.name must be prefixed by `' + variables.namePrefix + '`'" - expression: "!object.metadata.name.matches('^' + variables.namePrefix + '.*--')" messageExpression: "'subnamespace name must not contain `--` except for orgName delimiter'" Webhook サーバの実装なしに これだけで実現できるけど 正しく動くかどうかが不安... ValidatingAdmissionPolicy で subnamespace 名を検証する namespace の情報も参照できる subnamespaceanchors リソースの作成が対象 1. org 名のプレフィックスを持つ 2. デリミタ以外で -- を使用していない
23. 23 Pod の nodeSelector で専有ノードへのスケジュールを強制する • 従来、オブジェクトの変更は Webhook サーバを使用する Mutating Admission Webhook で実現していた ◦ Webhook サーバの実装やサードパーティアドオン含め運用が必要 ◦ 外部サーバへのリクエストによるパフォーマンスが課題 ✅ v1.34 で Beta に昇格した MutatingAdmissionPolicy (MAP) で解決！ （デフォルト無効） テナントの専有ノードに pods を必ずスケジュールする org-pfn 専有ノード labels: node.preferred.jp/reserved=org-pfn org-pfn--prod/example-pod nodeSelector: node.preferred.jp/reserved=org-pfn
24. 24 apiVersion: admissionregistration.k8s.io/v1alpha1 kind: MutatingAdmissionPolicy metadata: name: reserved-node spec: failurePolicy: Fail reinvocationPolicy: IfNeeded matchConstraints: resourceRules: - apiGroups: [""] apiVersions: ["v1"] operations: ["CREATE"] resources: ["pods"] variables: - name: orgName expression: namespaceObject.metadata.labels['org.preferred.jp/name'] mutations: - patchType: ApplyConfiguration applyConfiguration: expression: > Object{ spec: Object.spec{ nodeSelector: Object.spec.nodeSelector{ node.preferred.jp/reserved: 'org-' + variables.orgName, } } } Webhook サーバの実装なしに これだけで実現できるけど 正しく動くかどうかが不安... （本日2回目） ✅ kaptest ツールでテストできます！ MutatingAdmissionPolicy で Pod spec.nodeSelector を強制する pod リソースの作成が対象 JSONPatch も使えます MAP は v1.34 でもいくつがバグがあることを 確認しているので、まだ使い始めるのは やめたほうがよいかもです (k/k#134808)
25. 25 VAP・MAP のマニフェストに対してテストケースとなるリソースの マニフェストを使ってポリシの評価結果を静的にテストできる。 • 2024年の PFN 2週間インターンシップにおいて開発 • OSS として GitHub で公開 ◦ https://github.com/pfnet/kaptest • 2024年去年の CNDW で紹介 ◦ 実践/先取り「入門 Kubernetes VAP/MAP」 • PFCP で使用するポリシの検証に使用 • 先日 v0.2.0 をリリースし、MAP のサポートを追加 🚀 ◦ それに伴い、kaptest.yaml のフィールド名を変更 VAP・MAP のテストツール “kaptest” 安定したら設定ファイルがにバージョンを導入します🙏
26. 26 kaptest で VAP のポリシをテストする # kaptest.yaml policies: - ../org-namespace-must-be-prefixed-by-orgname.yaml resources: - resources.yaml vapTestSuites: - policy: org-namespace-must-be-prefixed-by-orgname tests: - object: kind: SubnamespaceAnchor name: org-foo--child namespace: org-foo expect: admit - object: kind: SubnamespaceAnchor name: org-bar--child namespace: org-foo expect: deny deniedMessage: metadata.name must be prefixed by `org-bar--` - object: kind: SubnamespaceAnchor name: org-foo--with--double-hyphen namespace: org-foo expect: deny deniedMessage: subnamespace name must not contain `--` except for orgName delimiter # resources.yaml apiVersion: v1 kind: Namespace metadata: name: org-foo labels: org.preferred.jp/name: foo --- apiVersion: hnc.x-k8s.io/v1alpha2 kind: SubnamespaceAnchor metadata: name: org-foo--child namespace: org-foo --- apiVersion: hnc.x-k8s.io/v1alpha2 kind: SubnamespaceAnchor metadata: name: org-bar--child namespace: org-foo --- apiVersion: hnc.x-k8s.io/v1alpha2 kind: SubnamespaceAnchor metadata: name: org-foo--with--double-hyphen namespace: org-foo VAP/MAP のマニフェストを指定します テストの対象とするリソースの マニフェストを指定します テストケース毎に期待する結果を定義 拒否メッセージのテストもサポート！
27. 27 kaptest で MAP のポリシをテストする # kaptest.yaml policies: - ../reserved-node.yaml resources: - resources.yaml mapTestSuites: - policy: reserved-node tests: - object: kind: Pod name: example namespace: org-foo expect: mutate expectObject: kind: Pod name: example-mutated namespace: org-foo 変更した結果のオブジェクトを指定！ # resources.yaml apiVersion: v1 kind: Namespace metadata: name: org-foo labels: org.preferred.jp/name: foo --- apiVersion: v1 kind: Pod metadata: name: example namespace: org-foo spec: containers: - name: app image: nginx --- apiVersion: v1 kind: Pod metadata: name: example-mutated namespace: org-foo spec: nodeSelector: node.preferred.jp/reserved: org-foo containers: - name: app image: nginx
28. 28 同一ノード上でのプロセス・データの 分離
29. 29 専有ノード: テナント専用ノード (+) ノードに他テナントの Pod がいないのでセキュリティ的に安心 (-) ノードごとの月額単位で課金 共有ノード: 複数のテナントが共有するノード (-) ノードに他のテナントの Pod がいるため、セキュリティが懸念 • コンテナを抜けられてホストに潜入できるとまずい (+) 利用に合わせて分単位で課金 Pod の分離 PFCP のノードの種類
30. 30 root ユーザー禁止 (+) コンテナを抜けられてもすぐに root ユーザーにはなれない (-) root ユーザーが使えないため apt install などできない root ユーザー許容 (-) コンテナを抜けられたときにホストの root ユーザーとなる ◦ 他テナントのコンテナに潜入されるリスク (+) apt install など可能に → root を許可しつつ、安全にしたい Pod の分離 コンテナセキュリティ強化と利便性
31. 31 CloudNative Days Winter 2024
32. 32 Pod の分離 User Namespace - UID のマッピング Init User NS 0 … 999 1000 … 1999 2000 … 2999 3000 … 3999 Container 1 User NS 0 … 999 Container 2 User NS 0 … 999 1000 …. 1999 Host Init User NS 0 … 999 1000 … 1999 2000 … 2999 3000 … 3999 Init User NS 0 … 999 Init User NS 0 … 999 1000 …. 1999 Host User Namespace なしのUIDs User Namespace ありの UIDs コンテナ1 コンテナ2
33. 33 User NS の UID/GID のマッピングはあくまでもプロセスの話 ◦ ファイルは...？ Pod の分離 ファイルの所有者 Processes Files Processes Files Processes
 Files OS 🐧
 ここのマッピングは大丈夫 Icon pack by Icons8 - https://icons8.com コンテナ コンテナ コンテナ ファイルなどのUID/GIDの マッピングは？
34. 34 Pod の分離 ファイルの所有者 $ ls -l drwxrwxr-x 2 pfn pfn 4096 Nov 10 11:43 pfn/ -rw-rw-r-- 1 utam0k utam0k 10 Nov 9 11:45 utam0k.txt utam0k: 1000 pfn: 1001
35. 35 $ ls -l drwxrwxr-x 2 pfn pfn 4096 Nov 10 11:43 pfn/ -rw-rw-r-- 1 utam0k utam0k 10 Nov 9 11:45 utam0k.txt $ unshare --user --map-root-user $ cat /proc/$$/uid_map 0 1000 1 utam0k: 1000 pfn: 1001 実行ユーザー(utam0k) を root ユーザーにマッピング コンテナの 0 をホスト 1000 に 長さ 1 でマッピングされている utam0k(ホスト) ↔ root(コンテナ) Pod の分離 ファイルの所有者
36. 36 $ ls -l drwxrwxr-x 2 pfn pfn 4096 Nov 10 11:43 pfn/ -rw-rw-r-- 1 utam0k utam0k 10 Nov 9 11:45 utam0k.txt $ unshare --user --map-root-user $ cat /proc/$$/uid_map 0 1000 1 $ ls -l drwxrwxr-x 2 nobody nogroup 4096 Nov 10 11:43 pfn/ -rw-rw-r-- 1 root root 10 Nov 9 11:45 utam0k.txt utam0k: 1000 pfn: 1001 Pod の分離 ファイルの所有者
37. 37 $ ls -l drwxrwxr-x 2 pfn pfn 4096 Nov 10 11:43 pfn/ -rw-rw-r-- 1 utam0k utam0k 10 Nov 9 11:45 utam0k.txt $ unshare --user --map-root-user $ cat /proc/$$/uid_map 0 1000 1 $ ls -l drwxrwxr-x 2 nobody nogroup 4096 Nov 10 11:43 pfn/ -rw-rw-r-- 1 root root 10 Nov 9 11:45 utam0k.txt $ echo "test" | tee -a pfn/pfn.txt tee: pfn/pfn.txt: Permission denied test $ echo "test" | tee -a utam0k.txtf test utam0k: 1000 pfn: 1001 Pod の分離 ファイルの所有者 uid: 0(ホストでは1000) が nobody/nogroup のファイルに 書き込みをしようとしてNG
38. 38 Pod の分離 id-mapped mount - Permission Denied Init User NS Container User NS UID/GID のマッピング by FS UID 0 UID 1000 UID 1000 UID 2000 ・・・ ・・・ Icon pack by Icons8 - https://icons8.com
39. 39 Pod の分離 id-mapped mount - 例 $ ls -l drwxrwxr-x 2 pfn pfn 4096 Nov 27 08:26 pfn/ -rw-rw-r-- 1 utam0k utam0k 10 Nov 9 11:45 utam0k.txt $ sudo mount -m --bind --map-users 1001:1000:1 $(pwd)/pfn $(pwd)/mnt utam0k: 1000 pfn: 1001 1001(pfn) を 1000(utam0k) に 長さ 1 でマッピング
40. 40 Pod の分離 id-mapped mount - 例 $ ls -l drwxrwxr-x 2 pfn pfn 4096 Nov 27 08:26 pfn/ -rw-rw-r-- 1 utam0k utam0k 10 Nov 9 11:45 utam0k.txt $ sudo mount -m --bind --map-users 1001:1000:1 $(pwd)/pfn $(pwd)/mnt $ ls -l drwxrwxr-x 2 utam0k nogroup 4096 Nov 10 12:03 mnt/ drwxrwxr-x 2 pfn pfn 4096 Nov 10 11:43 pfn/ -rw-rw-r-- 1 utam0k utam0k 10 Nov 9 11:45 utam0k.txt utam0k: 1000 pfn: 1001
41. 41 Pod の分離 全体像 $ sudo mount -m --bind --map-users 1001:1000:1 $(pwd)/pfn $(pwd)/mnt $ ls -l drwxrwxr-x 2 utam0k nogroup 4096 Nov 10 12:03 mnt/ drwxrwxr-x 2 pfn pfn 4096 Nov 10 11:43 pfn/ -rw-rw-r-- 1 utam0k utam0k 10 Nov 9 11:45 utam0k.txt utam0k: 1000 pfn: 1001
42. 42 Pod の分離 全体像 $ sudo mount -m --bind --map-users 1001:1000:1 $(pwd)/pfn $(pwd)/mnt $ ls -l drwxrwxr-x 2 utam0k nogroup 4096 Nov 10 12:03 mnt/ drwxrwxr-x 2 pfn pfn 4096 Nov 10 11:43 pfn/ -rw-rw-r-- 1 utam0k utam0k 10 Nov 9 11:45 utam0k.txt $ unshare --user --map-root-user $ echo "test" | tee -a mnt/pfn.txt test $ cat pfn/pfn.txt pfn test utam0k: 1000 pfn: 1001 実行ユーザー(utam0k) を root ユーザーにマッピング
43. 43 ✓ User Namespace プロセスの UID/GID の変換を担当 ✓ id-mapped mount ファイルシステムレイヤでの UID/GID の変換を担当 Pod の分離 共有ノードを支える技術 Processes Files Processes Files Processes
 Files OS 🐧
 User Namespace id-mapped mount Icon pack by Icons8 - https://icons8.com コンテナ コンテナ コンテナ
44. 44 id-mapped mount が非対応なファイルシステムがある man の mount_setattr(2) の Notes セクションに対応済み一覧がある ✓ xfs(5) (since Linux 5.12) ✓ ext4(5) (since Linux 5.12) ✓ btrfs(5) (since Linux 5.15) ✓ overlayfs (ID-mapped lower and upper layers supported since Linux 5.19) ✓ cephfs (since Linux 6.7) NFS が非対応 で困った... 😭 → 共有ノードで RWX なストレージを提供できていない Pod の分離 直面した課題
45. 45 問題を整理 ➔ NFS が id-mapped mount 非対応 ◦ NFS を用いた PV/PVC を利用するとコンテナの起動に失敗する ➔ id-mapped mount がないとどうなるか？ ◦ 起動は成功する ◦ NFS を利用する PV の UID/GID のマッピングがなくなる ➔ そもそも PFCP の PV で UID/GID は必要？ ◦ PVC は Namespace 単位のオブジェクト ◦ PFCP ではテナントは Namespace で区切られているので UID/GID での制御は不要 • 誰が書き込んでいるかは考えなくよい(all_squash) Pod の分離 直面した課題
46. 46 Pod の分離 id-mapped mount をスキップ
47. 47 Pod の分離 id-mapped mount をスキップ ここでファイルシステムの種類ごとに id-mapped mount のスキップの制御はできない😢
48. 48 Pod の分離 id-mapped mount をスキップ NEW
49. 49 Low-Level に渡る情報を加工、検証できる NRI(Node Resource Interface) Kubelet
 Linux など
 Container Runtime High-Level Low-Level OCI Runtime Spec Container Runtime I nterface
50. 50 • containerd/nri • Kubecon + CNC NA 2025 でもいくつか発表 • Pod とコンテナのライフサイクルに合わせて プラグインがフックされる ◦ e.g., 作成、消去、停止 • プラグインでは検証やコンテナの加工が可能 ◦ 加工できるフィールド例: ▪ Linux namespaces ▪ memory の swap limit ▪ CPU の quota や period • Protobuf ベースの NRI Plugin プロトコルでコ ンテナランタイム側とやりとり NRI(Node Resource Interface) https://github.com/containerd/nri
51. 51 NRI(Node Resource Interface)
52. 52 Pod の分離 id-mapped mount をスキップ コンテナの加工をプラグインの ようにできるコンテナランタイ ムの新機能 NFS の時だけ id-mapped mount をスキップ NEW
53. 53 DaemonSets での配布が可能 • Ansible を書かなくてよい！ • ノードを選択することができる！ アップグレードは？ • NRI がいない場合は無視されて起動を試 みる ◦ .oO(もう少しやり方はありそう) NRI プラグインのデプロイ
54. 54 ここがすごい！ • 標準化されているのでコンテナランタイムへの依存がない • NRI のプラグインでは Pod のアノテーション情報も見える • WebAssembly サポートがある • DaemonSets で各ノードに NRI プラグインを配れる ここが注意！ • まだまだ新しい機能で情報は少ない • 加工できない OCI Runtime のフィールドもある • コンテナを加工するという責任 いままではどうしていたのか？ • OCI Runtime の Hooks を使って差し込む • Low-Level コンテナランタイムをラップする NRI(Node Resource Interface)
55. 55 限られた計算リソースの公平制御
56. 56 ✓ 利用効率 • 貴重な計算資源を有効活用 ✓ 公平性 • テナント内でリソース分配 • テナント間のリソース融通 スケジューラ PFCP におけるスケジューラの主な役割
57. 57 ✓ 利用効率 • 貴重な計算資源を有効活用 ✓ 公平性 • テナント内でリソース分配 • テナント間のリソース融通 スケジューラ PFCP におけるスケジューラの主な役割 実装中
58. 58 Kueue: Kubernetes-native Job Queueing • kubernets-sigs/kueue • Workload という単位でリソースマネジメントとスケジュー リングを行う kube-scheduler の KEP で Kueue への言及が増えている • KEP-4671: Gang Scheduling • KEP-5278: Nominated node name for an expected pod placement スケジューラ Kueue 実装中
59. 実装中
60. 62 • ClusterQueue ◦ クラスター全体のリソース（CPU, GPU, MN-Core な ど）を管理し、ジョブの受付とリソース割り当てを制御 する「大元のキュー」 • Cohort ◦ リソースの余剰分を互いに「貸し借り」できる、 ClusterQueueのグループ • ResourceFlavor ◦ 「MN-Core」や「MN-Core 2」のように、同じリソース （MN-Core）の異なるフレーバーを区別・管理するため の仕組み スケジューラ Kueue の概念 実装中
64. LocalQueue の名前を 指定する
65. 67 やりたいこと • Priority が高い Workload のリソース使用量を制限 • Priority が低い Workload は空いていれば入る • Priority 間のプリエンプション • クラスタ管理者が各テナントのリソース使用量を決定 • テナント管理者が各テナントの subnamespace のリソースを決定 設計方針 • すべてのワークロードはリソースを借りているという状態 • Cohort でテナントのリソース使用量を制限 • ClusterQueue で subnamespace のリソース使用量を制限 スケジューラ PFCP での Kueue の設計 実装中
67. Priority: Standard > Low 設計方針 • すべてのワークロードはリソースを 借りているという状態 • Cohort でリソース使用量を制限 Cohort(クラスタ管理者が管理) • 各テナントごとに作成 • Cohort に各テナントが使用できる 最大のリソース使用量を定義 ◦ クラスタ管理者が管理者
68. ClusterQueue(全体) • 各CQ はテナントの Cohort からリ ソースを借用状態(↔ nominalQuota) • 借用なので高い Priority が来るとプリ エンプションされる ClusterQueue(Low) • テナントで1つ • 最大借用リソース使用量は無制限 ClusterQueue(Standard) • 各サブ NS ごとに作成される • 最大借用リソース量はテナント管理者 が管理
69. • 各ネームスペースでは Priority に合わ せた LocalQueue が作成される • Low はテナント内のサブ NS で共有さ れる ◦ 早い者勝ち
70. 72 スケジューラ LocalQueue と PrioirtyClass を紐付ける 実装中 Webhook サーバの実装なしに これだけで実現できるけど 正しく動くかどうかが不安... （本日3回目） ✅ kaptest ツールでテストできます！
71. 73 ✓ そもそも Kueue の挙動を理解するのが難しい ◦ まだ世の中に情報が少ない ◦ ドキュメントはあるが、想像と違う動きをすることも ✓ 既に動いているクラスタに途中で入れるのは難しい ◦ Kueue のリソース管理に移行する必要がある ✓ 開発が活発である一方で不安定なところはある ◦ Alpha 機能を使う場合は自分たちでもコミットする ◦ CR の conversion サポートがない スケジューラ Kueue で直面している課題 実装中
72. 74 まとめ
73. 75 まとめ (1/2) 1. なぜマルチテナントを選択するのか ◦ MN-Core や GPU といった貴重な計算リソースを無駄なく 効率よく利用するため 2. Kubernetes オブジェクトの操作を制限・強制する ◦ PFCP での Kubernetes Namespace の設計 ▪ マルチテナントでも Namespace を作成してもらいたい ▪ OSS である HNC を活用している ◦ テナント単位でオブジェクト数を制限する ▪ HNC の機能である HRQ を活用して実現 ◦ オブジェクト操作にポリシを提供する ▪ VAP・MAP を活用している ▪ VAP・MAP のテストには kaptest を利用している
74. 76 4. 同一ノード上でのプロセス・データの分離 ◦ Pod 分離: Usernamespaces + id-mapped mount で解決 ▪ NFS で id-mapped mount が機能しない ◦ NRI(NodeResourceInterface) を利用してid-mapped mount をスキップ 5. 限られた計算リソースの公平制御 ◦ Kueue への取り組み: バッチスケジューリングに関する多くの機能 ▪ 開発が活発である一方で若いソフトウェアで不安定 ▪ 自分たちでのコミットしていく必要がある まとめ (2/2)
75. We’re Hiring! Preferred Networks の基盤技術グループでは採⽤を実施中です！ • 機械学習プラットフォームエンジニア Kubernetes, 社内向け機械学習プラットフォーム、外販クラウドサービスの開発運⽤ キーワード: K8s, オンプレ, GPU, Observability, MLOps, HPC, スケジューラ, AWS,       Front/Backend, コンテナネットワーク, データセンタネットワーク, RDMA, RoCE v2 • ストレージエンジニア ストレージの企画設計管理運⽤ • ⼤規模計算基盤エンジニア/ネットワーク‧インフラ運⽤エンジニア クラスタの物理設計、MN-Core™ を含めた先端システム設計等 77 カジュアル⾯談にお気軽にご応募ください
76. MN-Core Technology Conference 25 ✓ MN-Core の開発者向けイベントを開催！ ✓ MN-Core のこれまでとこれからがわかる イベントです ◦ 現在開発中の推論向けチップ MN-Core L1000の最新情報も発表 します ✓ PFN のブースでフライヤーを配布中 2025/12/16 東京ミッドタウンにて お待ちしています！