Kubernetes クラスターとノード

EKS/AKS の Automation Suite の Kubernetes インフラストラクチャの要件と構成。

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

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

Automation Suite インストーラーの管理者権限を付与すると、Automation Suite の実行に必要なコンポーネントはすべて UiPath® がインストールおよび管理します。ただし、クラスターに対するインストーラーの管理者権限を付与できない場合、必要なコンポーネントの一部はインストールできません。

したがって、インストーラーの管理者権限を付与していないクラスターに Automation Suite をインストールする前に、管理者ユーザーは Automation Suite プラットフォームをインストールする前に、特定の必須コンポーネントを個別にインストールする必要があります。

Automation Suite インストーラーに管理者権限を付与できない場合は、次の手順を実行します。

• Istio サービス メッシュをインストールして構成します。詳しくは、「 サービス メッシュをインストールおよび構成する」をご覧ください。
• 独自の ArgoCD を利用できます。詳しくは、「 GitOps ツールをインストールおよび設定する」をご覧ください。
• 証明書は自分で作成して管理します。詳しくは、「 インストール時に生成される証明書」をご覧ください。
• サービス アカウントを作成し、Automation Suite のインストールに必要な権限を付与します。詳しくは、「 インストール権限を付与する」をご覧ください。

必要なコンポーネントをインストールした後は、低い権限でインストーラーを実行できます。必要な権限のリストは、「 インストール許可を付与する」をご覧ください。

サポートされる EKS/AKS バージョン

Automation Suite ロング ターム サポートの各リリースには相互運用性マトリクスが付属しています。互換性のある EKS または AKS のバージョンについては、「 相互運用性マトリクス」をご覧ください。

Automation Suite と以下の Linux OS との互換性をテストしました。

クラウド プロバイダー	OS
AKS	Ubuntuの22.04
EKS	Amazon Linux 2 から EKS 1.32 まで Amazon Linux 2023 (EKS のすべてのバージョン) ボトルロケット 1.48.0

EKS/AKS の Automation Suite は、x86 EKS/AKS のアーキテクチャのみをサポートし、ARM64 はサポートしていません。

ノードの容量

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

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

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

注:

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

スワップ メモリ

Automation Suite をインストールする前に、スワップ メモリを無効化する必要があります。スワップ メモリは、コンテナ ワークロードで問題を引き起こすことが知られています。さらに、Automation Suite のワークロードではスワップ メモリを使用するメリットが無く、Kubernetes ではメモリの使用がすでに最適化されています。

自動スケーリング

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

Automation Suite ロボットの追加要件

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

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

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

次のセクションでは、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 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 がサポートされています。NVIDIA GPU (ドライバーなど) の設定方法については、 Azure の公式ドキュメント または AWS のドキュメントをご覧ください。

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

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

CPU 推論を有効化するには、「Document Understanding を有効化または無効化する」セクションに示すように、[enable_cpu_inference] プロパティを [true] に設定します。

注:

推論は最大 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 モダン プロジェクトに GPU リソースを割り当てる 」をご覧ください。

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 になります。

注:

詳細な計算方法とニーズに必要な容量については、「 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 セットアップの公式ドキュメントに従います。
  • Azure Kubernetes Service (AKS)
  • Amazon Elastic Kubernetes Service (Amazon EKS)
• オプション 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 の場合:

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

• GPU の場合:

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

Automation Suite ロボットの例:

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

次のコマンドの両方を実行します。taint だけでは不十分です。

kubectl taint node <node_name> serverless.robot=present:NoSchedule
kubectl 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

詳しくは、「 セルフホスト モデル」をご覧ください。