為每個團隊單獨運行一套Kubernetes集群，往往會帶來超出實際需求的隔離開銷。雖然多個團隊可以共用同一個集群，但隨著團隊數量增加，協調成本也會隨之上升。常見問題包括：CRD版本衝突、RBAC權限重疊，以及無法將GPU資源按團隊維度進行合理劃分。發展到一定規模後，各團隊往往會要求擁有獨立集群，以找回自主權。
本文提供了一種既能保留團隊自主權、又無需拆分硬體的方案。該方案由一個具備GPU資源池的控制平面集群、支持按團隊配額的GPU共享機制，以及每個團隊獨立的Kubernetes控制平面（包含API伺服器、控制器、數據儲存、同步器和調度器）共同構成。整套方案基於兩款開源工具實現：KAI Scheduler與vCluster。
按照本教學操作完成後，你將看到三個團隊在各自的租戶集群中運行真實的GPU Kubernetes Pod，同時共享同一塊物理GPU，且每個團隊只能看到自己的工作負載。
為了確保資源有限的用戶也能復現完整流程，本教學使用的集群配置為一塊NVIDIA L40S GPU，由三個團隊共享其中的不同份額。這樣的設置便於直觀地觀察和驗證各環節的運行機制。相同的方案同樣適用於擁有數百個GPU節點和數十個團隊的大規模集群，只需按需擴展節點池、隊列層級和租戶集群數量即可。
KAI Scheduler介紹
KAI Scheduler是一款專為AI工作負載GPU資源調度而設計的高性能、可擴展拓撲感知型Kubernetes調度器，能夠管理包含數千個節點的大規模GPU集群，並支持高吞吐量的工作負載調度。它支持GPU資源的動態分配，可與默認的kube-scheduler並行運行。任何設置了schedulerName: kai-scheduler的Pod都由KAI Scheduler負責處理，其餘Pod仍走默認的kube-scheduler流程。
vCluster介紹
vCluster Kubernetes平台可在你的基礎設施或裸金屬上，快速創建完全隔離的租戶集群。每個租戶集群擁有獨立的API伺服器、自定義資源定義（CRD）和基於角色的訪問控制（RBAC），體驗上與獨立的Kubernetes集群無異，同時共享底層節點和硬體。虛擬化控制平面對租戶完全透明：無共享控制平面節點，無集群內代理Pod，各環境之間也沒有橫向訪問路徑。這使得vCluster非常適合GPU基礎設施場景——團隊可獲得獨立的集群體驗，而無需拆分硬體。
本教學採用vCluster的共享節點模式，各團隊共享GPU節點，同時各自擁有獨立的隔離控制平面，適合內部可信團隊使用。對於需要節點級、網路級和儲存級隔離的不可信租戶，同樣的架構可擴展至vCluster私有節點模式。
場景示例
本示例涉及三個團隊：NLP團隊、視覺團隊和推薦系統團隊。NLP團隊希望安裝自己的CRD；視覺團隊需要cluster-admin權限來調試調度問題；推薦系統團隊使用不同版本的Kubeflow。沒有人願意共用一個kubectl上下文，並冒著誤操作破壞他人環境的風險。
通過vCluster，每個團隊擁有獨立的控制平面、RBAC、命名空間和CRD，並可各自擁有cluster-admin訪問權限。在底層，所有租戶集群共享相同的節點和GPU。
環境準備
本示例運行在Nebius提供的NVIDIA Brev GPU實例上，配置如下：
一塊NVIDIA L40S GPU，40個vCPU，160 GiB內存，256 GiB磁盤（48 GB顯存）
Ubuntu 24.04.4 LTS
MicroK8s v1.36.2（Kubernetes由Brev預配置，內置MicroK8s GPU插件，已將NVIDIA GPU Operator預裝至gpu-operator-resources命名空間）
KAI Scheduler v0.16.4
vCluster CLI 0.35.1
注意：對於不同的環境，集群創建和GPU Operator安裝步驟在GKE/EKS/AKS/原生k8s/k3s上會有所不同。從第3步（KAI Scheduler）起，只要Kubernetes環境已啟用Container Device Interface（CDI）並運行NVIDIA GPU Operator，操作步驟完全一致。
第一步：配置MicroK8s基礎環境
安裝獨立的kubectl和helm，以避免每條命令都需要加microk8s前綴，並配置kubeconfig，同時鎖定MicroK8s版本，防止演示期間snap自動升級控制平面。
sudo snap refresh --hold microk8s
sudo snap install kubectl --classic --channel=1.35/stable
sudo snap install helm --classic
mkdir -p ~/.kube
sudo microk8s config > ~/.kube/config
sudo chown $USER:$USER ~/.kube/config
chmod 600 ~/.kube/config
啟用所需的MicroK8s插件：
microk8s enable dns
microk8s enable hostpath-storage # vCluster需要PVC支持
驗證集群狀態：
kubectl get nodes -o wide
kubectl get storageclass
第二步：添加NVIDIA Helm倉庫
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update
第三步：確認GPU Operator運行狀態
kubectl get pods -n gpu-operator-resources
如果使用較舊版本的GPU Operator，可通過以下命令原地升級至26.3.x：
helm upgrade gpu-operator nvidia/gpu-operator
-n gpu-operator-resources
--version v26.3.3
--reset-then-reuse-values
如需全新安裝NVIDIA GPU Operator，可使用以下命令：
helm install gpu-operator nvidia/gpu-operator
-n gpu-operator-resources --create-namespace
--version v26.3.3
--set driver.enabled=false
...
第四步：安裝KAI Scheduler
helm upgrade -i kai-scheduler
oci://ghcr.io/kai-scheduler/kai-scheduler/kai-scheduler
-n kai-scheduler --create-namespace
--version v0.16.4
--set "global.gpuSharing=true"
驗證安裝結果：
kubectl get pods -n kai-scheduler
第五步：創建隊列層級
KAI Scheduler使用Queue CRD來構建組織→團隊的層級結構。本步驟創建一個父隊列（ml-org，總預算為1塊GPU）和三個子隊列。每個子隊列保底分配0.33塊GPU，當其他團隊空閒時可使用完整的1塊GPU。
將以下內容保存為create-queues.yaml：
apiVersion: scheduling.run.ai/v2
kind: Queue
metadata:
name: ml-org
spec:
resources:
gpu: { quota: 1, limit: -1, overQuotaWeight: 1 }
---
apiVersion: scheduling.run.ai/v2
kind: Queue
metadata:
name: team-nlp
spec:
parentQueue: ml-org
priority: 100
resources:
gpu: { quota: 0.33, limit: 1, overQuotaWeight: 1 }
---
apiVersion: scheduling.run.ai/v2
kind: Queue
metadata:
name: team-vision
spec:
parentQueue: ml-org
priority: 100
resources:
gpu: { quota: 0.33, limit: 1, overQuotaWeight: 1 }
---
apiVersion: scheduling.run.ai/v2
kind: Queue
metadata:
name: team-recommender
spec:
parentQueue: ml-org
priority: 100
resources:
gpu: { quota: 0.33, limit: 1, overQuotaWeight: 1 }
其中，quota為保底最小值，limit為最大允許值，overQuotaWeight控制超配資源的分配比例。
應用配置並查看結果：
kubectl apply -f create-queues.yaml
kubectl get queues
注意：default-parent-queue和default-queue是KAI Scheduler首次安裝時自動創建的，作為未指定隊列的Pod的默認回退隊列。
第六步：創建vCluster租戶集群
安裝vCluster CLI：
curl -L -o vcluster "https://github.com/loft-sh/vcluster/releases/latest/download/vcluster-linux-amd64"
sudo install -m 755 vcluster /usr/local/bin/vcluster
rm vcluster
vcluster --version
定義vCluster配置文件，關鍵設置是setOwner: false。KAI Scheduler的pod-grouper會沿著所有權鏈（Job→Pod，Deployment→ReplicaSet→Pod）自動對工作負載進行分組。禁用vCluster的owner重寫功能後，KAI Scheduler即可看到真實的層級結構。
cat > vcluster.yaml
experimental:
syncSettings:
setOwner: false
sync:
fromHost:
nodes:
enabled: true
selector:
all: true
EOF
為每個團隊分別創建vCluster：
vcluster create team-nlp --values vcluster.yaml --connect=false
vcluster create team-vision --values vcluster.yaml --connect=false
vcluster create team-recommender --values vcluster.yaml --connect=false
驗證三個vCluster均已正常運行：
vcluster list
每個團隊都可以看到真實節點，包括GPU節點：
vcluster connect team-nlp -- kubectl get nodes
第七步：部署GPU工作負載
各團隊從各自的vCluster中提交GPU工作負載。Pod規格簡潔，只需三個關鍵欄位告知KAI Scheduler如何處理：
vcluster connect team-nlp -- kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: nlp-sentiment-model
labels:
kai.scheduler/queue: team-nlp # 所屬團隊
annotations:
gpu-fraction: "0.33" # GPU使用份額
spec:
schedulerName: kai-scheduler # 使用KAI而非默認調度器
tolerations:
- key: nvidia.com/gpu
operator: Exists
effect: NoSchedule
containers:
- name: nlp-inference
image: nvidia/cuda:12.4.0-base-ubuntu22.04
command: ["bash", "-c", "nvidia-smi; sleep infinity"]
nodeSelector:
nvidia.com/gpu.present: "true"
EOF
對每個團隊重複上述操作，修改對應的隊列名稱即可。
驗證結果可以看到三個Pod分屬三個不同的vcluster-team-*命名空間，但全部運行在同一個物理節點上。
從各自的vCluster內部查詢，每個團隊只能看到自己的Pod：
vcluster connect team-nlp -- kubectl get pods -o wide
vcluster connect team-vision -- kubectl get pods -o wide
vcluster connect team-recommender -- kubectl get pods -o wide
最後，通過隊列狀態確認資源分配情況：
kubectl describe queue team-nlp | grep -A4 Status
kubectl describe queue team-vision | grep -A4 Status
kubectl describe queue team-recommender | grep -A4 Status
三個團隊均可看到相同的分配結果：
Status:
Allocated:
nvidia.com/gpu: 330m
Requested:
nvidia.com/gpu: 330m
關於GPU隔離的說明
需要注意的是，KAI Scheduler負責調度決策——決定哪些Pod使用哪塊GPU以及使用比例，但在GPU共享模式下，它並不在硬體層面強制執行GPU內存隔離。應用程式需要自行遵守內存配額（例如在vLLM中設置--gpu-memory-utilization參數）。
在底層實現上，GPU在各Pod的CUDA上下文之間按核心邊界進行時間片切換。如需在支持的硬體上實現硬體級內存隔離，可使用NVIDIA多實例GPU（MIG）提供硬體級分區，KAI Scheduler同樣支持對MIG資源進行調度。
總結
KAI Scheduler通過GPU共享與DRA驅動支持、帶保底配額和超配能力的分層隊列、gang調度以及拓撲感知等能力，公平地決定各團隊獲得的GPU時間片及其調度分組方式。在AI工作負載調度問題得到解決的基礎上，vCluster進一步賦予每個團隊獨立的Kubernetes控制平面，而無需承擔獨立基礎設施的成本。
KAI Scheduler與vCluster的組合，在單塊GPU上為三個團隊提供了媲美獨立集群的使用體驗，同時實現了零資源浪費。答案並非總是"更多GPU"，而是"更好地利用現有基礎設施"。
如需了解更多，可在GitHub上查看KAI Scheduler、vCluster和NVIDIA GPU Operator的相關項目，也可在2026年KubeCon北美峰會（11月9日至12日）上深入了解KAI Scheduler與vCluster的集成方案。
Q&A
Q1：KAI Scheduler是什麼？它在GPU共享中起什麼作用？
A：KAI Scheduler是一款專為AI工作負載設計的拓撲感知型Kubernetes調度器，核心功能是優化GPU資源分配。它支持分層隊列管理，可為每個團隊設置保底GPU配額和超配上限，並通過gang調度和時間片機制實現多團隊共享同一塊物理GPU，同時保證調度公平性。它可與默認kube-scheduler並行運行，只處理指定了schedulerName: kai-scheduler的Pod。
Q2：vCluster如何實現多團隊的Kubernetes隔離？
A：vCluster為每個團隊創建獨立的虛擬控制平面，包含獨立的API伺服器、CRD、RBAC和命名空間，體驗上與獨立集群完全一致。各團隊可擁有cluster-admin權限，互不干擾。底層所有租戶集群共享同一組物理節點和GPU，虛擬控制平面對租戶透明，不存在共享控制平面節點或跨租戶橫向訪問路徑。
Q3：KAI Scheduler能保證GPU內存隔離嗎？
A：KAI Scheduler在GPU共享模式下只負責調度決策，不在硬體層面強制執行GPU內存隔離。各應用需要自行遵守內存限制，例如在vLLM中通過--gpu-memory-utilization參數控制用量。如需硬體級內存隔離，可使用NVIDIA多實例GPU（MIG）功能，KAI Scheduler同樣支持對MIG資源進行調度管理。
