Container Service for Kubernetes:クラウドネイティブAIスイートO&Mガイド

背景情報

クラウドネイティブAIスイートがインストールされているクラスターをデプロイした後、クラスターリソースを割り当て、リソース使用量を複数の次元で表示できます。 これにより、クラスターリソースの使用率を最適化できます。

クラスターが複数のユーザーによって使用されている場合、ユーザーがリソースを求めて競合する場合に備えて、各ユーザーに一定量のリソースを割り当てる必要があります。 従来の方法では、Kubernetesリソースクォータを使用して、各ユーザーに固定量のリソースを割り当てます。 ただし、リソース使用率はユーザーグループによって異なります。 クラスターリソースの全体的な使用率を向上させるために、クラスターリソースをユーザーに割り当てた後にユーザーがリソースを共有できるようにすることができます。

次の図は、企業の組織構造を示しています。 ビジネス要件に基づいて、さまざまなレベルでエラスティッククォータを設定できます。 図中の各リーフノードは、ユーザグループに対応する。 権限とクォータを個別に管理するには、ユーザーグループ内のユーザーを1つ以上の名前空間に追加し、ユーザーに異なるロールを割り当てることができます。 これにより、リソースをユーザーグループ間で共有し、同じユーザーグループ内のユーザーを分離できます。

前提条件

• Container Service for Kubernetes (ACK) Proクラスターが作成されました。 クラスターを作成するときに、コンポーネント設定ウィザードページでモニタリングエージェントとSimple Log Serviceが有効になっていることを確認します。 詳細については、「ACK Proクラスターの作成」をご参照ください。

• クラスターのKubernetesバージョンが1.18以降です。

タスク

ステップ1: クラウドネイティブAIスイートのインストール

クラウドネイティブAIスイートは、タスク弾力性、データアクセラレーション、AIタスクスケジューリング、AIタスクライフサイクル管理、AIダッシュボード、AI開発者コンソールのコンポーネントで構成されています。 ビジネス要件に基づいてコンポーネントをインストールできます。

クラウドネイティブAIスイートのデプロイ

1. ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。

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

3. [クラウドネイティブAI Suite] ページで、[デプロイ] をクリックします。 表示されるページで、インストールするコンポーネントを選択します。

4. ページの下部にある [クラウドネイティブAIスイートのデプロイ] をクリックします。 システムは、環境と選択されたコンポーネントの依存関係をチェックします。 環境と依存関係がチェックに合格した後、システムは選択したコンポーネントをデプロイします。

   コンポーネントのインストール後、コンポーネントリストに次の情報を表示できます。

   • クラスターにインストールされているコンポーネントの名前とバージョンを表示できます。 コンポーネントをデプロイまたはアンインストールできます。

   • コンポーネントが更新可能な場合は、コンポーネントを更新できます。

   • ack-ai-dashboardとack-ai-dev-consoleをインストールした後、Cloud-native AI Suiteページの左上隅にAIダッシュボードとAI開発者コンソールへのハイパーリンクが表示されます。 ハイパーリンクをクリックすると、対応するコンポーネントにアクセスできます。

5. インストールが完了すると、クラウドネイティブAI Suiteページの左上隅にAIダッシュボードとAI開発者コンソールへのハイパーリンクが表示されます。 ハイパーリンクをクリックすると、対応するコンポーネントにアクセスできます。

AIダッシュボードのインストールと設定

1. Cloud-native AI Suiteページの [インタラクションモード] セクションで、[コンソール] を選択します。 次の図に示すように、[メモ] ダイアログボックスが表示されます。

   • [許可] が表示されている場合は、手順3を実行します。

   • [Unauthorized] が赤で表示され、[OK] ボタンが暗くなっている場合は、手順2を実行します。

     

