Cluster et nœuds Kubernetes

Exigences et configuration de l'infrastructure Kubernetes pour Automation Suite sur EKS/AKS.

Cluster et autorisations

Vous pouvez apporter votre propre cluster Kubernetes et appliquer vos pratiques classiques pour l’enregistrer et le gérer.

Si vous accordez les privilèges d’administrateur du programme d’installation d’Automation Suite, UiPath® installe et gère tous les composants nécessaires à l’exécution d’Automation Suite. Cependant, si vous ne pouvez pas accorder au programme d'installation des privilèges d'administrateur sur le cluster, l'installation de certains composants requis est impossible.

Par conséquent, avant d'installer Automation Suite sur un cluster auquel vous n'avez pas accordé de privilèges d'administrateur du programme d'installation, un utilisateur administrateur doit installer des composants requis spécifiques séparément, avant l'installation de la plate-forme Automation Suite.

Effectuez les étapes suivantes si vous ne pouvez pas accorder des privilèges d'administrateur au programme d'installation d'Automation Suite :

• Installez et configurez le service mesh Istio. Pour de plus amples informations, consultez la section Installation et configuration du service mesh.
• Fournissez votre propre ArgoCD. Pour de plus amples informations, consultez la section Installer et configurer l'outil GitOps.
• Créez et gérez vous-même les certificats. Pour de plus amples informations, consultez la section Certificats générés lors de l'installation.
• Créez un compte de service et accordez les autorisations nécessaires à l’installation d’Automation Suite. Pour de plus amples informations, consultez la section Accorder des autorisations d'installation.

Après avoir installé les composants requis, vous pouvez exécuter le programme d'installation avec des autorisations inférieures. Pour obtenir la liste des autorisations requises, consultez la section Accorder des autorisations d’installation.

Versions d'EKS/AKS prises en charge

Chaque version de l'assistance longue durée d'Automation Suite est accompagnée d'une matrice de compatibilité. Pour connaître les versions compatibles, consultez la section Matrice de compatibilité.

Nous avons testé la compatibilité d'Automation Suite avec les systèmes d'exploitation Linux suivants :

Fournisseur de cloud	Système d'exploitation
AKS	Ubuntu 22.04
EKS	Amazon Linux 2 jusqu'à EKS 1.32 Amazon Linux 2023 pour toutes les versions EKS Bottlerocket 1.48.0

Automation Suite sur EKS/AKS ne prend en charge que l'architecture EKS/AKS x86, et ARM64 n'est pas pris en charge.

Capacité du nœud

Pour estimer la capacité de nœud en fonction des exigences de votre produit et de votre échelle, utilisez le calculateur de dimensionnement d'installation d'UiPath Automation Suite.

L'exigence de volume racine pour les nœuds d'agent (travailleur) est de 256 Go.

Au minimum, pour commencer avec les services de plate-forme obligatoires (identité, licences et routage) et Orchestrator, vous devez enregistrer 8 processeurs virtuels et 16 Go de RAM par nœud.

Remarque :

Nous vous déconseillons d'utiliser des instances ponctuelles dans Automation Suite dans les scénarios de production, en raison de problèmes de stabilité et de performances.

Mémoire d’échange

Vous devez désactiver la mémoire d’échange avant d’installer Automation Suite. Il a été constaté que la mémoire d’échange provoquait des problèmes avec les charges de travail des conteneurs. Par ailleurs, les charges de travail d’Automation Suite ne bénéficient pas de l’utilisation de la mémoire d’échange, d’autant plus que Kubernetes optimise déjà l’utilisation de la mémoire.

Mise à l'échelle automatique

Nous vous recommandons d'activer la mise à l'échelle automatique sur votre cluster pour garantir une fiabilité élevée et éviter les interruptions d'activité.

Exigences supplémentaires pour les Automation Suite Robots

Automation Suite Robot nécessite un ou plusieurs nœuds de travail supplémentaires.

La configuration matérielle requise pour le nœud d'Automation Suite Robots dépend de la façon dont vous prévoyez d'utiliser vos ressources. Outre la configuration requise supplémentaire pour le nœud d'agent, vous avez également besoin d'un minimum de 10 Go de stockage de fichiers pour activer la mise en cache des packages.

Pour de plus amples informations, consultez la documentation sur le stockage .

Les sections suivantes décrivent les facteurs qui ont un impact sur la quantité de matériel requise par le nœud d'Automation Suite Robots.

Taille du robot

Le tableau suivant décrit le processeur, la RAM et le stockage requis pour toutes les tailles de Robot.

