Cluster e nós do Kubernetes

Requisitos e configuração de infraestrutura do Kubernetes para o Automation Suite no EKS/AKS.

Cluster e permissões

Você pode trazer seu próprio cluster do Kubernetes e seguir suas práticas padrão para provisioná-lo e gerenciá-lo.

Se você conceder os privilégios de administrador do instalador do Automation Suite, a UiPath® instala e gerencia todos os componentes necessários para executar o Automation Suite. No entanto, se você não puder conceder privilégios de administrador ao instalador no cluster, a instalação de alguns componentes necessários é impossível.

Portanto, antes de instalar o Automation Suite em um cluster em que você não concedeu privilégios de administrador ao instalador, um usuário administrador deve instalar componentes específicos necessários separadamente, antes da instalação da plataforma do Automation Suite.

Execute as seguintes etapas se não puder conceder privilégios de administrador ao instalador do Automation Suite:

• Instale e configure o service mesh do Istio. Para obter detalhes, consulte Instalação e configuração do service mesh.
• Traga seu próprio ArgoCD. Para obter detalhes, consulte Instalação e configuração da ferramenta GitOps.
• Crie e gerencie certificados por conta própria. Para obter detalhes, consulte Certificados gerados durante a instalação.
• Crie uma conta de serviço e conceda as permissões necessárias para a instalação do Automation Suite. Para obter detalhes, consulte Conceder permissões de instalação.

Após instalar os componentes necessários, você pode executar o instalador com permissões mais inferiores. Para obter a lista de permissões necessárias, consulte Conceder permissões de instalação.

Versões do EKS/AKS compatíveis

Cada versão de suporte de longo prazo do Automation Suite vem com uma matriz de compatibilidade. Para versões EKS ou AKS compatíveis, consulte a matriz de Compatibilidade.

Testamos a compatibilidade do Automation Suite com os seguintes sistemas operacionais Linux:

Provedor de nuvem	SO
AKS	Ubuntu 22.04
EKS	Amazon Linux 2 até EKS 1.32 Amazon Linux 2023 para todas as versões do EKS Bottlerocket 1.48.0

O Automation Suite no EKS/AKS oferece suporte apenas à arquitetura x86 EKS/AKS e não oferece suporte ao ARM64.

Capacidade de nó

Para estimar a capacidade do nó com base em seus requisitos de produto e escala, use a Calculadora de dimensionamento de instalação do UiPath Automation Suite.

O requisito de volume raiz para nós de agente (trabalhador) é de 256 GB.

No mínimo, para começar com os serviços de plataforma obrigatórios (Identity, licenciamento e roteamento) e o Orchestrator, você deve provisionar 8 vCPU e 16 GB de RAM por nó.

Observação:

Não recomendamos o uso de instâncias regulares no Automation Suite em cenários de produção, devido a problemas de estabilidade e desempenho.

Trocar memória

Você deve desabilitar a memória de troca antes de instalar o Automation Suite. Sabe-se que a memória de troca causa problemas com cargas de trabalho de contêineres. Além disso, as cargas de trabalho do Automation Suite não se beneficiam do uso de memória de troca, e o Kubernetes já otimiza o uso da memória.

Escalonamento automático

Recomendamos habilitar o escalonamento automático em seu cluster para garantir a alta confiabilidade e evitar interrupções nos negócios.

Requisitos adicionais de robôs do Automation Suite

Automation Suite Robot precisa de nós de trabalho adicionais.

Os requisitos de hardware para o nó Automation Suite Robots dependem da maneira como você planeja usar seus recursos. Além dos requisitos adicionais do nó do agente, você também precisa de um mínimo de 10 GB de armazenamento de arquivos para habilitar o armazenamento em cache do pacote.

Para obter detalhes, consulte a documentação de armazenamento .

As seções a seguir descrevem os fatores que afetam a quantidade de hardware que o nó Robots do Automation Suite requer.

Tamanho do robô

A tabela a seguir descreve a CPU, a RAM e o armazenamento necessários para todos os tamanhos de Robots.

Tamanho	CPU	BATER	Armazenamento
Pequeno	0.5	1 GB	1 GB
Padrão	1	2 GB	2 GB
Médio	2	4GB	4GB
Grande	6	10 GB	10 GB