2. RAMワーカーロールに権限を付与するカスタムポリシーを作成します。

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

      1. RAM コンソールにログインします。 左側のナビゲーションウィンドウで、[権限]> [ポリシー] を選択します。

      2. [ポリシー] ページで [ポリシーの作成] をクリックします。

      3. [JSON] タブをクリックします。 [アクション] フィールドに次の内容を追加し、[次へ] をクリックしてポリシー情報を編集します。

          "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. [Name] パラメーターをk8sWorkerRolePolicy-{ClusterID} 形式で指定し、[OK] をクリックします。

   2. クラスターのRAMワーカーロールに権限を付与します。

      1. RAM コンソールにログインします。 左側のナビゲーションウィンドウで、[アイデンティティ]> [ロール] を選択します。

      2. Kubernetes WorkerRole-{ClusterID} 形式のRAMワーカーロールを検索ボックスに入力します。 管理するロールを見つけて、[操作] 列の [権限の付与] をクリックします。

      3. [ポリシーの選択] セクションで、[カスタムポリシー] をクリックします。

      4. k8sWorkerRolePolicy-{ClusterID} 形式で作成したカスタムポリシーの名前を検索ボックスに入力し、ポリシーを選択します。

      5. [OK] をクリックします。

   3. [メモ] ダイアログボックスに戻り、[権限付与チェック] をクリックします。 承認が成功すると、承認済みが表示され、[OK] ボタンが使用可能になります。 次に、ステップ3を実行します。

      

3. Console Data Storageパラメーターを設定します。

   この例では、プリインストールMySQLが選択されています。 本番環境でApsaraDB RDSを選択できます。 詳細については、「AIダッシュボードとAI開発者コンソールのインストールと設定」をご参照ください。

4. クリッククラウドネイティブAIスイートのデプロイ.

   AIダッシュボードのステータスが準備完了に変更されると、AIダッシュボードは使用可能になります。

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

アルゴリズム開発者の要件に基づいて、データセットを作成および高速化できます。 次のセクションでは、AIダッシュボードまたはCLIを使用してデータセットを作成する方法について説明します。

fashion-mnistデータセット

kubectlを使用して、クラスターノードにObject Storage Service (OSS) タイプの永続ボリューム (PV) と永続ボリューム要求 (PVC) を作成します。

1. 次のサンプルYAMLテンプレートに基づいて名前空間demo-nsを作成します。

kubectl create ns demo-ns

2. fashion-mnist.yamlという名前の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. PVとPVCを作成する:

kubectl create -f fashion-mnist.yaml

4. PVとPVCのステータスを確認します。

5. 次のコマンドを実行して、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

6. 次のコマンドを実行して、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. 管理者としてAccess AI Dashboardをします。
2. AIダッシュボードの左側のナビゲーションウィンドウで、[データセット] > [データセットリスト] を選択します。

3. On theデータセットリストページ、データセットを見つけて、加速[演算子] 列に表示されます。

   次の図は、高速化されたデータセットを示しています。

手順2: リソースダッシュボードの表示

AI Dashboardが提供するリソースダッシュボードで、クラスターリソースの使用状況を複数のディメンションで表示できます。 これにより、リソース割り当ての最適化とリソース使用率の向上に役立ちます。

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

ノードダッシュボード

Training job dashboard

リソース割り当てダッシュボード

ステップ3: ユーザーとクォータの管理

• クォータツリーを使用すると、階層的なリソースクォータを設定できます。 クォータツリーは、容量スケジューリングプラグインによって使用されます。 クラスターリソースの全体的な使用率を最適化するために、クォータツリーを使用してリソースをユーザーに割り当てた後、ユーザーがリソースを共有できるようにすることができます。

• Kubernetesの各ユーザーはサービスアカウントを所有しています。 サービスアカウントは、ジョブを送信してコンソールにログオンするための資格情報として使用できます。 権限は、ユーザーの役割に基づいてユーザーに付与されます。 たとえば、管理者ロールはAIダッシュボードにログインし、クラスターでメンテナンス操作を実行できます。 研究者ロールは、ジョブの送信、クラスターリソースの使用、AI開発者コンソールへのログインを行うことができます。 管理者ロールには、研究者ロールが持つすべての権限があります。

• ユーザーグループは、リソース割り当ての最小単位です。 各ユーザーグループは、クォータツリーのリーフノードに対応します。 ユーザーは、ユーザーグループに関連付けられたリソースを使用する前に、ユーザーグループに関連付けられている必要があります。

次のセクションでは、クォータツリーを使用して階層的なリソースクォータを設定する方法と、ユーザーグループを使用してリソースをユーザーに割り当てる方法について説明します。 次のセクションでは、単純なジョブを送信してCPUリソースを共有および再利用する方法についても説明します。

