Kubernetes クラスターとノード

クラスターとアクセス許可

独自の Kubernetes クラスターを利用し、標準のプラクティスに従ってプロビジョニングおよび管理できます。

管理者ユーザーは、Automation Suite プラットフォームをインストールする前に、特定の必須コンポーネントを個別にインストールする必要があります。 必要なコンポーネントをインストールしたら、インストーラーを実行できます。 必要な権限のリストについては、「 インストール権限を付与する」をご覧ください。

ノードの容量

製品とスケールの要件に基づいてノードの容量を推定するには、UiPath Automation Suite Install Sizing Calculator を使用します。

エージェント (ワーカー) ノードのルートボリューム要件は 256 GB です。

必須のプラットフォーム サービス (Identity、ライセンス、ルーティング) と Orchestrator で開始するには、少なくともノードあたり 8 個の vCPU と 16 GB の RAM をプロビジョニングする必要があります。

注:

Automation Suite のスポット インスタンスを運用シナリオで使用することは、安定性とパフォーマンスの問題があるためお勧めしません。

自動スケーリング

高い信頼性を確保し、ビジネスの中断を回避するため、クラスターで自動スケーリングを有効化することをお勧めします。

Automation Suite ロボットの追加要件

Automation Suite ロボットには追加のワーカー ノードが必要です。

Automation Suite ロボット ノードのハードウェア要件は、リソースの使用方法によって異なります。追加のエージェント ノードの要件に加えて、 パッケージのキャッシュ を有効にするために 10 GB 以上のファイル ストレージも必要です。

詳しくは、 ストレージに関する ドキュメントをご覧ください。

次のセクションでは、Automation Suite ロボット ノードで必要なハードウェアの量に影響する要因について説明します。

ロボットのサイズ

次の表に、すべてのロボット サイズに必要な CPU、メモリ、およびストレージを示します。

Size	CPU	メモリ	ストレージ
小	0.5	1 GB	1 GB
標準	1	2 GB	2 GB
中	2	4 GB	4 GB
大	6	10 GB	10 GB

エージェント ノードのサイズ

Automation Suite ロボット エージェント ノードのリソースは、同時に実行できるジョブの数に影響します。その理由は、CPU コアの数と RAM の容量が、ジョブの CPU/メモリ要件で除算されるためです。

たとえば、16 CPU と 32 GB の RAM を搭載したノードは、次のいずれかを実行できます。

• 32 個の小型のジョブ
• 16 個の標準ジョブ
• 8 個の中型のジョブ
• 2 個の大型のジョブ

複数のジョブ サイズを混在できるため、特定の時点において、同じノードで次のようなジョブの組み合わせを実行できます。

• 10 個の小型のジョブ (5 CPU と 10 GB のメモリを消費)
• 4 個の標準ジョブ (4 CPU と 8 GB のメモリを消費)
• 3 個の中型のジョブ (6 CPU と 12 GB のメモリを消費)

Kubernetes のリソース消費量

ノードは Kubernetes クラスターに属しているため、サーバー上に存在する Kubernetes エージェント (kubelet) は少量のリソースを消費します。UiPath の測定結果によると、Kubelet が消費するリソースは以下のとおりです。

• 0.6 CPU
• 0.4 GB の RAM

前述のノードと同様のノードでは、実際の容量は約 15.4 CPU と 31.6 GB の RAM になります。

マシン サイズの自動選択

すべてのクロスプラットフォーム プロセスでは、[Automation Suite ロボット] のオプションが既定で [自動] に設定されています。この設定では、サーバーレス ロボットを使用してプロセスを実行するのに適したマシン サイズが選択されます。

サイズの自動選択にあたっては、以下の表に記載された基準が順番に評価されます。ある基準が満たされた時点で、その基準に対応するマシン サイズが選択され、残りの基準は評価されません。

順序	基準	マシン サイズ
1	リモート デバッグのジョブである	中
2	プロセスが UI Automation に依存している OR プロセスが UiPath Document Understanding アクティビティに依存している	標準
3	その他の無人プロセス	小

Document Understanding の追加の推奨事項