Tamanho do nó do agente

Os recursos do nó do agente dos Automation Suite Robots têm um impacto no número de trabalhos que podem ser executados simultaneamente. O motivo é que o número de núcleos de CPU e a quantidade de capacidade de RAM são divididos pelos requisitos de CPU/RAM do trabalho.

Por exemplo, um nó com 16 CPUs e 32 GB de RAM seria capaz de executar qualquer um dos seguintes:

• 32 pequenos trabalhos
• 16 trabalhos padrão
• 8 trabalhos médios
• 2 trabalhos grandes

Os tamanhos de trabalho podem ser misturados, portanto, a qualquer momento, o mesmo nó pode executar uma combinação de trabalhos, como o seguinte:

• 10 trabalhos pequenos (consumindo 5 CPUs e 10 GB de RAM)
• 4 trabalhos padrão (consumindo 4 CPUs e 8 GB de RAM)
• 3 trabalhos médios (consumindo 6 CPUs e 12 GB de RAM)

Consumo de recursos do Kubernetes

Dado que o nó faz parte de um cluster Kubernetes, o agente Kubernetes presente no servidor (kubelet) consome uma pequena quantidade de recursos. Com base em nossas medições, o kubelet consome os seguintes recursos:

• CPU 0,6
• 0,4GB RAM

Um nó semelhante ao descrito anteriormente teria, na verdade, aproximadamente 15,4 CPUs e 31,6 GB de RAM.

Seleção automática do tamanho da máquina

Todos os seus processos multiplataforma têm a opção Automation Suite Robots definida como Automático por padrão. Essa configuração seleciona o tamanho da máquina apropriado para executar o processo usando Serverless Robots.

Ao escolher automaticamente o tamanho, os critérios listados na tabela a seguir são avaliados por ordem. Assim que um critério é satisfeito, o tamanho da máquina correspondente é escolhido, e os critérios restantes não são avaliados.

Ordenar	Critério	Tamanho da Máquina
1	Trabalho de depuração remota	Médio
2	O processo depende da Automação de Interface Gráfica OU o processo depende das atividades do UiPath Document Understanding	Padrão
3	Outro processo Unattended	Pequeno

Recomendações adicionais do Document Understanding

Para obter maior desempenho, você pode instalar o Document Understanding em um nó de agente adicional com suporte a GPU. Observe, no entanto, que os projetos baseados no AI Center no Document Understanding são totalmente funcionais sem o nó da GPU. Na verdade, o Document Understanding usa VMs de CPU para todas as suas tarefas de extração e classificação; já para o OCR, recomendamos fortemente o uso de uma VM de GPU.

Para obter detalhes sobre o uso de CPUs/GPUs dentro da estrutura do Document Understanding, consulte Uso de CPUs e GPUs.

Se você quiser usar um nó adicional com suporte a GPU, deverá atender aos seguintes requisitos:

Hardware	Requerimento mínimo
Processador	8 (v-)CPU/cores
BATER	52 GB
disco do SO	IOPS mínimo da SSD de 256 GB: 1100
Data Disk	N/A
GPU RAM	11 GB

Ao adicionar o pool de nós da GPU, é importante que você use --node-taints nvidia.com/gpu=present:NoSchedule em vez de --node-taints sku=gpu:NoSchedule.

Para garantir o agendamento adequado de cargas de trabalho de GPU, certifique-se de que sua configuração YAML do DaemonSet (NFD ou Nvidia GPU) inclua um bloco tolerations correspondente.

Você pode usar o seguinte exemplo:

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

O Automation Suite suporta GPUs NVIDIA. Para saber sobre como configurar as GPUs da NVIDIA (como drivers), consulte a documentação oficial do Azure ou a documentação da AWS.

Requisitos adicionais de projetos modernos do Document Understanding

Com a inferência de CPU ativada, é necessário um mínimo de 2 GPUs.

Para habilitar a inferência de CPU, defina a propriedade enable_cpu_inference como true, conforme indicado na seção Habilitando ou desabilitando o Document Understanding .

Observação:

A inferência pode ser até 10 vezes mais lenta. Recomendamos usá-la para documentos com no máximo 125 páginas, pois a inferência pode falhar para documentos maiores.

