在ACK AutoMode叢集中實現GPU工作負載的按需自動調整與成本最佳化 - Container Service for Kubernetes

叢集開啟智能託管模式後，可通過智能託管節點池動態伸縮 GPU 資源，為具有明顯波峰波穀的線上推理等 GPU 工作負載情境顯著降低成本。

適用範圍

ACK託管叢集（智能託管模式）
節點作業系統為ContainerOS 3.6及以上版本。如需升級ContainerOS版本，請參見更換作業系統。

步驟一：選用GPU規格建立智能託管節點池

建議為GPU工作負載建立單獨的節點池。當提交需要GPU資源的工作負載時，系統將根據資源需求自動建立GPU節點；在節點空閑且滿足縮容條件時自動釋放，確保僅在實際使用期間產生費用。

在ACK叢集列表頁面，單擊目的地組群名稱，在叢集詳情頁左側導覽列，選擇節點管理 > 節點池。

單擊建立節點池，按照頁面提示完成配置。

關鍵配置如下。詳細配置項說明，請參見建立節點池。

配置項	說明
託管配置	選擇智能託管。
交換器	節點池擴縮容時，根據擴縮容策略在選擇的vSwitch可用性區域下擴縮節點。為保障高可用，建議選擇2個及以上不同可用性區域。
執行個體相關配置	選擇執行個體配置方式為指定執行個體規格。架構：GPU雲端服務器。執行個體規格：根據業務需求選擇合適的執行個體規格類型系列，如ecs.gn7i-c8g1.2xlarge (NVIDIA A10)。為提高擴容成功率，建議選擇多個執行個體規格。
汙點（Taints）	為防止非GPU工作負載被調度到價格較高的GPU節點，建議通過汙點實現邏輯隔離。鍵：nvidia.com/gpu 值：true Effect：NoSchedule

步驟二：為GPU工作負載配置資源請求與汙點容忍

為確保應用可調度至節點池並觸發GPU節點的自動建立，需在YAML配置中聲明GPU資源需求及對節點汙點的容忍策略。

配置GPU資源請求：在容器的resources欄位中聲明所需的GPU卡資源。

# ...
spec:
  containers:
  - name: gpu-automode
    resources:
      limits:
        nvidia.com/gpu: 1   # 請求 1 個 GPU 卡資源
# ...

配置汙點容忍：添加tolerations欄位，匹配節點池的汙點，從而允許Pod調度到帶有該汙點的節點上。

# ...
spec:
   tolerations:
    - key: "nvidia.com/gpu"  # 匹配節點池設定的汙點 Key
      operator: "Equal"
      value: "true"          # 匹配節點池設定的汙點 Value
      effect: "NoSchedule"   # 匹配節點池設定的汙點 Effect
# ...

步驟三：部署GPU工作負載並驗證Auto Scaling效果

以一個Stable Diffusion Web UI應用為例，示範完整部署流程及彈效能力驗證過程。

建立並部署工作負載。

展開查看樣本

建立stable-diffusion.yaml。

該YAML包含兩部分：

Deployment: 定義Stable Diffusion工作負載。其Pod請求1個NVIDIA GPU，並配置了對應的汙點容忍。
Service: 建立LoadBalancer類型的Service，通過公網IP暴露工作負載，並將請求轉寄至容器的7860連接埠。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: stable-diffusion
  name: stable-diffusion
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: stable-diffusion
  template:
    metadata:
      labels:
        app: stable-diffusion
    spec:
      containers:
      - args:
        - --listen
        command:
        - python3
        - launch.py
        image: yunqi-registry.cn-shanghai.cr.aliyuncs.com/lab/stable-diffusion:v1.0.0-gpu
        imagePullPolicy: IfNotPresent
        name: stable-diffusion
        ports:
        - containerPort: 7860
          protocol: TCP
        readinessProbe:
          tcpSocket:
            port: 7860
        resources:
          limits:
            # 請求 1 個 GPU 卡資源
            nvidia.com/gpu: 1
          requests:
            cpu: "6"
            memory: 12Gi  
      # 聲明汙點容忍，確保 Pod 可以調度到對應節點池
      tolerations:
      - key: "nvidia.com/gpu"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"   