クォータノードの追加とリソースクォータの設定

各リソースのMinパラメーターとMaxパラメーターを指定することで、リソースクォータを設定できます。 Minパラメーターは、使用できるリソースの最小量を指定します。 Maxパラメーターは、使用できるリソースの最大量を指定します。 名前空間をクォータツリーのリーフノードに関連付けると、ルートノードとリーフノードの間のノードに設定された制限が名前空間に適用されます。

1. 利用可能な名前空間がない場合は、まず名前空間を作成する必要があります。 名前空間が使用可能な場合は、選択した名前空間に実行中状態のポッドが含まれていないことを確認する必要があります。

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

2. クォータノードを作成し、名前空間に関連付けます。

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

ユーザーは1つ以上のユーザーグループに所属できます。 ユーザーグループには、1人以上のユーザーを含めることができます。 ユーザーごとにユーザーグループを関連付けるか、ユーザーグループごとにユーザーを関連付けることができます。 クォータツリーとユーザーグループを使用して、プロジェクトに基づいてリソースを割り当て、権限を付与できます。

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

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

容量スケジューリングの例

次の操作を実行します。

1. 名前空間とクォータツリーを作成します。

   1. 次のコマンドを実行して、4つの名前空間を作成します。

      次のコマンドを実行してnamespace1を作成します。

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

   2. 次の図に基づいてクォータツリーを作成します。

      

2. 次のYAMLテンプレートを使用してnamespace1にデプロイを作成します。 Deploymentは5つのポッドをプロビジョニングし、各ポッドは5つのCPUコアを要求します。

   エラスティッククォータを設定しない場合、CPUリソースの最小量が10に設定されているため、ユーザーは10個のCPUコアしか使用できません。つまり、2つのポッドが作成されます。 エラスティッククォータを設定した後:

   • クラスターで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に別のデプロイを作成します。 Deploymentは5つのポッドをプロビジョニングし、各ポッドは5つのCPUコアを要求します。

   エラスティッククォータを設定しない場合、CPUリソースの最小量が10に設定されているため、ユーザーは10個のCPUコアしか使用できません。つまり、2つのポッドが作成されます。 エラスティッククォータを設定した後:

   • クラスターで20個のCPUコア (namespace1では40コア-20コア) を使用できる場合、4つのポッド (4ポッドx 5コア /ポッド=20コア) が作成されます。

   • リソースの最大量 (cpu.max=20) に達したため、最後のポッドはPending状態になります。

   • 上記の2つのデプロイメントを作成した後、namespace1とnamespace2のポッドは40個のCPUコアを使用しました。これはルートノードのCPUコアの最大数です。

   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に3つ目のデプロイを作成します。 このデプロイメントは5つのポッドを提供し、各ポッドは5つのCPUコアを要求します。

   • クラスターにアイドルリソースがありません。 スケジューラは、root.b.1のCPUリソースの最小量を保証するために、root.aから10個のCPUコアを再要求します。

   • スケジューラは、一時的に使用された10個のCPUコアを再要求する前に、root.aのワークロードの優先度、可用性、作成時間などの他の要因も考慮します。 したがって、nginx3のポッドが再利用された10個のCPUコアに基づいてスケジュールされた後、2つのポッドは実行中状態になり、他の3つは保留状態になります。

   • 10個のCPUコアがroot.aから再利用されると、namespace1とnamespace2の両方に、実行中状態の2つのポッドと、Pending状態の3つのポッドが含まれます。

   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で4つのデプロイを作成します。 このデプロイメントは5つのポッドを提供し、各ポッドは5つのCPUコアを要求します。

   • スケジューラは、各タスクの優先度、可用性、および作成時間を考慮し、root.aからCPUリソースを再要求します。

   • スケジューラは、root.a.1から1つのCPUコアを、root.a.2から1つのCPUコアを回収します。 このシナリオでは、2つのポッド (2ポッドx 5 CPUコア /ポッド=10 CPUコア) がnamespace1で実行されています。 2つのポッド (2ポッドx 5 CPUコア /ポッド=10 CPUコア) がnamespace2で実行されています。

   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