Sem inferência de CPU, um mínimo de 5 GPUs é necessário para projetos modernos do Document Understanding. O cenário de exemplo na tabela a seguir demonstra como 5 GPUs são suficientes para processar 300 páginas.

Observação:

Para projetos modernos do Document Understanding, a GPU mínima recomendada é NVIDIA T4.

Função	Número
Páginas de modelo personalizado processadas por hora	300
Páginas de modelo prontas para uso processadas por hora	0
Treinamento de modelos em paralelo	1
Número de páginas em todos os projetos - Tempo de design	200
Número de tipos de documentos por versão do projeto	3

As 5 GPUs são distribuídas entre diferentes funções, conforme detalhado na tabela a seguir:

Serviço	Número de GPUs
Réplicas OCR	1
Réplicas de treinamento do modelo personalizado	1
Réplicas do modelo personalizado	2
Réplicas de modelos prontas para uso	1
Total	5

Para obter mais informações sobre como alocar GPUs para cada serviço, consulte a página Alocação de recursos de GPU para projetos modernos do Document Understanding .

Além das demanda de GPU, os projetos modernos do Document Understanding também exigem recursos específicos de CPU para um desempenho ideal. Para um desempenho ideal, é necessário um mínimo de 18 vCPUs .

Com o projeto moderno do Document Understanding, 4 TB adicionais do objectstore são necessários para realizar as atividades dos exemplos fornecidos continuamente por um ano. Você pode começar com um número menor, mas a atividade falhará assim que o armazenamento for concluído, a menos que você o dimensione explicitamente.

Se você estiver provisionando para um ano de processamento contínuo, precisará de 4 TB para projetos modernos do Document Understanding e 512 GB para os outros produtos. O total será de 4,5 TB de armazenamento. Da mesma forma, se você começar com seis meses de processamento, precisará de 2 TB para projetos modernos do Document Understanding e 512 GB para os outros produtos. Neste caso, o total será de 2,5 TB.

Observação:

Para obter cálculos mais detalhados e a capacidade necessária para suas necessidades, consulte Calculador de dimensionamento de instalação do UiPath Automation Suite.

Provisionamento de GPUs habilitadas para MIG

As cargas de trabalho do Automation Suite Document Understanding são suportadas em execução em GPUs virtuais (VGPUs) criadas com a tecnologia NVIDIA MIG (Multi-Instance GPU).

Para executar o Document Understanding nessas condições, tenha em mente os seguintes requisitos:

• Memória da GPU (VRAM): pelo menos 16 GB por VGPU. A UiPath é compatível apenas com a única estratégia, o que significa que todas as VGPUs serão exatamente iguais.
• Armazenamento: pelo menos 80 GB por VGPU

Habilitando GPUs habilitadas para MIG no Kubernetes

Após provisionar as GPUs habilitadas para MIG em seu cluster com perfis que correspondam ou excedam os requisitos mínimos acima, certifique-se de que as GPUs sejam Kubernetes programáveis. O nó deve relatar um número diferente de zero de GPUs antes que cargas de trabalho possam ser agendadas nele.

Para tornar as GPUs programáveis, você tem duas opções:

• Opção A: siga a documentação oficial de configuração da GPU do seu provedor de nuvem:
  • Serviço do Azure Kubernetes (AKS)
  • Serviço Elastic Kubernetes (Amazon EKS)
• Opção B (Alternativa): implante o plug-in de dispositivo da NVIDIA diretamente:
  1. Crie um novo namespace:

     kubectl create namespace gpu-resources
     

  2. Aplique a seguinte configuração, substituindo migEnabledPoolName pelo rótulo que corresponde ao seu nó de 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
     

Após implantar o plug-in, a seção Alocar do nó deve mostrar o número correto de VGPUs sob nvidia.com/gpu, com base no perfil do MIG que você configurou. O nó agora deve ser programável e estar pronto para executar cargas de trabalho do Document Understanding.

Requisitos adicionais do Temporal as a Service (TaaS)

Quando o Maestro está habilitado, o TaaS é executado como um conjunto de implantações do Kubernetes dentro do cluster. No perfil padrão, o TaaS requer um mínimo de 5,5 vCores e 5,5 GB de RAM de espaço de cluster disponível.

