Kubernetes クラスターとノード

EKS/AKS で Automation Suite を実行するための Kubernetes クラスターとノードの要件、およびプロビジョニング オプション。

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

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

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

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

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

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

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

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

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

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

クラウド プロバイダー	OS
AKS	Ubuntuの22.04 Ubuntuの24.04
EKS	Amazon Linux 2 および Amazon Linux 2023 (EKS のすべてのバージョン) Bottlerocket 1.19.2

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 ではメモリの使用がすでに最適化されています。

自動スケーリング

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

Task Mining の追加要件

Task Mining をインストールする場合は、20 個の vCPU と 60 GB の RAM を搭載したワーカー ノードを追加でプロビジョニングする必要があります。このノードには taint を付与し、Task Mining のワークロードのみが実行されるようにする必要があります。詳しくは、「ノードのスケジュール設定」セクションをご覧ください。

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	リモート デバッグのジョブである	中
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 ワークロードを実行する準備が整います。

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

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

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
  

Task Mining の例:

kubectl taint node <node_name> task.mining/cpu=present:NoSchedule

Automation Suite ロボットの例:

• 次のコマンドを使用して、サーバーレス ロボットの 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 のドキュメントをご覧ください。