パフォーマンスを向上させるには、GPU がサポートされた追加のエージェント ノードに Document Understanding をインストールできます。 ただし、Document Understanding の AI Center に基づくプロジェクトは、GPU ノードがなくても完全に機能します。 実際には、Document Understanding はすべての抽出および分類タスクに CPU 仮想マシンを使用しますが、OCR には GPU 仮想マシンを使用することを強くお勧めします。

Document Understanding フレームワーク内での CPU/GPU の使用方法の詳細については、「 CPU と GPU の使用」をご覧ください。

GPU サポートのある追加のノードを使用する場合、次の要件を満たす必要があります。

ハードウェア	最小要件
プロセッサ	8 (v-)CPU/コア
RAM	52ギガバイト
OS ディスク	256 GB SSD 最小 IOPS: 1100
データ ディスク	N/A
GPU RAM	11ギガバイト

GPU ノード プールを追加する際は、--node-taints sku=gpu:NoSchedule ノード プールではなく --node-taints nvidia.com/gpu=present:NoSchedule を使用することが重要です。

大事な： GPU ワークロードのスケジュールを適切に設定するには、DaemonSet (NFD または Nvidia GPU Operator) YAML 構成に次のものが含まれていることを確認してください 一致する tolerations ブロック。以下の例を使用できます。

tolerations:
  - key: "nvidia.com/gpu"
    operator: "Equal"
    value: "present"
    effect: "NoSchedule"

Automation Suite では NVIDIA GPU がサポートされています。 NVDIA GPU (ドライバーなど) の設定方法については、 OpenShift のドキュメントをご覧ください。

Document Understanding モダン プロジェクトの追加要件

Document Understanding モダン プロジェクトには 5 つ以上の GPU が必要です。 次の表のシナリオ例は、300 ページを処理するには 5 つの GPU で十分であることを示しています。

手記： Document Understanding モダン プロジェクトで推奨される最小 GPU は NVIDIA T4 です。

機能	Number
1 時間あたりに処理されるカスタム モデルのページ数	300
すぐに使えるモデルの 1 時間あたりに処理されるページ数	0
並列でトレーニングするモデルのトレーニング	1
すべてのプロジェクトのページ数 - 設計時	200
プロジェクト バージョンごとのドキュメントの種類の数	3

5 つの GPU は、次の表に示すように、さまざまな機能に分散されています。

サービス	GPU の数
OCR レプリカ	1
カスタム モデルのトレーニング レプリカ	1
カスタム モデルのレプリカ	2
すぐに使えるモデルのレプリカ	1
合計	5

各サービスへの GPU の割り当て方法について詳しくは、「Microsoft Cloud のリソースを割り当てる」をご覧ください。

Document Understanding モダン プロジェクトでは、GPU の需要に加えて、最適なパフォーマンスを得るために特定の CPU リソースも必要になります。 最適なパフォーマンスを得るには、 18 個以上の vCPU が必要です。

最新の Document Understanding プロジェクトでは、提供されている例のアクティビティを 1 年間継続して実行するために、追加で 4 TB の objectstore が必要です。 より小さい数から始めることができますが、明示的に拡大縮小しない限り、ストレージが完了するとアクティビティは失敗します。

1 年間の継続的処理のためにプロビジョニングする場合、Document Understanding モダン プロジェクトに 4 TB、その他の製品に 512 GB が必要です。 合計で 4.5 TB のストレージになります。 同様に、6 か月の処理から開始する場合、Document Understanding モダン プロジェクトには 2 TB、その他の製品には 512 GB が必要です。 この場合、合計は 2.5 TB になります。

手記： 詳細な計算方法とニーズに必要な容量については、「 UiPath Automation Suite Install Sizing Calculator」をご覧ください。

MIG 対応 GPU のプロビジョニング

Automation Suite の Document Understanding ワークロードは、NVIDIA MIG (マルチインスタンス GPU) テクノロジで作成された仮想 GPU (VGPU) での実行をサポートします。

これらの条件で Document Understanding を実行するには、次の要件に注意してください。

• GPUメモリ(VRAM):VGPUあたり16GB以上

  注:UiPath単一の戦略のみをサポートしているため、すべてのVGPUはまったく同じになります。