Implantações

O TaaS consiste nas seguintes implantações do Kubernetes, cada um responsável por uma função distinta dentro do serviço Temporal:

Implantação	Description
taas-temporal-frontend	Ponto de entrada para todas as conexões do cliente com o serviço Temporal
taas-temporal-internalFrontend	Lida com a comunicação interna entre serviços dentro do cluster
taas-temporal-history	Gerencia o histórico de execução do fluxo de trabalho e as transições de estado
taas-temporal-matching	Corresponde tarefas agendadas aos trabalhadores disponíveis para execução
taas-temporal-worker	Processa fluxos de trabalho internos do sistema Temporal
taas-temporal-web	UI da Web para visualizar e monitorar fluxos de trabalho
taas-temporal-admintools	Implantação de utilitário para emitir comandos de administrador Temporal dentro do cluster

Requisitos de recursos do pod

A tabela a seguir lista as solicitações e limites de CPU e memória para cada implantação do TaaS. As configurações de recursos são as mesmas em todos os perfis do TaaS.

Implantação	Solicitação de CPU	Limite de CPU	Solicitação de memória	Limite de memória
taas-temporal-frontend	250 m	1	256mi	256mi
taas-temporal-internalFrontend	250 m	1	256mi	256mi
taas-temporal-history	250 m	1	4Gi	4Gi
taas-temporal-matching	250 m	1	512Mi	512Mi
taas-temporal-worker	100 m	1	256mi	256mi
taas-temporal-web	100 m	200 m	128 Mi	128 Mi
taas-temporal-admintools	100 m	200 m	128 Mi	128 Mi

Escalonamento automático

O TaaS usa o dimensionador horizontal automático de pod (HPA) para implantações selecionadas. O comportamento de dimensionamento depende do perfil TaaS, conforme descrito na tabela a seguir.

	Padrão	Lite	HA
Escalonamento automático habilitado	Não	Sim	Sim
HPA criados	0	4	4
taas-temporal-frontend Réplicas	1 (estático)	1–3 (CPU 80%)	2–3 (CPU 80%)
taas-temporal-internalFrontend Réplicas	1 (estático)	1–3 (CPU 80%)	2–3 (CPU 80%)
taas-temporal-history Réplicas	1 (estático)	1-5 (CPU 80% + Mem 70%)	2-5 (CPU 80% + Mem 70%)
taas-temporal-matching Réplicas	1 (estático)	1–3 (CPU 80%)	2–3 (CPU 80%)
taas-temporal-worker Réplicas	1 (estático)	1 (estático)	2 (estático)
taas-temporal-web Réplicas	1 (estático)	1 (estático)	1 (estático)
taas-temporal-admintools Réplicas	1 (estático)	1 (estático)	1 (estático)
PDBs	disabled	enabled	enabled
Núm.ShardsDeHistórico	64	128	256

Agendamento de nós

Os taints de nó e os rótulos são necessários para os Automation Suite Robots. Para o Document Understanding, eles são recomendados.

Exemplo do AI Center e do DU:

• Para a CPU:

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

• Para a GPU:

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

ExemploAutomation Suite Robot :

Você deve configurar um nó de trabalho dedicado com o taint e os rótulos corretos para os Automation Suite Robots. Sem eles, os pods do asrobots falham ao agendar, independentemente dos recursos disponíveis em outros nós.

Execute os dois comandos a seguir - o taint sozinho não é suficiente:

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

Importante:

Se você tiver taints de nó personalizados que são aplicados pela Política do Gateway, como funções específicas para nós ou rótulos de trabalho, eles não serão passados para o Automation Suite e poderão interromper o processo de instalação.

Para saber sobre taints e tolerations, consulte a documentação do Kubernetes.

Requisitos adicionais do modelo auto-hospedado

Modelos auto-hospedados exigem hardware de GPU. Os requisitos mínimos dependem do tamanho do modelo:

Tamanho do modelo	Configuração mínima da GPU
Parâmetros 7B	1 GPU de 80 GB
Parâmetros 70B	GPU de 4 x 80 GB
Mais de 120 B de parâmetros	GPU de 8 x 80 GB

Para obter detalhes, consulte Modelos auto-hospedados.