Container Service for Kubernetes:クラウドネイティブ AI スイートのデプロイと管理

スイートのデプロイ

1. ACK コンソールにログインし、左側メニューで [クラスター] をクリックします。

2. クラスター名をクリックし、左側のペインで [アプリケーション] > [クラウドネイティブ AI スイート] を選択します。

3. [デプロイ] をクリックします。

4. コンポーネントを選択し、[クラウドネイティブ AI スイートのデプロイ] をクリックします。デプロイ前にシステムが依存関係をチェックします。インストール後、[コンポーネント] リストから個々のコンポーネントを [デプロイ]、[アップグレード]、または [アンインストール] できます。

5. ack-ai-dashboard と ack-ai-dev-console をインストールした後、[クラウドネイティブ AI スイート] ページに [AI ダッシュボード] と [AI 開発者コンソール] へのリンクが表示されます。

   

AI ダッシュボードの設定

ワーカーロールへの RAM 権限の付与

AI ダッシュボードがクラスターデータにアクセスする前に、クラスターのワーカーロールにカスタム RAM ポリシーをアタッチします。

1. カスタムポリシーを作成します。

   1. RAM コンソールにログインし、左側メニューで [権限] > [ポリシー] を選択します。

   2. [ポリシーの作成] をクリックし、[JSON] タブを選択して、次のポリシーを追加します：

      {
          "Version": "1",
          "Statement": [
              {
                  "Effect": "Allow",
                  "Action": [
                      "cs:*",
                      "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"
                  ],
                  "Resource": "*"
              }
          ]
      }

   3. ポリシーに k8sWorkerRolePolicy-{ClusterID} という名前を付け、[OK] をクリックします。

2. ポリシーをクラスターのワーカーロールにアタッチします。

   1. RAM コンソールで、[ID] > [ロール] を選択し、KubernetesWorkerRole-{ClusterID} を検索します。

   2. [権限付与] をクリックします。

   3. [ポリシーの選択] で [カスタムポリシー] をクリックし、k8sWorkerRolePolicy-{ClusterID} を検索して選択し、[OK] をクリックします。

AI ダッシュボードのセットアップの完了

1. [クラウドネイティブ AI スイート] ページで、[インタラクションモード] に [サンプルコンソール] を選択します。[注意] ダイアログボックスが表示されます。

   • [承認済み] と表示されている場合は、ステップ 3 に進みます。

   • [未承認] が赤色で表示されている場合は、上記の RAM 権限の設定を完了し、[承認チェック] をクリックします。承認後、[承認済み] が表示されます。

2. [コンソールデータストレージ] を設定します。テスト用には [プリインストールされた MySQL]、本番環境用には [ApsaraDB RDS] を選択します。詳細については、「AI ダッシュボードと AI 開発者コンソールのインストールと設定」をご参照ください。

3. [クラウドネイティブ AI スイートのデプロイ] をクリックします。AI ダッシュボードのステータスが [準備完了] と表示されたら、準備完了です。

(オプション) データセットの作成と高速化

Object Storage Service (OSS) のデータセットを永続ボリューム (PV) としてマウントし、AI ダッシュボードでアクセスを高速化します。

PV と PVC の作成

1. 名前空間を作成します：

   kubectl create ns demo-ns

2. fashion-mnist.yaml という名前のファイルを作成します：

   プレースホルダー	説明	例
   fashion-mnist	OSS バケット名	my-dataset-bucket
   oss-cn-beijing.aliyuncs.com	バケットのリージョンに対応する OSS エンドポイント	oss-cn-hangzhou.aliyuncs.com
   AKID	AccessKey ID	LTAI5tXxx
   AKSECRET	AccessKey シークレット	xXxXxXx

   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-hangzhou.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. マニフェストを適用します：

   kubectl create -f fashion-mnist.yaml

4. PV と PVC がバインドされていることを確認します：

   kubectl get pv fashion-demo-pv
   kubectl get pvc fashion-demo-pvc -n demo-ns

   PV の期待される出力：

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

   PVC の期待される出力：

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

[データセットの高速化]

1. 管理者としてAI ダッシュボードにログインします。

2. 左側メニューで [データセット] > [データセットリスト] を選択します。

