Container Service for Kubernetes：雲原生AI套件管理員營運指南

背景資訊

當部署一個雲原生AI叢集之後，叢集管理員需要對叢集資源進行劃分，管理多重專案組，並可以多個維度查看叢集資源的使用方式，以便及時做出調整，使叢集達到最佳的利用率。

當叢集中有多個使用者時，為了保障使用者有足夠的資源使用，管理員會將叢集的資源固定分配給不同的使用者。傳統的方法是通過Kubernetes原生的ResourceQuota方式進行固定資源的分配。但由於小組之間資源忙閑不一，為了叢集整體利用率達到最高，需要在確保使用者的資源分派的基礎上通過資源共用的方式來提升整體資源的利用率。

以下圖的公司組織圖為例，您可以根據具體情況，配置多個層級的彈性配額。圖中每個葉子結點，可對應一個使用者組，通過給使用者組中的使用者指派不同的namespace和role，可以將許可權管理和配額管理分開。既可以在組間共用資源，又可以在組內實現隔離。

前提條件

• 已建立ACK Pro版叢集，且在組件配置頁面，需要選中監控外掛程式和Log Service。

• ACK Pro版叢集的Kubernetes版本不低於1.18。

目標任務

步驟一：安裝雲原生AI套件

雲原生AI套件作為一款外掛程式化的工具集，包括任務彈性、資料加速、AI任務調度、AI任務生命週期管理、叢集營運控制台、端到端研發控制台等組件。您可以根據實際需要自由選擇安裝。

部署雲原生AI套件

1. 登入Container Service管理主控台。

2. 在控制台左側導覽列，單擊叢集。

3. 在叢集列表頁面，單擊目的地組群名稱或者目的地組群右側操作列下的詳情。

4. 在叢集管理頁左側導覽列，選擇應用 > 雲原生AI套件。

5. 在雲原生AI套件頁面，單擊一鍵部署。

6. 在一鍵部署雲原生AI套件頁面，根據需要選中相應的組件後，單擊頁面下方的部署雲原生AI套件，開始檢查環境和依賴項，檢查通過後，自動部署選擇的組件。

   說明

   • 互動方式下的Arena命名行（必選）為預設必選組件。

   • 選中雲原生AI營運控制台時，會彈出提示話框。具體操作，請參見步驟1。

   組件安裝成功後，在組件列表頁面：

   • 您能看到當前叢集中已經安裝的組件名稱、版本等資訊，並能對組件進行部署、卸載操作。

   • 如果已安裝的組件有新版本的話，還可以對組件進行升級操作。

   • 安裝了雲原生AI營運控制台組件（ack-ai-dashboard）後，您可在頁面左上方看到營運控制台訪問地址，通過該地址可以訪問營運控制台頁面。

安裝配置雲原生AI營運控制台

1. 在雲原生AI套件部署頁面的互動方式地區，選中控制台，彈出提示對話方塊。

   • 如果授權狀態為已授權，請執行步驟3。

   • 如果授權狀態為紅色的未授權，且確定按鈕為不可用狀態，請執行步驟2。

     

2. 建立自訂權限原則並對RAM角色進行授權。

   1. 建立自訂權限原則。

      1. 登入RAM控制台，在左側導覽列選擇許可權管理>權限原則。

      2. 單擊建立權限原則。

      3. 單擊指令碼編輯頁簽。將以下策略添加至Action欄位中，然後單擊繼續編輯基本資料。

          "log:GetProject",
          "log:GetLogStore",
          "log:GetConfig",
          "log:GetMachineGroup",
          "log:GetAppliedMachineGroups",
          "log:GetAppliedConfigs",
          "log:GetIndex",
          "log:GetSavedSearch",
          "log:GetDashboard",
          "log:GetJob",
          "ecs:DescribeInstances",
          "ecs:DescribeSpotPriceHistory",
          "ecs:DescribePrice",
          "eci:DescribeContainerGroups",
          "eci:DescribeContainerGroupPrice",
          "log:GetLogStoreLogs",
          "ims:CreateApplication",
          "ims:UpdateApplication",
          "ims:GetApplication",
          "ims:ListApplications",
          "ims:DeleteApplication",
          "ims:CreateAppSecret",
          "ims:GetAppSecret",
          "ims:ListAppSecretIds",
          "ims:ListUsers"

      4. 在頁面頂端的名稱文字框中輸入自訂權限原則的名稱，格式需設定為k8sWorkerRolePolicy-{ClusterID}，單擊確定。

   2. 對目標容器叢集的RAM角色授權。

      1. 登入RAM控制台，在左側導覽列選擇身份管理>角色。

      2. 在文字框中輸入目標角色名稱，格式為KubernetesWorkerRole-{ClusterID}。單擊目標角色名稱後操作列的新增授權。

      3. 在選擇許可權地區，單擊自訂策略。

      4. 在文字框中輸入之前建立的自訂權限原則名稱，格式為k8sWorkerRolePolicy-{ClusterID}。

      5. 單擊確定。

   3. 返回Container ServiceACK控制台的提示對話方塊，單擊授權檢測。如果授權成功，授權狀態顯示為已授權，且確定按鈕可用。請執行步驟3。

      

