Kubernetes クラスターとノード

OpenShift の Automation Suite のための Kubernetes クラスターおよびノードの要件。

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

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

An admin user must install specific required components separately, before the Automation Suite platform installation. After installing the required components, you can execute the installer. For the list of required permissions, refer to Granting installation permissions.

ノードの容量

To estimate node capacity based on your product and scale requirements, use the UiPath Automation Suite Install Sizing Calculator.

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

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

注:

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

自動スケーリング

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

Automation Suite ロボットの追加要件

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

The hardware requirements for the Automation Suite Robots node depend on the way you plan to use your resources. In addition to the additional agent node requirements, you also need a minimum of 10 GB of file storage to enable package caching.

For details, refer to Storage documentation.

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

ロボットのサイズ

次の表で、すべてのサイズのロボットに必要な CPU、RAM、およびストレージについて説明します。

Size	CPU	RAM	ストレージ
小	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/RAM 要件で割られるためです。

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

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

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

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

Kubernetes のリソース消費量

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

• 0.6 CPU
• 0.4 GB の RAM

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

マシン サイズの自動選択

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

サイズを自動的に選択すると、次の表に示す基準が順番に評価されます。1 つの基準が満たされるとすぐに、対応するマシン サイズが選択され、残りの基準は評価されません。

順序	基準	マシン サイズ
1	リモート デバッグのジョブである	中
2	プロセスが UI Automation に依存しているか、またはプロセスが 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 nvidia.com/gpu=present:NoScheduleテインします。Automation Suite の GPU ワークロードは、 nvidia.com/gpu taint キーのみを許容するように設定されているため、この正確なキーを使用する必要があります。ノードを別のキーでテイントすると、スケジューラーは GPU ポッドをノードに配置できず、スケジュールされていないままになります。

GPU ワークロードの適切なスケジューリングを確保するには、DaemonSet (NFD または Nvidia GPU Operator) YAML 構成に一致する tolerations ブロックが含まれていることを確認します。

以下の例を使用できます。

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

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

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

CPU 推論をアクティブ化した場合は、2 つ以上の GPU が必要です。

To enable CPU inference, set the enable_cpu_inference property to true, as indicated in the Enabling or disabling Document Understanding section.

注:

推論は最大 10 倍遅くなる可能性があります。125 ページまでのドキュメントに使用することをお勧めします。このサイズの大きいドキュメントでは推論が失敗する可能性があるためです。

CPU 推論がない場合、Document Understanding モダン プロジェクトには 5 つ以上の GPU が必要です。次の表のシナリオ例は、5 GPU で 300 ページを処理する方法を示しています。

注:

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

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

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

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

GPU の需要に加えて、Document Understanding モダン プロジェクトでは、最適なパフォーマンスを得るために特定の 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 になります。

注:

For more detailed calculations and the capacity required for your needs, refer to the UiPath Automation Suite Install Sizing Calculator.

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

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

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

• GPU メモリ (VRAM): VGPU あたり少なくとも 16 GB。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 ワークロードを実行する準備が整います。

Temporal as a Service (TaaS) の追加要件

Maestro が有効な場合、TaaS はクラスター内で一連の Kubernetes デプロイとして実行されます。既定のプロファイルでは、TaaS には最低でも 5.5 個の仮想コアと 5.5 GB の使用可能なクラスター ヘッドルームの RAM が必要です。

デプロイ

TaaS は、次の Kubernetes デプロイで構成され、それぞれが Temporal サービス内の個別の機能を担当します。

デプロイ	説明
taas-temporal-frontend	Temporal サービスへのすべてのクライアント接続のエントリ ポイント
taas-temporal-internalFrontend	クラスター内のサービス間通信を処理します
taas-temporal-history	ワークフローの実行履歴とステート遷移を管理します
taas-temporal-matching	スケジュールされたタスクを、実行可能なワーカーと一致させます
taas-temporal-worker	時間システムの内部ワークフローを処理します
taas-temporal-web	ワークフローを視覚化および監視するための Web UI
taas-temporal-admintools	クラスター内で一時的な管理コマンドを発行するためのユーティリティのデプロイ

ポッドのリソース要件

次の表に、各 TaaS デプロイの CPU とメモリの要求と制限を示します。リソース設定は、すべての TaaS プロファイルで同じです。

デプロイ	CPU 要求	CPU 制限	メモリ要求	メモリ制限
taas-temporal-frontend	250メートル	1	256マイル	256マイル
taas-temporal-internalFrontend	250メートル	1	256マイル	256マイル
taas-temporal-history	250メートル	1	4Giの	4Giの
taas-temporal-matching	250メートル	1	512マイル	512マイル
taas-temporal-worker	100メートル	1	256マイル	256マイル
taas-temporal-web	100メートル	200メートル	128マイル	128マイル
taas-temporal-admintools	100メートル	200メートル	128マイル	128マイル

自動スケーリング

TaaS では、一部のデプロイに Horizontal Pod Autoscaler (HPA) を使用します。スケーリングの動作は、次の表に示すように、TaaS プロファイルによって異なります。

	既定 (Default)	Lite	Ha
自動スケーリングが有効	いいえ	はい	はい
作成された HPA	0	4	4
taas-temporal-frontend レプリカ	1 (静的)	1–3 (CPU 80%)	2–3 (CPU 80%)
taas-temporal-internalFrontend レプリカ	1 (静的)	1–3 (CPU 80%)	2–3 (CPU 80%)
taas-temporal-history レプリカ	1 (静的)	1–5 (CPU 80% + Mem 70%)	2–5 (CPU 80% + Mem 70%)
taas-temporal-matching レプリカ	1 (静的)	1–3 (CPU 80%)	2–3 (CPU 80%)
taas-temporal-worker レプリカ	1 (静的)	1 (静的)	2 (静的)
taas-temporal-web レプリカ	1 (静的)	1 (静的)	1 (静的)
taas-temporal-admintools レプリカ	1 (静的)	1 (静的)	1 (静的)
Pdb	を無効化しました	enabled	enabled
numHistoryシャード	64	128	256

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

ノードの taint とラベルは Automation Suite ロボットに必要です。Document Understanding では、この方法をお勧めします。

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 ロボットの例:

Automation Suite ロボット用の正しい taint とラベルを使用して、専用のワーカー ノードを構成する必要があります。これらがないと、asrobots ポッドは、他のノードで使用可能なリソースに関係なく、スケジュールに失敗します。

次のコマンドの両方を実行します。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 のドキュメントをご覧ください。

セルフホスト モデルの追加要件

セルフホスト モデルには GPU ハードウェアが必要です。最小要件はモデルのサイズによって異なります。

モデルのサイズ	GPU の最小構成
7Bパラメータ	1 × 80 GB GPU
70Bパラメータ	4 × 80 GB GPU
120B+ パラメーター	8 × 80 GB GPU

For details, refer to Self-hosted models.