3. データセット (fashion-demo-pvc) を見つけ、[操作] 列の [高速化] をクリックします。

   高速化されたデータセットは新しいレコードとして表示されます。名前は fashion-demo-pvc-acc、名前空間は demo-ns、データソースは pvc://fashion-demo-pvc、[高速化済み] 列には [はい]、ステータスは [NotReady]、[操作] 列には [高速化のキャンセル] ボタンが表示されます。

クラスターダッシュボード

AI ダッシュボードはデフォルトでクラスターダッシュボードを開き、クラスター全体の GPU の健全性と割り当て状況を表示します。

GPU 使用率は、GPU がサンプル期間中に何らかの処理を実行したかどうかを示し、その効率を示すものではありません。100% のノードでも、重い並列ワークロードではなく、軽量なカーネルを実行している可能性があります。全体像をより正確に把握するためには、GPU メモリ (使用量/合計) と合わせて確認してください。

ノードダッシュボード

クラスターページの右上隅にある [ノード] をクリックすると、ノードごとおよび GPU デバイスごとの GPU メトリックを表示できます。

トレーニングジョブダッシュボード

ノードページの右上隅にある [TrainingJobs] をクリックすると、ジョブごとのリソース消費量と GPU 効率を表示できます。

リソースクォータダッシュボード

トレーニングジョブページの右上隅にある [クォータ] をクリックすると、リソースタイプ (CPU、メモリ、nvidia.com/gpu、aliyun.com/gpu-mem、aliyun.com/gpu) 別のクォータ消費量を表示できます。

クォータツリーのセットアップ

1. 各チームの名前空間を作成します。既存の名前空間をクォータノードに関連付ける前に、実行中の Pod がないことを確認する必要があります。

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

2. AI ダッシュボードでクォータノードを作成し、各リーフノードを名前空間に関連付けます。各ノードに [最小] と [最大] を設定します。

ユーザーとユーザーグループの作成

1 人のユーザーは複数のグループに所属でき、1 つのグループには複数のユーザーを含めることができます。ユーザーをグループに関連付けて、割り当てられたリソースへのアクセスを許可します。

1. ユーザーを作成します。詳細については、「新規ユーザーの kubeconfig ファイルとログオントークンの生成」をご参照ください。

2. ユーザーグループを作成します。詳細については、「ユーザーグループの追加」をご参照ください。

キャパシティスケジューリングの例

この例では、スケジューラが 4 つの名前空間にまたがって CPU リソースを共有および回収する方法を示します。クォータツリーは次の構造を持っています：

クォータ設定：

ウォークスルー：

エラスティッククォータがない場合、各リーフ名前空間は自身の最小値 (10 コア = 5 コア / Pod で 2 Pod) のみを使用します。エラスティッククォータと 40 のクラスターコアが利用可能な場合、名前空間は自身の最大値までアイドルキャパシティを借用します。

ステップ 1： namespace1 に 5 つの Pod をデプロイし、それぞれが 5 CPU コア (合計 25 コア) を要求します。

root.a.1 の最大値が 20 コアに設定されているため、4 つの Pod が実行されます (20 コア)。5 つ目の Pod は保留中のままです。

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

ステップ 2： namespace2 に 5 つの Pod をデプロイし、それぞれが 5 CPU コアを要求します。

残りの 20 コアで、4 つの Pod が実行されます。5 つ目は保留中のままです。これで namespace1 と namespace2 の両方が、ルートクォータの 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

ステップ 3： namespace3 に 5 つの Pod をデプロイし、それぞれが 5 CPU コアを要求します。

アイドルキャパシティは残っていません。スケジューラは root.b.1 の最小値を保証するために root.a から 10 コアを回収します。root.a.1 から 5 コア (namespace1 の実行中 Pod を 4 から 3 に減らす) と root.a.2 から 5 コア (namespace2 の実行中 Pod を 4 から 3 に減らす) を回収します。10 コアが回収されたことで、namespace3 で 2 つの Pod が実行されます。

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

ステップ 4： namespace4 に 5 つの Pod をデプロイし、それぞれが 5 CPU コアを要求します。

スケジューラは root.b.2 の最小値を保証するために root.a からさらに 10 コアを回収します。具体的には root.a.1 から 5 コア、root.a.2 から 5 コアです。回収後、namespace1 と namespace2 はそれぞれ 2 つの実行中 Pod (10 コア) を持ち、namespace4 では 2 つの Pod が実行されます。

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

結果：

各チームに保証された最小リソースは維持されました。他のチームが最小値を必要としたときに、借用されたキャパシティは回収されました。