More Freedom on the Same Shared GPU Cluster: A Small Team’s Experience with vCluster

2026年10月1日のCloud Native Community Japan - AI Infra Meetup #1で発表した「More Freedom on the Same Shared GPU Cluster: A Small Team's Experience with vCluster」の講演資料です。
講演詳細についてはこちらをご覧ください。 https://ocgroups.dev/cncf/group/bqd97by/event/7fu3gfg
社内向けGPUクラスタに対して、vClusterを活用しユーザーの使い方を変えずユーザー自由度を増やした事例を紹介します。

Transcript

1. More Freedom on the Same Shared GPU Cluster: A Small Team’s Experience with vCluster AI Infra Meetup #1 2026/10/1 NTTドコモビジネス イノベーションセンター 石本直也 © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 1
2. 自己紹介—4人でGPU基盤を運用 石本 直也 インフラエンジニア 新卒2年目 GPUクラスタ構築・運用 [1] GPU over APN Testbed • 社内向けGPUクラスタの構築・運用 ５名以下のチームでデータセンター設備・ラッキング・ネットワークから Kubernetesまで広く担当 • 全国広域分散GPU実証環境 GPU over APN Testbedの構築・運用 [1] 社内向けGPUクラスタに対して vClusterを活用しユーザーの使い方を変えず、ユーザー自由度を増やした事例を紹介 © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. [1] IOWN® APN を活用した全国広域分散GPU実証環境「GPU over APN Testbed」を提供開始 https://www.ntt.com/about-us/press-releases/news/article /2026/0706.html 2
3. 共有GPUクラスタの運用 • 4種類/数十台のGPUノードを、1つのクラスタとして運用 • 複数チーム・複数プロダクトが利用 テナント分離 利用者ごとにNamespaceを払い出し • 社内のAI研究者によるNotebookやGPUを利用するワークロードが中心で、 当初はNamespace 分離で十分 • ユーザー・チームごとのNamespace内での管理権限を付与(Namespace Admin) © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 3
4. Namespace Adminでは足りなくなった AIアプリケーション開発チームが加わり、新しいリクエストが発生 • チームが開発する複数プロダクトごとにNamespaceを自由に分けたい • クラスタ全体に影響するコンポーネントの導入(ex. 別ingress controllerによるAPI検証) ユーザーが開発する上で運用者の権限が必要なため NamespaceAdmin権限では検証を完結できない © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 4
5. ユーザーの開発において、運用者がボトルネック 従来の対応 コンポーネント導入の際 ユーザーが運用者へ相談 運用者が 既存 クラスタへの影響を調査 月初メンテナンスで導入 →ユーザー提供 相談から導入までにタイムラグが発生 ユーザーの利用方法を変更せず、ユーザーの検証自由度を高める方法を検討 変えないもの • 利用者のクラスタの使い方は変えない (学習コストを最小限に抑える) © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 改善するもの • Operator・ClusterRoleなどのリソースを 扱うユーザー自由度の改善 • 検証開発のスピードの改善 5
6. vClusterによる分離 hostクラスタの上にnestedなk8sクラスタを作るOSS、商用版も存在 Namespaceの中に、仮想的な k8sクラスタ(API Server) を作成することで、 ユーザー目線「独立したK8sクラスタ」として扱える環境を提供 ClusterRole Namespace などの クラスタスコープリソースは仮想クラスタごとに管理 利用者は、 仮想クラスタ内でCluster Adminに近い権限を持てる Pod・Service などはSyncerによって host クラスタへ同期されhostで実行 © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 6
7. Pod ができるまでの流れ 主要コンポーネント • K8sのコントロールプレーン機能が詰まったvcluster API • vClusterとHostクラスタを繋ぐSyncer vCluster APIが、ユーザーからのyamlのリクエストをうけたのち Hostクラスタ上で名前が衝突しないよう、SyncerがPod名を変換して作成 nginx ↓ nginx-x-” vCluster内のnamespace名”-x-”仮想クラスタ名” (vCluster内のnamespace名、仮想クラスタ名が付与) Host クラスタ（共有GPU ） 仮想クラスタ host の Namespace 内で動く User vcluster API ① kubectl apply © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. ② watch で検知 Syncer Sync （作成代行） ③ 名前を 変換して作成 Host API Server Real Pod ④ 起動 name: nginx-x-namespace-xvcluster 7
8. vClusterの管理者設定 一部リソースについて仮想クラスタとHostクラスタ間同期 ・HostクラスタのNode/Ingress情報を同期 →ユーザーは従来通り使い勝手を維持(nodeaffinityでGPUを選択可能、hostのingressも活用可能) 共有GPU host cluster vCluster：チーム専用の仮想クラスタ Host Scheduler etcd ユーザー kubectl 専用 API Server 仮想Node として登録 Namespace CRD / RBAC Syncer Pod・Service・ Ingressを変換/同期 NVIDIA Device Plugin 変換された 実Pod GPU Host API Server Node名・ラベル・ GPU情報・Ingress classを同期 © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 8
9. vClusterでうまくいったこと ユーザー面線 ・従来は、クラスタに影響を及ぼすコンポーネントもユーザー管理の下で導入可能 • Operator や Custom Resource を使ったプロダクトの開発、検証、テストが高速で回せる • kubeconfigを変更するだけで、仮想クラスタの利用が可能 • ユーザーは既存マニフェストを継続して利用可能 運用者目線 • HostクラスタのCluster Admin権限を渡さずに、利用者へ高い自由度を提供 • ユーザーへのvClsuter提供は、約15分の説明で実施、問い合わせも少なくスムーズに導入 • vCluster内のkubernetesアップデートもvClusterのコマンド一つ vcluster create --upgrade virtual-cluster -f vcluster.yaml 今後 • vClusterとDRAによるGPUの選択・割り当てを実現する共有設定の検証 • Gateway APIへの移行する上での検証 © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 9
10. まとめ • AIアプリケーション開発において、Namespace 分離だけで権限不足 • vClusterでnamespace,clusterrole、operatorなどクラスタリソースを分離 Node・ネットワークなどの実行基盤はhostclusterと共有 • GPU利用方法を維持したまま、より自由な検証環境を提供 © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 10
11. © NTT DOCOMO BUSINESS, Inc. All Rights Reserved.
12. Appendix共有ノードでセキュリティ強化オプション 共有ノードでは別テナントの Pod が同じノード・同じ GPU を使う。 vcluster.yaml でのオプション toHost.priorityClasses: false 他テナントの Pod を押し出す優 先度を禁止 共有 GPU ノード（host） nodes.clearImageStatus: true Node 同期時に他テナントのイ メージ名を隠す Pod vCluster A（チーム A） ✕ Pod vCluster B（チーム B） resourceQuota / limitRange CPU・メモリ・オブジェクト数 に上限 CNI Pod 間の通信を NetworkPolicy で制御 podSecurityStandard: restricted 特権コンテナ・hostNetwork な どを禁止する © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. networkPolicy.enabled: true 他テナント Pod との通信を遮断 GPU GPU GPU GPU 12
13. Appendix vClusterのGPUクラスタへの適応設定 host の Node と Ingress を仮想クラスタにつなぐ sync 設定（vcluster.yaml） ユーザーが慣れているnodeアフィニティでのGPUノードの選択 sync.fromHost.node.enable.true HostからNode情報(kubectl get node)を同期 hostのNode名・ラベル・GPUを仮想クラスタ内から参照可能に ホストのingressの利用 sync.fromHost.ingressClasses.enable.true • HostからIngressクラス情報を同期 • host側の物を活用し、cert-managerなどSSL証明書発行フローを維持 sync. toHost. ingresses.enable.true ・vcluster内で作成ingressリソースをhostに同期 その他 sync: fromHost: nodes: enabled: true ingressClasses: enabled: true toHost: ingresses: enabled: true OverwriteconfigでcoreDNSの設定に社内DNSなどを追加 © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 13
14. Appendix vClusterの分離 上位のリソース 実行に必要な最小限のリソース © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 例 Deployment、ReplicaSet、 StatefulSet、CRD、カスタムリ ソース、RBAC、Namespace Pod、Service、PVC、Pod が使 う ConfigMap/Secret など どこで扱われるか 仮想クラスタの中だけ（ホストに は作られない） Syncer でホストに同期される 14
15. Appendix vClusterのGPUクラスタへの適応 vcluster.yaml の sync は向きで 2 種類：fromHost（host → vCluster）と toHost（vCluster → host）。Pod・Service などは設定なしで toHost vCluster sync: 4 fromHost: nodes: API Server 1 etcd fromHost 共有GPU host cluster 1 Node（GPU） 2 IngressClass 3 Ingress コントローラー ＋ certmanager enabled: true ingressClasses: 2 enabled: true toHost: ingresses: Syncer 3 toHost enabled: true controlPlane: 4 distro: k8s: 1 nodes host の Node（ラベル・GPU 数）を vCluster へ → nodeSelector がそのまま使える 2 ingressClasses host の IngressClass を vCluster から選べるようにする 3 ingresses vCluster の Ingress を host へ → host のコントローラーと cert-manager で公開 4 controlPlane vCluster 自体の構成（Kubernetes ディストリビューション、etcd をデプロイ） enabled: true backingStore: etcd: deploy: enabled: true © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 15