マルチテナントKubernetesコンテナ基盤 / 京都大学学術情報メディアセンターセミナー

Preferred Networksでは、AI/MLワークロード向けのクラウドサービスである「Preferred Computing Platform (PFCP)」をマルチテナントKubernetesコンテナ基盤として提供している。本講演では、複数ユーザが利用するマルチテナント基盤で重要となる、Kubernetes APIレベルでの権限分離とその強制、同一ホスト上でのプロセス・データの分離、同一ネットワーク内での通信分離等のアイソレーション技術、限られた計算リソースの公平制御、および課金システムについて、その実現のための技術と設計思想について説明する。また、Kubernetes上でAI/ML ワークロードを実行するために必要なアクセラレータのサポート、RDMAを含めHPCアプリケーションを実行する上で必要になる基本的な技術、複数の拠点にスケール可能なシステム構成等、PFCP全体についても概説する。

イベントサイト: https://www.media.kyoto-u.ac.jp/accms_web/event/3427.html

Transcript

1. マルチテナントKubernetesコンテナ基盤 2025年10月14日(火) 京都大学 学術情報メディアセンターセミナー 株式会社 Preferred Networks 須田 一輝、上野 裕一郎、小松 享
2. 須田 一輝 / @superbrothers • Preferred Networks, Inc. / エンジニア • Preferred Computing Platform (PFCP) 開発リード • Kubernetes Meetup Tokyo 共同主催者 • オライリー書籍 監訳 ◦ 「Kubernetes で実践する クラウドネイティブ DevOps」 ◦ 「入門 Prometheus」
3. 上野 裕一郎 / @y1r96 • Preferred Networks, Inc. / エンジニア • Preferred Computing Platform (PFCP) 開発サブリード • 興味 あること ◦ HPC (Accelerator, RDMA, Parallel Computing) ◦ AI/ML, Systems for AI/ML
4. 小松 享 / @utam0k • Preferred Networks, Inc. / エンジニア ◦ エンジニアリングマネージャー • OSS 活動 ◦ OCI Runtime Specification メンテナ ◦ Kubernetes SIG-Scheduling Reviewer ◦ などなど
5. 5 1. PFN の事業 2. PFN の AI・ML ワークロード向 クラウドサービス Preferred Computing Platform (PFCP) ◦ PFCP の紹介 ◦ PFCP のデモ 3. PFCP のマルチテナント Kubernetes コンテナ基盤を支える技術 ◦ なぜマルチテナントを選択するの ◦ マルチテナントのクラスタを構成する ◦ マルチテナントの制約を緩和する ◦ マルチテナントでの AI・ML ワークロード ◦ マルチテナントで必要な分離 (ネットワーク、Pod） ◦ マルチテナントで計算資源を効率よ 使う アジェンダ
6. 6 PFN の事業
7. 7 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
8. 8 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年提供予定）
9. 9 PFNは、AI技術のバリューチェーンを垂直統合し、様々な産業領域で ソリューション・製品を水平展開しています。 PFNの事業: AI技術の水平展開 生成AI・基盤モデル 社会 消費者 人間の能力の拡張 新しい創作表現・娯楽体験 安心・安全な社会 高度な教育・医療 生産性向上・品質改善 属人化回避・人手不足解消 計算基盤 産業 AIチップ 工場・製造 コンテンツ 製作 ロボット 小売 製薬 ヘルスケア 素材 化学品 教育 金融
10. 10 PFN の AI・ML ワークロード向け クラウドサービス Preferred Computing Platform （PFCP）
11. 11 • PFN 構築、運用する AI・ML ワークロード向 のクラウドサービス ◦ https://pfcomputing.com/ ◦ ユーザガイド: https://docs.pfcomputing.com/ • PFN のエンジニア・リサーチャ 使用する環境と同じものを提供 ◦ これまで社内向 に計算基盤を開発運用して た経験を元に開発 • 強力な計算ボードと高速なネットワーク ◦ 独自開発したアクセラレータ MN-Core™ シリーズを提供 ◦ 深層学習に最適化された高速なネットワークで相互に接続 誰もが MN-Core™ シリーズを利用できる AI クラウドサービス Preferred Computing Platform (PFCP)
12. 12 • 実験も学習も推論も ◦ 実験環境としてマネージドな JupyterLab を提供 ◦ 学習だ でな 、推論サーバの運用まで幅広いワークロードをサポート • オープンソースを採用 ◦ コンテナ実行環境にKubernetes を採用 (Linux Foundation / CNCF) ◦ AI・ML ワークロード向 に独自に拡張 • リソース使用状況の可視化 ◦ ワークロード状態を観測するためのモニタリングサービスも付随 誰もが MN-Core™ シリーズを利用できる AI クラウドサービス Preferred Computing Platform (PFCP) 管理コンソール ワークロード・計算資源監視 対話型実験環境 分散学習・LLM 推論
13. 13 2つの利用形態を計算ノードでサポートします。 • 専有ノード: 月額課金でテナントで専有 • 共有ノード: 従量課金で複数のテナントで共有 *1 計算ノードの利用形態: 専有ノードと共有ノード *1: 共有ノードは専有ノードとは異なり、複数の組織のワークロード 同じノード上でカーネルを共有します。 テナント間のセキュリティ境界についてより強固な分離 必要な場合は、専有ノードの利用を推奨します。 共有ノードでは追加のセキュリティ対策として、Linux の User Namespaces の使用を強制し、ホスト らコンテナの UID/GID の分離を実施しています。 計算ノードの種類と比較 - Preferred Computing Platform（PFCP）ユーザガイド
14. 14 • 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
15. 15 日本語を入力・出力言語とするテキスト翻訳に特化して PFN フルスクラッチ開発した大規模言語モデル（LLM） PLaMo™翻訳 のサービス提供*1 PFCP 利用事例: PLaMo 翻訳 *1 日本語の翻訳に特化したPLaMo翻訳のサブスクリプション サービスを正式リリース - 株式会社Preferred Networks PLaMo翻訳 : https://translate.preferredai.jp PLaMo 翻訳 システム構成概略 Google Cloud Cloud Run vLLM
16. 16 1. 対話型実験環境: ワークスペース機能 a. 対話型実験環境を作成して MN-Core 2 デバイスを操作する 2. 安全なサービス公開: ブラウザ らのアクセス a. 弊社製の言語モデル plamo-2-translate を vLLM で起動する b. open-webui にブラウザ らアクセスする PFCP デモ
17. 17 PFCP のマルチテナント Kubernetes コンテナ基盤を 支える技術
18. 18 なぜマルチテナントで Kubernetes を使用するのか MN-Core や GPU といった貴重な計算リソース（アクセラレータ）を 無駄な ・効率よ 利用するため • テナントごとにクラスタを用意した場合、1つのノード上の 計算リソースをテナント間で共有すること 難しい （共有ノードの実現 難しい） ◦ 仮想ノード (Virtual Kubelet 等) の選択肢もある 経験 ない • 社内向 にマルチテナントで計算基盤を提供して た経験 ら マルチテナント らはじめることを選択 ◦ 一方でマルチテナントではテナント間の分離 頑張りどころ ◦ 将来的にシングルテナントで提供することもで る
19. 19 1. 脆弱性の影響範囲 広 なることの対応 ◦ シングルテナントの場合、他のテナントに影響するケース 少ない 2. クラスタ管理者権限 必要な操作をユーザに提供で ないことへの対応 ◦ namespace を作成してもらえない ◦ Kubernetes Operator をインストールしてもらえない 3. テナント間で共有するものを守る ◦ クラスタのデータストア (etcd) を守る ◦ 計算ノードを守る ▪ 専有ノード: 他のテナントのワークロードを入れない 4. テナント間の分離（セキュリティ） ◦ ネットワークの分離（NetworkPolicy は RDMA に効 ない） ◦ Pod の分離（共有ノード: 権限昇格などの脆弱性への対策） マルチテナント頑張りどころの一例
20. 20 1. マルチテナントのクラスタを構成する 2. マルチテナントの機能制約を緩和する 3. マルチテナントでの AI・ML ワークロード 4. マルチテナントで必要な分離 (ネットワーク、Pod） 5. マルチテナントで計算資源を効率よ 提供する PFCP の マルチテナント Kubernetes コンテナ基盤を支える技術
21. 21 マルチテナントのクラスタを構成する
22. 22 クラスタを管理する: Cluster API • https://github.com/kubernetes-sigs/cluster-api • 管理クラスタ上のカスタムリソースで、ワークロードクラスタを管理 • Kubernetes らし Reconcile Loop でノードを扱う ◦ Machine リソースの削除で、ノードを削除する ◦ 健全でないノード数25%未満を維持しな らノードを更新する 管理クラスタ ワークロードクラスタ Cluster API infrastructure provider Infra API Machine Watch infrastructure Machine Watch 対応 仮想マシン 操作 作成・削除 仮想マシン マシン
23. 23 複数拠点の複数クラスタを Cluster API で一括管理 AWS EKS オンプレミス ベアメタル (MN-Core/GPU) さくらインターネット GPU ベアメタルサーバー 高火力 PHY さくらのクラウド（VM） AWS EC2 インスタンス (VM/GPU) 管理クラスタ ワークロードクラスタ AWS VPC Peering さくらインターネット AWS 接続オプション AW S Direct Connect • 複数種のインフラストラクチャプロバイダ • MAAS・さ らインターネットは 自作のプロバイダを使用
24. 24 拠点ごとのクラスタ構成 拠点 CNI プラグイン ロードバランサ 永続ストレージ インターコネクト オンプレミス CIlium (OSS) (BGP) MetalLB (OSS) (BGP モード) アプライアンス RoCE v2 / Ethernet さくらインターネット Cilium (OSS) (VXLAN) さくらのクラウド ロードバランサ Rook Ceph (OSS) RoCE v2 / Ethernet AWS Cilium (OSS) (VXLAN) AWS NLB AWS EBS / EFS AWS EFA 利用者 らは同じ使い勝手でも拠点ごとに構成 異なる（選択肢の違い） 構成 異なることでトラブルシュート 難しい
25. 25 カーネルで脆弱性報告 あっても数時間で全ノードを更新で る体制 • PFCP はメンテナンスポリシで4ヶ月に一度の Kubernetes バージョンの アップグレードを宣言 ◦ 最新マイナーバージョンの1つ前を採用 • OS やミドルウェア、アドオンなどのソフトウェアもすべて一緒に更新 ◦ すべてのホストで OS 再インストール ら実施する ▪ Cluster API でクラスタのバージョン更新を自動化で ている ▪ いつでも全ノードで OS 再インストールで る体制を維持する • マルチテナントでは脆弱性の影響 他のテナントに及ぶため、 脆弱性を管理し、す に変更を適用で る体制 より重要になる クラスタ管理におけるマルチテナントの頑張りどころ メンテナンスポリシ - Preferred Computing Platform（PFCP）ユーザガイド
26. 26 マルチテナントの制約を緩和する
27. 27 マルチテナントの機能制約 • Kubernetes Operator をインストールしてもらえない ◦ 一般に Operator は CRD のインストールを伴う ▪ CRD は cluster-wide リソースなので全テナントに影響 ある ▪ kcp などの選択肢も出て ている ◦ PFCP は、任意の Operator はインストールさせない割り切り ▪ PFCP は Kubernetes-as-a-Service ではない ▪ AI・ ML ワークロードに特化して必要なものは マネージドで提供する • Namespace リソースを作成してもらえない ◦ 1つのテナントにつ 、1つだ の Namespace では使いに い ◦ テナントの管理者 Namespace を作成で るようにしたい
28. 28 org-pfn--group4 org-pfn--group3 org-pfn--group2 hierarchical-namespaces (HNC): 階層型の Namespace と操作の委譲 テナント管理者が Namespace を作成できる org-pfn • テナント管理者 テナント専用の root namespace に紐づ 形で subnamespace (CR) を管理可能 • 先日アップストリームのリポジトリ アーカイブされてしまった ◦ PFN でフォークしてメンテを継続 ◦ https://github.com/pfnet/hierarchical-namespaces root namespace (クラスタ管理者が管理) subnamespace (テナント管理者が管理) • namespace 名にポリシの適用 • namespace のラベルの強制 （NetworkPolicy 等で機能） • RBAC 等のリソースを subnamespace に自動作成 org-pfn--group1
29. 29 マルチテナントの悪影響を抑える （共有するリソースを守る）
30. 30 特定のテナント 大量の Kubernetes オブジェクトを作成してしまう • ResourceQuota で制限 ◦ Namespace ごとの総リソース消費を制限する ◦ PFCP では HNC を使用してテナント管理者 セルフで Namespace を作成で てしまう ◦ テナント単位で制限したい • HierarchicalResourceQuota (HRQ) で制限 ◦ HNC のカスタムリソースで、自身を含む紐づ 全ての Namespace の総リソース消費を制限で る ◦ PFCP では1つの root namespace に subnamespace 紐づ ◦ root namespace に HRQ を作成してテナント単位で制限する クラスタのデータストア（etcd）を守る
31. 31 専有ノードにはそのテナントのワークロードのみをスケジュールさせる • どのテナントの namespace にリソース 作成された に 基づいて検証・変更を行う ◦ HNC で namespace にテナント名を含むラベル付与を強制 ◦ Admission Webhook や Validating/MutatingAdmissionPolicy で 上記のラベルを使用 • Pod リソース ◦ nodeSelector と tolerations を強制 ◦ 任意の tolerations を使用されないように検証する 共有ノードのセキュリティについてはこのあと別途解説 計算ノードを守る（専有ノード）
32. 32 マルチテナントでの AI・ML ワークロード
33. 33 • 機械学習ジョブはバッチスケジューラでいい感じに動 ◦ Kubernetes だと色々工夫 必要になる。 ユーザも Kubernetes や コンテナ に慣れる必要 ある。 • バッチスケジューラではな 、Kubernetes のいいところ ◦ 推論ワークロードを載せやすい ▪ そもそも Web サービス のために作られたので オートスケール、モニタリング、サービス間接続 しやすい！ ▪ （スパコンに Jupyter や サーバ を乗せるのは大変そう...） ◦ コミュニティ 大 い ▪ LLM以降、バッチ利用についても OSS 色々増えて ている バッチスケジューラ（Slurm, PBS, …）ではなく わざわざ Kubernetes で頑張る理由
34. 34 機械学習基盤のコンポーネント Scale-out Fabric InfiniBand, Ethernet Compute Node Compute Node RDMA NIC RDMA NIC Accelerator Accelerator CPU Scale-up Fabric Compute Node RDMA NIC RDMA NIC Accelerator Accelerator CPU Scale-up Fabric RDMA NIC RDMA NIC Accelerator Accelerator CPU Scale-up Fabric Job Scheduling Framework Kubernetes, Slurm, PBS, … Job Job Multi-Node Job どうやって Multi-Node Job を サポートする？ どうやって Scale-up Fabric を サポートする？ どうやって Accelerator を サポートする？ どうやって RDMA NIC を サポートする？ ネットワークを どううまく使う？
35. 35 機械学習基盤のコンポーネント Scale-out Fabric InfiniBand, Ethernet Compute Node Compute Node RDMA NIC RDMA NIC Accelerator Accelerator CPU Scale-up Fabric Compute Node RDMA NIC RDMA NIC Accelerator Accelerator CPU Scale-up Fabric RDMA NIC RDMA NIC Accelerator Accelerator CPU Scale-up Fabric Job Scheduling Framework Kubernetes, Slurm, PBS, … Job Job Multi-Node Job どうやって Multi-Node Job を サポートする？ どうやって Scale-up Fabric を サポートする？ どうやって Accelerator を サポートする？ どうやって RDMA NIC を サポートする？ ネットワークを どううまく使う？
36. 36 Multi-Node Job / MPI • MPI: 分散メモリ環境（マルチノード）向 の通信インターフェイス ◦ Open MPI などの OSS やベンダープロプライエタリな実装 ある ◦ 機械学習でも MPI を使ってジョブを起動すること 多い launcher node $ mpiexec ./exec srv-a srv-b srv-c hostfile rank=0 (srv-a) $ ./exec ssh srv-a ./exec MPI_Comm_rank() -> 0 MPI_Comm_size() -> 3 ssh srv-b ./exec MPI_Comm_rank() -> 1 MPI_Comm_size() -> 3 rank=1 (srv-b) $ ./exec ssh srv-c ./exec MPI_Comm_rank() -> 2 MPI_Comm_size() -> 3 rank=2 (srv-c) $ ./exec プロセス番号は rank と呼ばれる 今のコミュニケータに全部で何台いる も取れる hostfile で 実際のサーバとプロセスを紐付 る MPI_COMM_WORLD 今のジョブの世界全体
37. 37 • launcher 他の Pod 上でコマンドを起動するには： ◦ kubectl exec する方法 ▪ API Server の不調やタイムアウトに巻 込まれてつらい ◦ sshd たてる + Service で Pod を Discovery する方法 ▪ 鍵作成に手間 る 、内製オペレータで自動化して解決 MPI on Kubernetes を実現するためのチャレンジ launcher pod $ mpiexec ./exec srv-a srv-b hostfile rank=0 pod $ ./exec ??? ??? rank=1 pod $ ./exec
38. 38 • 複数の Pod を同時にスケジュールする ◦ Kubernetes 標準にはそういった機能はない ▪ 内製スケジューラで Gang Scheduling して解決 ◦ Kueue など OSS で実現で るものもでて ている • 設定の複雑さ ◦ 例 ▪ トポロジを考慮したホストファイルの生成 ▪ RDMA の設定（QoS、NCCL、NIC） ◦ ユーザ 設定するには難しす るので、 内製オペレータで initContainer や 環境変数を設定してやる MPI on Kubernetes を実現するためのチャレンジ
39. 39 機械学習基盤のコンポーネント Scale-out Fabric InfiniBand, Ethernet Compute Node Compute Node RDMA NIC RDMA NIC Accelerator Accelerator CPU Scale-up Fabric Compute Node RDMA NIC RDMA NIC Accelerator Accelerator CPU Scale-up Fabric RDMA NIC RDMA NIC Accelerator Accelerator CPU Scale-up Fabric Job Scheduling Framework Kubernetes, Slurm, PBS, … Job Job Multi-Node Job どうやって Multi-Node Job を サポートする？ どうやって Scale-up Fabric を サポートする？ どうやって Accelerator を サポートする？ どうやって RDMA NIC を サポートする？ ネットワークを どううまく使う？
40. 40 • 基本はデバイスファイルをつ てやればいい ... ◦ /dev/nvidiaX (NVIDIA, GPU) ◦ /dev/mncXpYs0 (PFN, MN-Core) • デバイス へんなことやらない は注意 必要 ◦ ドライバに脆弱性 出ると困る → ちゃんと作る必要 ある💪 • 安全にデバイスに設定値を入れたい ◦ 例: アクセラレータの動作周波数をワークロードごとに最適化！ ▪ 標準的な Device Plugin ではパラメータを渡すの 難しい ▪ Dynamic Resource Allocation 使える可能性あり • DRA ドライバだ に強い権限を持たせる。 ユーザには直接渡さない。 Scale-up Fabric や Acclererator のサポート
41. 41 機械学習基盤のコンポーネント Scale-out Fabric InfiniBand, Ethernet Compute Node Compute Node RDMA NIC RDMA NIC Accelerator Accelerator CPU Scale-up Fabric Compute Node RDMA NIC RDMA NIC Accelerator Accelerator CPU Scale-up Fabric RDMA NIC RDMA NIC Accelerator Accelerator CPU Scale-up Fabric Job Scheduling Framework Kubernetes, Slurm, PBS, … Job Job Multi-Node Job どうやって Multi-Node Job を サポートする？ どうやって Scale-up Fabric を サポートする？ どうやって Accelerator を サポートする？ どうやって RDMA NIC を サポートする？ ネットワークを どううまく使う？
42. 42 • スパコンだと InfiniBand 選ばれること 多い PFCP だと Ethernet を採用している • Ethernet のいいところ ◦ 標準で TCP/IP を利用可能 ▪ TCP/IP はストレージやIngress、サービス間通信で重要 • non-RDMA でも ECMP で る ▪ IPoIB しな ていい ◦ 色々なベンダ らスイッチやスイッチ ASIC でている ▪ Cisco, Arista (Broadcom), NVIDIA ◦ 輻輳制御周りは大変なところもある ... (マルチベンダだと特に) InfiniBand vs Ethernet → Ethernet を採用
43. 43 • 深層学習フレームワーク 通信するテンソルを Pack する • 集団通信ライブラリを呼び出す: ◦ 通信ハードウェアを探索して TCP/IP を発見 ◦ Socket API を使うため ホストに Buffer を Copy • Socket API を呼び出す ◦ Userland / Kernel で Copy ◦ OS NIC に DMA 機械学習アプリから NIC まで（TCP/IP の場合） TCP/IP 通信 集団通信ライブラリ xCCL Linux Kernel Socket API connect, write Tensor @ Accelerator NIC Vendor implementation D2H Copy DMA 深層学習フレームワーク 機械学習アプリケーション 例: LLM, 画像認識, ... ライブラリの呼出 ncclAllReduce, … フレームワークの呼出 torch.distributed.all_reduce Pack Buffer @ Accelerator Buffer @ Host Buffer @ Kernel space to kernel
44. 44 • 深層学習フレームワーク 通信するテンソルを Pack する • 集団通信ライブラリを呼び出す: ◦ 通信ハードウェアを探索して IB Device を発見 • Verbs API を呼び出す ◦ Accelerator ら 直接 DMA ◦ PeerDirect RDMA 機械学習アプリから NIC まで（RDMA の場合） RDMA 集団通信ライブラリ xCCL rdma-core (userspace) infiniband subsystem (kernel) InfiniBand Verbs reg_mr, post_send, poll_cq Tensor @ Accelerator RDMA NIC Vendor implementation DMA 深層学習フレームワーク 機械学習アプリケーション 例: LLM, 画像認識, ... ライブラリの呼出 ncclAllReduce, … フレームワークの呼出 torch.distributed.all_reduce Pack Buffer @ Accelerator
45. 45 機械学習アプリから NIC まで（比較） TCP/IP 通信 RDMA 集団通信ライブラリ xCCL Linux Kernel Socket API connect, write Tensor @ Accelerator NIC Vendor implementation D2H Copy DMA 深層学習フレームワーク 機械学習アプリケーション 例: LLM, 画像認識, ... ライブラリの呼出 ncclAllReduce, … フレームワークの呼出 torch.distributed.all_reduce Pack Buffer @ Accelerator Buffer @ Host Buffer @ Kernel space to kernel 集団通信ライブラリ xCCL rdma-core (userspace) infiniband subsystem (kernel) InfiniBand Verbs reg_mr, post_send, poll_cq Tensor @ Accelerator RDMA NIC Vendor implementation DMA 深層学習フレームワーク 機械学習アプリケーション 例: LLM, 画像認識, ... ライブラリの呼出 ncclAllReduce, … フレームワークの呼出 torch.distributed.all_reduce Pack Buffer @ Accelerator すっ飛ばした分早い！ ホストメモリ経由しないのでPCIe帯域を節約！
46. 46 • veth, eBPF で... と は TCP/IP 通信の話である ◦ RDMA は カーネルの TCP/IP スタック を通らない RDMA NIC を直接つける veth VF eth0 net1 PF VF VF veth VF Pod Podのnetnsに移す NIC ホスト 通常ネットワーク インターコネクト SR-IOV による NIC の仮想化
47. 47 マルチテナントで必要な分離 / ネットワーク の分離
48. 48 NetworkPolicy は RDMA に効かない • Kubernetes 内での標準的なネットワークアイソレーションは NetworkPolicy を使った方法である ◦ これをもとに eBPF や iptables を使って通信元や通信先を制限 • RDMA は直接 NIC を Pod につ て、カーネルはバイパスする ◦ eBPF や iptables は通らない、ホストで制限で ない ◦ 代わりに、NIC や ネットワークスイッチ でで ることを考える TCP/IP 通信 RDMA 集団通信ライブラリ xCCL Linux Kernel Socket API NIC Vendor implementation D2H Copy DMA 深層学習フレームワーク ncclAllReduce, … Buffer @ Accelerator Buffer @ Host Buffer @ Kernel space to kernel 集団通信ライブラリ xCCL rdma-core (userspace) infiniband subsystem (kernel) InfiniBand Verbs RDMA NIC Vendor implementation DMA 深層学習フレームワーク ncclAllReduce, … Buffer @ Accelerator eBPF, iptables
49. 49 • NIC でで ること：何 しらの情報をパケットに付与（色付 ） ◦ VLAN Switch Tagging ▪ VF ら出るパケットに強制的に VLAN タグをつ る ▪ ConnectX の機能で、ベンダーロックインになる ◦ TC Flower offload / Open vSwitch offload ▪ TC flow rule を NIC にオフロードする ▪ Kernel にある機能で、複数のベンダ サポートしている • スイッチ でで ること：ポート VLAN・VRF 分離？ ◦ Pod スケジュール時にスイッチの設定変更をしないとい ない ◦ スイッチだ では、共有ノードのトラフィックを見分 られない NIC や スイッチ でのアイソレーション
50. 50 $ grep -R NETIF_F_HW_TC drivers/net/ethernet | cut -d\/ -f4 | sort | uniq airoha aquantia broadcom cadence chelsio freescale hisilicon intel marvell mediatek mellanox microchip mscc netronome qlogic sfc stmicro ti wangxun TC Flower Offload は広くサポートされている
51. 51 • 使えそうな機能 ◦ VLAN Push / Pop ▪ テナントごとに VLAN ID や VRF を決めて 、色付 ◦ Src/Dst IP による ACL ▪ テナントごとに CIDR を決めて いて、それで ACL する ◦ Tunneling (VXLAN, GRE, GENEVE) ▪ オーバーレイネットワークをつ る • それぞれ検討して絶賛開発中です TC Flower はどう使えるか？
52. 52 • AWS 拠点だと、EFA (Elastic Fabric Adapter) で RDMA する ◦ EFA は Ethernet (RoCE v2) というよりは InfiniBand ぽい • ネットワークアイソレーションは Security Group でで る ◦ テナントごとに Security Group を分 れば制御可能 ◦ 専有ノードはこれで対応可能 • Security Group は、EFA それぞれではな インスタンスに紐づ ◦ 共有ノード（1インスタンスに複数テナント）は分離不可能 AWS 拠点だとアイソレーションできるのか？ Tenant A Security Group Tenant A Compute Node Tenant A Compute Node Tenant B Security Group Tenant B Compute Node Tenant B Compute Node EFA EFA EFA EFA EFA EFA EFA EFA
53. 53 マルチテナントで必要な分離 / Pod の分離
54. 54 専有ノード: テナント専用ノード (+) ノードに他テナントの Pod いないのでセキュリティ的に安心 (-) ノードごとの月額単位で課金 共有ノード: 複数のテナント 共有するノード (-) ノードに他のテナントの Pod いるため、セキュリティ 懸念 • コンテナを抜 られてホストに潜入で るとまずい (+) 利用に合わせて分単位で課金 Pod の分離 PFCP のノードの種類
55. 55 root ユーザー禁止 (+) コンテナを抜 られてもす に root ユーザーにはなれない (-) root ユーザー 使えないため apt install などで ない root ユーザー許容 (-) コンテナを抜 られたと にホストの root ユーザーとなる ◦ 他テナントのコンテナに潜入されるリスク (+) apt install など可能に → root を許可しつつ、安全にしたい Pod の分離 コンテナセキュリティ強化と利便性
56. 56 Kata Container • GPU を1枚し サポートで ていない ◦ 私の認識だと実装コストの都合 • MN-Core のドライバ側の追加対応、検証 必要 gVisor • MN-Core のドライバ側の追加対応、検証 必要 KubeVirt • Pod ではな なるのであらゆるものを再考しないとい な 、 つらい User Namespace を用いた技 • いままでの延長で可能だった Pod の分離 コンテナセキュリティ強化と利便性
57. 57 Pod の分離 User Namespace - UID のマッピング Init User NS 0 … 999 1000 … 1999 2000 … 2999 3000… 3999 UID 空間 Host
58. 58 Pod の分離 User Namespace - 通常のコンテナ Init User NS 0 … 999 1000 … 1999 2000 … 2999 3000… 3999 Container 1 User NS 0 … 999 Container 2 User NS 0 … 999 Host
59. 59 Pod の分離 User Namespace - UID のマッピング Init User NS 0 … 999 1000 … 1999 2000 … 2999 3000 … 3999 Container 1 User NS 0 … 999 Host
60. 60 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 Nested User NS 0 … 999 Host
61. 61 User NS の UID/GID のマッピングはあ までもプロセスの話 ◦ ファイルは...？ Pod の分離 ファイルの所有者 Processes Files Processes Files Processes
 Files OS 🐧
 ここのマッピングは大丈夫 Icon pack by Icons8 - https://icons8.com コンテナ コンテナ コンテナ ファイルなどのUID/GIDの マッピングは？
62. 62 Pod の分離 id-mapped mount - Permission Denied $ 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
63. 63 Pod の分離 id-mapped mount - Permission Denied $ 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(コンテナ)
64. 64 Pod の分離 id-mapped mount - Permission Denied $ 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
65. 65 Pod の分離 id-mapped mount - Permission Denied $ 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.txt test utam0k: 1000 pfn: 1001
66. 66 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
67. 67 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 でマッピング
68. 68 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
69. 69 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
70. 70 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 ユーザーにマッピング
71. 71 ✓ 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 コンテナ コンテナ コンテナ
72. 72 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 の分離 直面している課題
73. 73 問題を整理 ➔ 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 の分離 直面している課題
74. 74 Pod の分離 id-mapped mount をスキップ 実装中
75. 75 Pod の分離 id-mapped mount をスキップ ここでファイルシステムの種類ごとに id-mapped mount のスキップの制御はで ない😢 実装中
76. 76 Pod の分離 id-mapped mount をスキップ コンテナの加工をプラグインの ようにできるコンテナランタイ ムの新機能 NFS の時だけ id-mapped mount をスキップ NEW 実装中
77. 77 マルチテナントで計算資源を 効率よく提供する / スケジューラ
78. 78 ✓ 利用効率 • 貴重な計算資源を有効活用 ✓ 公平性(実装中) • テナント内でリソース分配 • テナント間のリソース融通 スケジューラ PFCP におけるスケジューラの主な役割
79. 79 ✓ 利用効率 • 貴重な計算資源を有効活用 ✓ 公平性(実装中) • テナント内でリソース分配 • テナント間のリソース融通 スケジューラ PFCP におけるスケジューラの主な役割
80. 80 Scheduling Framework: スケジューラーのアーキテクチャ • 機能・目的ごとに拡張点 存在し、プラグインとして機能を差し込み可能 • スケジューリングのロジックをプラグインという単位で分割 例) NodeAffinity, PodTopologySpread, Preemption ... スケジューラ Kubernetes のスケジューラ拡張
81. 81 • Packing: で るだ 効率よ PodをNodeに詰めたい ◦ Podのリソース要求は多次元ベクトル ▪ 1次元でもNP-Hardな組合せ最適化問題(Bin Packing) • Defrag: フラグメンテーションを除去したい ← PFNではで ていない ◦ Podの実行時間は不定なので時間 建つと穴 開 スケジューラ High Utilization Rate Packing
82. 82 スケジューラ 典型的なワークロード All-Reduce スタイル 分散深層学習ジョブ (並列)ジョブ ワークフロー 分散(深層)強化学習ジョブ Environments + Actors Distributed Learners
83. 83 スケジューラ 典型的なワークロード All-Reduce スタイル 分散深層学習ジョブ (並列)ジョブ ワークフロー 分散(深層)強化学習ジョブ Environments + Actors Distributed Learners Pod を一斉にスタート(着地) させる必要がある
84. 84 スケジューラ Gang-Scheduling (a.k.a. Co-Scheduling) • 複数のPodを一度に配置したい = all or nothing なスケジューリング ◦ All-Reduceの分散深層学習は全 pods 揃わないと計算開始で ない ◦ 2つの Gang を1 Podずつ配置すると容易にデッドロックしてしまう • リソース効率的な観点でも一斉にスケジュールしたい Job A Job B どちらも サイズ6
85. 85 ✓ 利用効率 • 貴重な計算資源を有効活用 ✓ 公平性(実装中) • テナント内でリソース分配 • テナント間のリソース融通 スケジューラ PFCP におけるスケジューラの主な役割 実装中
86. 86 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 実装中
87. 実装中
88. 実装中
89. 実装中
90. 90 • Topology Aware Scheduling • Fair Sharing • Dynamic Resource Allocation のサポート • Multi Kueue • クレジット • 豊富なメトリクス スケジューラ Kueue のいろいろな一般的な機能
91. 91 ✓ そもそも Kueue の挙動を理解するの 難しい ◦ まだ世の中に情報 少ない ◦ ドキュメントはある 、想像と違う動 をすることも ✓ 既に動いているクラスタに途中で入れるのは難しい ◦ Kueue のリソース管理に移行する必要 ある ✓ 開発 活発である一方で不安定なところはある ◦ Alpha 機能を使う場合は自分たちでもコミットする スケジューラ Kueue で直面している課題 実装中
92. 92 まとめ
93. 93 まとめ (1/3) 1. なぜマルチテナントを選択するの ◦ MN-Core や GPU といった貴重な計算リソースを無駄な 効率よ 利用するため 2. マルチテナントのクラスタを構成する ◦ Cluster API を利用して複数拠点の複数クラスタを一括管理 ◦ 脆弱性対応のために常にノードを更新で る体制を維持 3. マルチテナントの制約を緩和する ◦ Kubernetes Operator: 必要なものはマネージドで提供で割り切る ◦ Namespace: hierarchical-namespaces (HNC) を活用
94. 94 4. マルチテナントでの AI・ML ワークロード ◦ MPI: 内製 Operator で簡単に利用可能（ssh 用の鍵作成等を代行） ◦ Gang Scheduling: 内製スケジューラを開発 ◦ 各種デバイスのサポート（Accelerator, RDMA 対応 NIC） ▪ PFCP では InfiniBand ではな Ethernet を採用 ◦ 従来、機械学習ジョブを Kubernetes でやることは大変だった LLM 以降、Kubernetes や周辺 OSS でのサポート 広 りつつある 5. マルチテナントで必要な分離 (ネットワーク、Pod） ◦ ネットワーク分離: NetworkPolicy は RDMA に効 ない ▪ OVS w/ TC Flower で実現を検討中 ◦ Pod 分離: Usernamespaces + id-mapped mount で解決 ▪ NFS で id-mapped mount 機能しない • NFS だ NRI を利用してip-mapped mount をスキップ まとめ (2/3)
95. 95 6. マルチテナントで計算資源を効率よ 使う ◦ スケジューラを独自で拡張: Bin-Packing, Gang Scheduling ◦ Kueue への取り組み: バッチスケジューリングに関する多 の機能 ▪ 開発 活発である一方で若いソフトウェアで不安定 ▪ 自分たちでのコミットしてい 必要 ある まとめ (3/3)