---
apiVersion: v1
kind: Service
metadata:
  annotations:
    # 指定 LoadBalancer 的服務地址類型為公網
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: internet
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-instance-charge-type: PayByCLCU
  name: stable-diffusion-svc
  namespace: default
spec:
  externalTrafficPolicy: Local
  ports:
  - port: 7860
    protocol: TCP
    targetPort: 7860
   # 關聯具有app=stable-diffusion標籤的Pod
  selector:
    app: stable-diffusion
   # 建立 LoadBalancer 類型的服務類型
  type: LoadBalancer

部署工作負載。
```
kubectl apply -f stable-diffusion.yaml
```

驗證節點自動擴容。

部署後，Pod會因缺少GPU資源而處於Pending狀態。

查看Pod狀態。
```
kubectl get pod -l app=stable-diffusion
```

查看Pod事件。

kubectl describe pod -l app=stable-diffusion

在Events中，預期先出現FailedScheduling，隨後出現ProvisionNode事件，表明擴容已觸發。

......
Events:
  Type     Reason            Age                From               Message
  ----     ------            ----               ----               -------
  Warning  FailedScheduling  15m                default-scheduler  0/3 nodes are available: 1 node(s) had untolerated taint {node.kubernetes.io/not-ready: }, 2 Insufficient cpu, 2 Insufficient memory, 2 Insufficient nvidia.com/gpu. preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling., ,
  Normal   ProvisionNode     16m                GOATScaler         Provision node asa-2ze2h0f4m5ctpd8kn4f1 in Zone: cn-beijing-k with InstanceType: ecs.gn7i-c8g1.2xlarge, Triggered time 2025-11-19 02:58:01.096
  Normal   AllocIPSucceed    12m                terway-daemon      Alloc IP 10.XX.XX.141/16 took 4.764400743s
  Normal   Pulling           12m                kubelet            Pulling image "yunqi-registry.cn-shanghai.cr.aliyuncs.com/lab/stable-diffusion:v1.0.0-gpu"
  Normal   Pulled            3m48s              kubelet            Successfully pulled image "yunqi-registry.cn-shanghai.cr.aliyuncs.com/lab/stable-diffusion:v1.0.0-gpu" in 8m47.675s (8m47.675s including waiting). Image size: 11421866941 bytes.
  Normal   Created           3m42s              kubelet            Created container: stable-diffusion
  Normal   Started           3m24s              kubelet            Started container stable-diffusion

擷取Pod所在的節點名稱。

# 將Pod所在的節點名稱存入變數 NODE_NAME
NODE_NAME=$(kubectl get pod -l app=stable-diffusion -o jsonpath='{.items[0].spec.nodeName}')

# 列印節點名稱
echo "Stable Diffusion is running on node: $NODE_NAME"

# 查看該節點的詳細資料，確認其已處於Ready狀態
kubectl get node $NODE_NAME

訪問Stable Diffusion。
等待幾分鐘，待新節點加入叢集且Pod啟動完成後，即可通過公網訪問應用。
1. 執行以下命令擷取服務的公網IP地址（EXTERNAL-IP）。
```
kubectl get svc stable-diffusion-svc
```
  在輸出中，擷取其EXTERNAL-IP。
```
NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
stable-diffusion-svc   LoadBalancer   192.XXX.XX.196   8.XXX.XX.68   7860:31302/TCP   18m
```
2. 在瀏覽器中訪問http://<EXTERNAL-IP>:7860。
  若頁面顯成功載入Stable Diffusion Web UI，則表明工作負載已在GPU節點上成功運行。
驗證節點自動縮容（手動觸發）。
為驗證節點的自動縮容能力，可手動刪除Deployment使節點進入閑置狀態。
1. 刪除此前建立的Deployment和Service。
```
# 刪除Deployment
kubectl delete deployment stable-diffusion

# 刪除Service
kubectl delete service stable-diffusion-svc
```
2. 觀察節點縮容。
  節點伸縮組件會在達到縮容觸發時延（智能託管模式下預設為3分鐘）後，自動將其從叢集中移除以節省成本。使用之前擷取的節點名稱重新查詢該節點。
```
kubectl get node $NODE_NAME
```
  預期輸出中提示找不到該節點，表明節點已按預期被自動縮容並釋放。
```
Error from server (NotFound): nodes "<nodeName>" not found
```