3. 選擇控制台資料存放區方式。

   本文以選擇叢集內建MySQL為例進行說明，實際使用時可替換為阿里雲RDS。詳細說明，請參見安裝配置雲原生AI控制台。

4. 單擊部署雲原生AI套件。

   待營運控制台處於Ready狀態後，即可正常使用。

初始化資料集（可選）

管理員可按照演算法開發人員的需求，建立和加速資料集。這裡示範如何通過營運控制台或命令列建立資料集。

fashion-mnist資料集

管理員通過kubectl命令列在可以訪問叢集的機器上，建立OSS類型的PV和PVC。

1. 根據以下YAML樣本建立命名空間namespace: demo-ns。

kubectl create ns demo-ns

2. 根據YAML樣本建立fashion-mnist.yaml。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: fashion-demo-pv         
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 10Gi                
  csi:
    driver: ossplugin.csi.alibabacloud.com
    volumeAttributes:
      bucket: fashion-mnist      
      otherOpts: "-o max_stat_cache_size=0 -o allow_other"
      url: oss-cn-beijing.aliyuncs.com   
      akId: "AKID"               
      akSecret: "AKSECRET"
    volumeHandle: fashion-demo-pv
  persistentVolumeReclaimPolicy: Retain
  storageClassName: oss
  volumeMode: Filesystem
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: fashion-demo-pvc
  namespace: demo-ns
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  selector:
    matchLabels:
      alicloud-pvname: fashion-demo-pv
  storageClassName: oss
  volumeMode: Filesystem
  volumeName: fashion-demo-pv

3. 執行YAML樣本檔案建立PV和PVC。

kubectl create -f fashion-mnist.yaml

4. 查看確認PV和PVC狀態。

1. 執行以下命令，確認PV狀態。

   kubectl get pv fashion-demo-pv -ndemo-ns

   預期輸出：

   NAME                   CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                          STORAGECLASS   REASON   AGE
   fashion-demo-pv        10Gi       RWX            Retain           Bound    demo-ns/fashion-demo-pvc       oss                     8h

2. 執行以下命令，確認PVC狀態。

   kubectl get pvc fashion-demo-pvc -ndemo-ns

   預期輸出：

   NAME                       STATUS   VOLUME                 CAPACITY   ACCESS MODES   STORAGECLASS   AGE
   fashion-demo-pvc           Bound    fashion-demo-pv        10Gi       RWX            oss            8h

建立加速資料集

管理員可通過AI營運控制台加速目標資料集。本樣本介紹如何對demo-ns命名空間下的fashion-demo-pvc資料集進行加速。

1. 使用管理員帳號訪問AI營運控制台。

2. 在AI營運控制台左側導覽列中，選擇資料集 > 資料集列表。

3. 在資料集列表頁面，單擊目標資料集右側操作列的一鍵加速。

   加速後的資料集如下圖所示：

步驟二：查看資源大盤

雲原生AI套件中的營運控制台，提供了叢集資源大盤，可多維度查看叢集即時使用方式，方便調優叢集資源分派，最佳化叢集資源使用率。

叢集監控大盤

節點監控大盤

訓練任務監控大盤

資源配額監控大盤

步驟三：系統管理使用者和配額

• 配額樹是配置多層級約束的資源，供Capacity Scheduling Plugin使用。可以確保使用者資源分派的基礎上通過資源共用的方式來提升叢集的整體資源使用率。

• 雲原生AI套件的使用者一一對應一個K8s ServiceAccount，是提交任務和登入控制台的憑證。使用者根據使用者類型確定許可權，其中admin負責營運叢集，可登入營運控制台；researcher負責提交任務，使用叢集資源，可登入開發控制台；admin包含researcher的所有許可權。

• 使用者組是資源分派的最小單位，並與QuotaTree的葉子結點一一對應。使用者必須關聯使用者組，才能使用與之關聯的配額資源。

本步驟將介紹如何通過配額樹來配置多層級的配額約束、通過使用者組來分配配額給組使用者以及通過提交簡單的任務，示範cpu資源的彈性借還。

添加配額節點，並限定資源使用額度

配額是通過設定各資源的Min/Max來配置額度，其中Min表示有保障的資源數量（Guaranteed Resource），Max表示最大可用的資源數。把namespace掛載在配額樹的葉子節點，就意味著namespace受根節點到當前葉子結點路徑上的所有約束。

1. 如果namespace不存在，需要提前手動建立namespace。如果namespace已存在，需要保證namespace下沒有Running的Pod。

   kubectl create ns namespace1
   kubectl create ns namespace2
   kubectl create ns namespace3
   kubectl create ns namespace4

