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 スイート] ページで、[デプロイ] をクリックします。

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

   コンポーネントがインストールされると、[コンポーネント] リストに次の情報が表示されます。

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

   • コンポーネントが更新可能な場合は、コンポーネントを [アップグレード] できます。

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

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

AI ダッシュボードをインストールして構成する

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

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

   • [未承認] が赤で表示され、[OK] ボタンが選択不可になっている場合は、ステップ 2 を実行します。

     

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

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

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

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

      3. [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": "*"
                 }
             ]
         }

      4. [名前] パラメーターを k8sWorkerRolePolicy-{ClusterID} 形式で指定し、[OK] をクリックします。

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

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

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

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

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

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

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

      

3. コンソールデータストレージ パラメーターを設定します。

   この例では、[プレインストール Mysql] が選択されています。本番環境では、[apsaradb RDS] を選択できます。詳細については、「AI ダッシュボードと AI 開発者コンソールをインストールして構成する」をご参照ください。

4. [クラウドネイティブ AI スイートをデプロイ] をクリックします。

   AI ダッシュボードのステータスが [準備完了] に変わると、AI ダッシュボードを使用できるようになります。

(オプション) データセットを作成する

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

Fashion-mnist データセット

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

1. 次のコマンドを実行して、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 のステータスを確認します。

   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. [データセットリスト] ページで、データセットを見つけ、[オペレーター] 列の [高速化] をクリックします。

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

   

ステップ 2：リソースダッシュボードを表示する

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

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

ノードダッシュボード

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

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

ステップ 3：ユーザーとクォータを管理する

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

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

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

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

クォータノードを追加してリソースクォータを設定する

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

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 にデプロイメントを作成します。デプロイメントは 5 つのポッドをプロビジョニングし、各ポッドは 5 つの CPU コアを要求します。

   弾性クォータを設定しない場合、最小 CPU リソース量が 10 (cpu.min=10) に設定されているため、ユーザーは 10 個の CPU コアしか使用できません。これは、2 つのポッドが作成されることを意味します。弾性クォータを設定した後：

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

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

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

   弾性クォータを設定しない場合、最小 CPU リソース量が 10 (cpu.min=10) に設定されているため、ユーザーは 10 個の CPU コアしか使用できません。これは、2 つのポッドが作成されることを意味します。弾性クォータを設定した後：

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

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

   • 上記の 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 つは [保留中] 状態になります。

   • root.a から 10 個の CPU コアが再利用された後、namespace1 と namespace2 の両方には、[実行中] 状態の 2 つのポッドと [保留中] 状態の 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 コアを再利用します。このシナリオでは、namespace1 で 2 つのポッド (2 ポッド x 5 CPU コア/ポッド = 10 CPU コア) が実行されています。namespace2 で 2 つのポッド (2 ポッド x 5 CPU コア/ポッド = 10 CPU コア) が実行されています。

   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