Taille	Processeur	RAM	Stockage
Petite	0,5	1 Go	1 Go
Standard	1	2 Go	2 Go
Moyenne	2	4 Go	4 Go
Grande	6	10 GB	10 GB

Taille du nœud d'agent

Les ressources du nœud de l'agent d'Automation Suite Robots ont un impact sur le nombre de tâches pouvant être exécutées simultanément. Cela s'explique par le fait que le nombre de cœurs de processeur et la quantité de capacité de RAM sont divisés par les configurations requises en termes de processeur/RAM de la tâche.

Par exemple, un nœud avec 16 processeurs et 32 Go de RAM pourrait exécuter l'un des éléments suivants :

• 32 petites tâches ;
• 16 tâches standard
• 8 tâches moyennes ;
• 2 tâches volumineuses

Les tailles de tâches peuvent être mélangées. Ainsi, à tout moment, le même nœud peut exécuter une combinaison de tâches, comme suit :

• 10 petites tâches (consommant 5 processeurs et 10 Go de RAM)
• 4 tâches standard (utilisant 4 processeurs et 8 Go de RAM);
• 3 Tâches moyennes (utilisant 6 processeurs et 12 Go de RAM)

Utilisation des ressources Kubernetes

Étant donné que le nœud fait partie d'un cluster Kubernetes, l'agent Kubernetes présent sur le serveur (kubelet) utilise une petite quantité de ressources. D’après nos mesures, le kubelet consomme les ressources suivantes :

• 0,6 de processeur ;
• 0,4 Go de RAM

Un nœud similaire à celui décrit précédemment aurait en réalité environ 15,4 processeurs et 31,6 Go de RAM.

Sélection automatique de la taille de la machine

All your cross-platform processes have the Automation Suite Robots option set to Automatic by default. This setting selects the appropriate machine size for running the process using serverless robots.

Lors du choix automatique de la taille, les critères répertoriés dans la table suivante sont évalués dans l'ordre. Dès qu'un critère est satisfait, la taille de machine correspondante est choisie et les critères restants ne sont pas évalués.

Ordre	Critère	Taille de la machine
1	Tâche de débogage à distance	Moyenne
2	Le processus dépend d’ UI Automation OU le processus dépend des activités UiPath Document Understanding	Standard
3	Autre processus non assisté (unattended)	Petite

Autres recommandations pour Document Understanding

Pour des performances améliorées, vous pouvez installer Document Understanding sur un nœud d’agent supplémentaire avec prise en charge de GPU. Notez cependant que les projets basés sur AI Center dans Document Understanding sont entièrement fonctionnels sans le nœud GPU. De fait, Document Understanding utilise des machines virtuelles de processeur pour toutes ses tâches d’extraction et de classification, tandis que pour l’OCR, nous recommandons fortement l’utilisation d’une machine virtuelle GPU.

Pour des détails sur l’utilisation du processeur/GPU dans l’infrastructure Document Understanding, consultez la section Utilisation du processeur et du processeur graphique.

Si vous souhaitez utiliser un nœud supplémentaire avec prise en charge du GPU, vous devez répondre aux exigences suivantes :

Matériel	Configuration minimale requise
Processeur	8 (v-)CPU/cœurs
RAM	52 Go
Disque du système d'exploitation	SSD de 256 Go IOPS minimum : 1 100
DataDisk	S/O
RAM GPU	11 Go

Lors de l’ajout du pool de nœuds GPU, il est important que vous utilisiez --node-taints nvidia.com/gpu=present:NoSchedule au lieu de --node-taints sku=gpu:NoSchedule.

Pour garantir que les charges de travail GPU soient correctement planifiées, assurez-vous que votre configuration YAML DaemonSet (NFD ou Nvidia GPU Operator) comprend un bloc tolerations correspondant.

Vous pouvez utiliser l'exemple suivant :

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

Automation Suite prend en charge les GPU NVIDIA. Pour en savoir plus sur la configuration des GPU NVIDIA (comme les pilotes), reportez-vous à la documentation officielle d'Azure ou à la documentation AWS.

Exigences supplémentaires pour les projets modernes de Document Understanding

Lorsque l'inférence de processeur est activée, un minimum de 2 GPU est requis.

Pour activer l'inférence du processeur, définissez la propriété enable_cpu_inference sur true, comme indiqué dans la section Activer ou désactiver Document Understanding .

Remarque :