2. 建立配額節點，並關聯namespace。

建立使用者和使用者組

使用者和使用者組是多對多的關係，一個使用者可以屬於多個使用者組，一個使用者組也以可有多個使用者。您可以通過使用者關聯使用者組，也可以通過使用者組關聯使用者。通過配額樹和使用者組，可以方便的根據實際專案組劃分資源，分配許可權。

1. 建立使用者。具體操作請參見為新增使用者產生KubeConfig和登入Token。

2. 建立使用者組。具體操作請參見新增使用者組。

Capacity調度功能示範

具體操作步驟如下所示。

1. 建立namespace及配額樹。

   1. 執行以下命令，分別建立四個對應的Namespace。

      已建立namespace1為例：

      kubectl create ns namespace1
      kubectl create ns namespace2
      kubectl create ns namespace3
      kubectl create ns namespace4

   2. 根據下圖，建立配額樹。

      

2. 使用以下YAML檔案範例，在namespace1中部署服務，Pod的副本數為5個，每個Pod請求CPU資源量為5核。

   如果沒有彈性配額，使用者最多隻能使用10核（cpu.min=10），也就是建立2個副本。但在彈性配額Capacity調度下：

   • 當叢集有閒置40核CPU時，可以建立4個副本（4副本 x 5核/副本=20核）。

   • 最後一個副本因為超出最大資源限制（cpu.max=20），處於Pending狀態。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx1
     namespace: namespace1
     labels:
       app: nginx1
   spec:
     replicas: 5
     selector:
       matchLabels:
         app: nginx1
     template:
       metadata:
         name: nginx1
         labels:
           app: nginx1
       spec:
         containers:
         - name: nginx1
           image: nginx
           resources:
             limits:
               cpu: 5
             requests:
               cpu: 5

3. 使用以下YAML檔案範例，在namespace2中部署服務，Pod的副本數為5個，每個Pod請求CPU資源量為5核。

   如果沒有彈性配額，使用者最多隻能使用10個cpu（cpu.min=10），只能建立2個副本。但在彈性配額Capacity調度下：

   • 在叢集資源有20核（40核-namespace1中的20核）空閑，可以建立4個副本（4副本 x 5核/副本=20核）。

   • 最後一個副本因為超出最大資源限制（cpu.max=20），處於Pending狀態。

   • 此時叢集中namespace1和namespace2中的Pod所佔用的資源已經達到了root設定的root.max.cpu=40。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx2
     namespace: namespace2
     labels:
       app: nginx2
   spec:
     replicas: 5
     selector:
       matchLabels:
         app: nginx2
     template:
       metadata:
         name: nginx2
         labels:
           app: nginx2
       spec:
         containers:
         - name: nginx2
           image: nginx
           resources:
             limits:
               cpu: 5
             requests:
               cpu: 5

4. 使用以下YAML檔案範例，在namespace3中部署服務，其中Pod的副本數為5個，每個Pod請求CPU資源量為5核。

   • 叢集無資源空閑，但是為了保障root.b.1的Min（最少可用配額），需要搶佔root.a中的pod歸還10核。

   • 調度器會綜合考慮root.a下作業的優先順序、可用性以及建立時間等因素，選擇相應的Pod歸還之前搶佔的資源（10核）。因此，nginx3得到配額min.cpu=10的資源量後，有2個Pod處於Running狀態，其他3個仍處於Pending狀態。

   • root.a被搶佔後，namespace1下有2個pod處於Running，3個處於Pending；namespace2下也有2個pod處於Running，3個處於Pending。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx3
     namespace: namespace3
     labels:
       app: nginx3
   spec:
     replicas: 5
     selector:
       matchLabels:
         app: nginx3
     template:
       metadata:
         name: nginx3
         labels:
           app: nginx3
       spec:
         containers:
         - name: nginx3
           image: nginx
           resources:
             limits:
               cpu: 5
             requests:
               cpu: 5

5. 使用以下YAML檔案範例，在namespace4中部署服務，其中Pod的副本數為5個，每個Pod請求CPU資源量為5核

   • 這時調度器會綜合優先順序、可用性以及建立時間等因素，選擇root.a下相應的Pod搶佔，歸還之前搶佔的資源。

   • 考慮到公平性，root.a.1和root.a.2的pod會分別被搶佔一個。這時，在namespace1下有2個pod*5核/副本=10核。在namespace2下，也有2個pod*5核/副本=10核。這時namespace1和namespace2下分別有2個副本（皆為：2副本 x 5核/副本=10核）。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx4
     namespace: namespace4
     labels:
       app: nginx4
   spec:
     replicas: 5
     selector:
       matchLabels:
         app: nginx4
     template:
       metadata:
         name: nginx4
         labels:
           app: nginx4
       spec:
         containers:
         - name: nginx4
           image: nginx
           resources:
             limits:
               cpu: 5
             requests:
               cpu: 5