• ストレージ:VGPUあたり80GB以上

Kubernetes で MIG 対応 GPU を有効化する

上記の最小要件と一致するか超えるプロファイルを持つ MIG 対応 GPU をクラスターにプロビジョニングしたら、GPU がスケジュール可能な Kubernetes であることを確認します。ノードは、ワークロードをスケジュールする前に、ゼロ以外の数の GPU を報告する必要があります。

GPU をスケジュール可能にするには、次の 2 つのオプションがあります。

• オプション A: お使いのクラウド プロバイダーの公式の GPU セットアップ ドキュメントまたは NVIDIA の Web サイトにあるドキュメントに従います。
  • NVIDIA ドキュメント: OpenShift Container Platform での MIG サポート
  • IBM 開発者向け資料: Red Hat OpenShift での NVIDIA MIG の実装
• オプション B (代替): NVIDIA デバイス プラグインを直接デプロイします。
  1. 新しい名前空間を作成します。

     kubectl create namespace gpu-resources

  2. 次の構成を適用して、 に一致するラベルで migEnabledPoolName します。 GPU ノード:

     apiVersion: v1
     kind: Pod
     metadata:
       name: nvidia-device-plugin-pod
       namespace: gpu-resources
     spec:
      affinity:
         nodeAffinity:
           requiredDuringSchedulingIgnoredDuringExecution:
             nodeSelectorTerms:
             - matchExpressions:
               - key: agentpool
                 operator: In
                 values:
                 # To be changed to a selector that matches the GPU nodes
                 - migEnabledPoolName
      containers:
      - args:
        - --fail-on-init-error=false
        env:
        - name: MPS_ROOT
          value: /run/nvidia/mps
        - name: MIG_STRATEGY
           # We only support the single strategy for now
          value: single
        - name: NVIDIA_MIG_MONITOR_DEVICES
          value: all
        - name: NVIDIA_VISIBLE_DEVICES
          value: all
        - name: NVIDIA_DRIVER_CAPABILITIES
          value: compute,utility
        image: nvcr.io/nvidia/k8s-device-plugin:v0.17.3
        imagePullPolicy: IfNotPresent
        name: nvidia-device-plugin-ctr
        securityContext:
          allowPrivilegeEscalation: true
          capabilities:
            add:
            - SYS_ADMIN
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /var/lib/kubelet/device-plugins
          name: device-plugin
      tolerations:
      - key: CriticalAddonsOnly
        operator: Exists
      - effect: NoSchedule
        key: nvidia.com/gpu
        operator: Exists
      terminationGracePeriodSeconds: 30
      volumes:
      - hostPath:
          path: /var/lib/kubelet/device-plugins
          type: ""
        name: device-plugin

プラグインをデプロイすると、ノードの [Allocatable ] セクションに、構成した MIG プロファイルに基づいて nvidia.com/gpuに VGPU の正しい数が表示されます。これで、ノードがスケジュール可能になり、Document Understanding ワークロードを実行する準備が整います。

ノードのスケジュール設定

Automation Suite ロボットと Document Understanding 用の専用のワーカー ノードでは、ノード taint を有効化することをお勧めします。

AI Center と DU の例:

• CPU の場合:

  oc taint node <node_name> aic.ml/cpu=present:NoSchedule

• GPU の場合:

  oc taint node <node_name> nvidia.com/gpu=present:NoSchedule

Automation Suite ロボットの例:

• 次のコマンドを使用して、サーバーレス ロボットの taint を追加します。

  oc taint node <node_name> serverless.robot=present:NoSchedule

• 次のコマンドを使用して、サーバーレス ロボットのラベルを追加します。

  oc label node <node_name> serverless.robot=true serverless.daemon=true

重要:

Gatekeeper のポリシーによって適用されるカスタムのノード taint がある場合 (ワーカー ノードに対する特定のロールやラベルなど)、そのノード taint は Automation Suite に渡されないため、インストール プロセスが中断する可能性があります。

taint と toleration について詳しくは、Kubernetes のドキュメントをご覧ください。