L'inférence peut être jusqu'à 10 fois plus lente. Nous le recommandons pour les documents d'un maximum de 125 pages, car l'inférence peut échouer pour les documents plus volumineux.

Sans inférence de processeur, un minimum de 5 GPU est requis pour les projets modernes Document Understanding. L’exemple du scénario du tableau suivant montre comment 5 GPU sont suffisants pour traiter 300 pages.

Remarque :

Pour les projets modernes Document Understanding, le GPU minimum recommandé est NVIDIA T4.

Function	Numérique
Pages de modèle personnalisées traitées par heure	300
Modèle prêt à l'emploi pages traitées par heure	0
Entraînement des modèles en parallèle	1
Nombre de pages dans tous les projets - Durée de conception	200
Nombre de types de documents par version de projet	3

Les 5 GPU sont répartis entre différentes fonctions, comme détaillé dans le tableau suivant :

Service	Nombre de GPU
Réplicas OCR	1
Réplicas d'entraînement de modèle personnalisés	1
Réplicas de modèle personnalisés	2
Réplicas de modèle prêts à l'emploi	1
Total	5

Pour plus d’informations sur l’allocation des GPU à chaque service, reportez-vous à la page Attribuer les ressources GPU pour les projets modernes Document Understanding .

Outre les exigences du GPU, les projets modernes Document Understanding nécessitent également des ressources CPU spécifiques pour des performances optimales. Pour des performances optimales, un minimum de 18 processeurs virtuels est requis.

Avec le projet moderne Document Understanding, 4 To de objectstore supplémentaires sont nécessaires pour effectuer les activités des exemples fournis en continu pendant un an. Vous pouvez commencer avec un nombre plus petit, mais l'activité échouera une fois le stockage terminé, sauf si vous le faites passer explicitement.

Si vous enregistrez pour un an de traitement continu, vous aurez besoin de 4 To pour les projets modernes Document Understanding et de 512 Go pour les autres produits. Le total sera de 4,5 To de stockage. De même, si vous commencez avec six mois de traitement, vous aurez besoin de 2 To pour les projets modernes Document Understanding et de 512 Go pour les autres produits. Dans ce cas, le total sera de 2,5 To.

Remarque :

Pour obtenir des calculs plus détaillés et connaître la capacité requise en fonction de vos besoins, consultez le calculateur de dimensionnement d’installation d’UiPath Automation Suite.

Enregistrement des GPU compatibles MIG

Les charges de travail Automation Suite Document Understanding prennent en charge l'exécution sur des GPU virtuels (VCPU) créés avec la technologie NVIDIA MIG (GPU multi-instances).

Pour exécuter Document Understanding dans ces conditions, gardez à l’esprit les exigences suivantes :

• Mémoire GPU: au moins 16 Go par VCPU. UiPath ne prend en charge que la stratégie unique, ce qui signifie que tous les VCPU seront exactement les mêmes.
• Stockage : au moins 80 Go par GPUPU

Activation des GPU activés par MIG dans Kubernetes

Après avoir enregistré les GPU activés par MIG dans votre cluster avec des profils correspondant ou dépassant les exigences minimales ci-dessus, assurez-vous que les GPU sont des Kubernetes planifiables. Le nœud doit signaler un nombre non nul de GPU avant que les charges de travail puissent y être planifiées.

Pour rendre les GPU planifiables, deux options s'offrent à vous :

• Option A : suivez la documentation officielle de configuration du GPU de votre fournisseur cloud :
  • Azure Kubernetes Service (AKS)
  • Amazon Elastic Kubernetes Service (Amazon EKS)
• Option B (Alternative) : Déployez le plug-in de l'appareil NVIDIA directement :
  1. Créez un nouvel espace de noms :

     kubectl create namespace gpu-resources
     

  2. Appliquez la configuration suivante, en remplaçant migEnabledPoolName par le libellé qui correspond à votre nœud 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
     

Après le déploiement du plugin, la section Allouable du nœud doit afficher le nombre correct de VGPU sous nvidia.com/gpu, en fonction du profil MIG que vous avez configuré. Le nœud doit désormais être planifiable et prêt pour exécuter les charges de travail Document Understanding.

Exigences supplémentaires pour Temporel en tant que service (TaaS)

Lorsque Maestro est activé, SaaS s'exécute sous la forme d'un ensemble de déploiements Kubernetes au sein du cluster. Dans le profil par défaut, SaaS nécessite un minimum de 5,5 vCores et 5,5 Go de RAM de cluster disponible.

Déploiements

