Cluster e nós do Kubernetes

Requisitos de cluster e nó do Kubernetes para o Automation Suite no OpenShift.

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.

Um usuário administrador deve instalar componentes específicos necessários separadamente, antes da instalação da plataforma do Automation Suite. Após instalar os componentes necessários, você pode executar o instalador. Para obter a lista de permissões necessárias, consulte Concessão de permissões de instalação.

Capacidade de nó

Para estimar a capacidade de nó com base em seu produto e requisitos de 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.

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 do pacote em cache.

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, contamine os nós com --node-taints nvidia.com/gpu=present:NoSchedule. As cargas de trabalho de GPU do Automation Suite são configuradas para tolerar apenas a chave de taint nvidia.com/gpu, portanto, você deve usar essa chave exata. Se você marcar os nós com uma chave diferente, o agendador não poderá colocar os pods da GPU no nó e eles permanecerão não agendados.

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 do OpenShift.

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

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 a Calculadora de dimensionamento da 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 ou a do site da NVIDIA:
  • Documentação da NVIDIA: suporte a MIG na plataforma OpenShift Container
  • Documentação para desenvolvedores da IBM: implementação do NVIDIA MIG no Red Hat OpenShift
• 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:

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

• Para a GPU:

  oc 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:

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