TaaS comprend les déploiements Kubernetes suivants, chacun responsable d’une fonction distincte au sein du service Temporal :

Déploiement	Description
taas-temporal-frontend	Point d’entrée pour toutes les connexions client au service Temporel
taas-temporal-internalFrontend	Gère la communication interservices interne au sein du cluster
taas-temporal-history	Gère l'historique d'exécution des workflows et les transitions d'états
taas-temporal-matching	Faites correspondre les tâches planifiées avec les travailleurs disponibles pour l'exécution
taas-temporal-worker	Processus - Workflows internes du système temporel
taas-temporal-web	IU Web pour visualiser et surveiller les workflows
taas-temporal-admintools	Déploiement de services publics pour l’émission de commandes d’administration temporelles au sein du cluster

Configuration requise en matière de ressources de pod

Le tableau suivant répertorie les requêtes et les limites de processeur et de mémoire pour chaque déploiement SaaS. Les paramètres de ressource sont les mêmes pour tous les profils SaaS.

Déploiement	Requête de processeur	Limite de processeur	Requête de mémoire	Limite de mémoire
taas-temporal-frontend	250 min	1	256 Mo	256 Mo
taas-temporal-internalFrontend	250 min	1	256 Mo	256 Mo
taas-temporal-history	250 min	1	4 Go	4 Go
taas-temporal-matching	250 min	1	512 Mo	512 Mo
taas-temporal-worker	100 min	1	256 Mo	256 Mo
taas-temporal-web	100 min	200 min	128 Mo	128 Mo
taas-temporal-admintools	100 min	200 min	128 Mo	128 Mo

Mise à l'échelle automatique

TaaS utilise Horizontal Pod Autoscaler (HPA) pour certains déploiements. Le comportement de mise à l'échelle dépend du profil TaaS, comme décrit dans le tableau suivant.

	Default	Lite	Haute disponibilité
Mise à l'échelle automatique activée	Non (No)	Oui (Yes)	Oui (Yes)
HPA créés	0	4	4
taas-temporal-frontend Réplicas	1 (statique)	1 à 3 (processeur 80 %	2 – 3 (processeur 80 »
taas-temporal-internalFrontend Réplicas	1 (statique)	1 à 3 (processeur 80 %	2 – 3 (processeur 80 »
taas-temporal-history Réplicas	1 (statique)	1 – 5 (processeur 80 % + mémoire 70 »	2 – 5 (processeur 80 % + mémoire 70 »
taas-temporal-matching Réplicas	1 (statique)	1 à 3 (processeur 80 %	2 – 3 (processeur 80 »
taas-temporal-worker Réplicas	1 (statique)	1 (statique)	2 (statique)
taas-temporal-web Réplicas	1 (statique)	1 (statique)	1 (statique)
taas-temporal-admintools Réplicas	1 (statique)	1 (statique)	1 (statique)
PDB	disabled	enabled	enabled
Nombre Partitions Historiques	64	128	256

Planification des nœuds

Les rejets et les libellés de nœuds sont requis pour les Automation Suite Robots. Pour Document Understanding, elles sont recommandées.

Exemple d'AI Center et du DU :

• Pour le processeur :

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

• Pour le GPU :

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

ExempleAutomation Suite Robot :

Vous devez configurer un nœud de travail dédié avec le rejet et les libellés corrects pour les Automation Suite Robots. Sans ceux-ci, les pods asrobots ne peuvent pas se planifier, quelles que soient les ressources disponibles sur les autres nœuds.

Exécutez les deux commandes suivantes - le rejet seul ne suffit pas:

kubectl taint node <node_name> serverless.robot=present:NoSchedule
kubectl label node <node_name> serverless.robot=true serverless.daemon=true

Important :

Si vous avez des rejets de nœud personnalisés qui sont appliqués par la politique de garde d'accès, tels que des rôles spécifiques pour les nœuds de travail ou les libellés, ils ne seront pas transmis à Automation Suite et peuvent interrompre le processus d'installation.

Pour en savoir plus sur les rejets et les tolérances, consultez la documentation de Kubernetes.

Exigences supplémentaires du modèle auto-hébergé

Les modèles auto-hébergés nécessitent du matériel GPU. Les exigences minimales dépendent de la taille du modèle :

Taille du modèle	Configuration minimale du GPU
Paramètres 7B	1 x GPU de 80 Go
70 Mo de paramètres	4 x GPU 80 Go
120 Mo et plus de paramètres	8 x GPU 80 Go

Pour de plus amples informations, consultez la section Modèles auto-hébergés.