Verificações de pré-requisito

Execute uipathctl prereq run para validar os pré-requisitos de infraestrutura para o Automation Suite no OpenShift, incluindo o fluxo com escopo de namespace.

É recomendável executar as verificações de pré-requisito para garantir que você configurou corretamente a infraestrutura de nuvem e para validar input.json antes de iniciar a instalação do Automation Suite.

Esta página abrange:

• Execução das verificações de pré-requisitos
• O que as verificações de pré-requisitos validam
• Execução de verificações de pré-requisitos sem funções de cluster
• Validação das verificações excluídas manualmente

Execução das verificações de pré-requisitos

Execute as verificações de pré-requisitos com um kubeconfig que tenha acesso com escopo de cluster. Se uipathadmin for apenas com escopo de namespace, siga Executando verificações de pré-requisitos sem funções de cluster .

Para verificar os pré-requisitos com base nas entradas que você configurou input.json no, execute o seguinte comando de uma máquina com acesso à API do Kubernetes do cluster:

uipathctl prereq run input.json --versions versions.json

Para obter detalhes sobre os sinalizadores que você pode usar com o comando uipathctl prereq run , consulte uipathctl prereq run.

Por padrão, o comando uipathctl prereq verifica todos os pré-requisitos. Como alternativa, o comando também permite que você execute estritamente as verificações que são relevantes para você, da seguinte forma:

• Se quiser excluir componentes da execução, use o sinalizador --excluded. Por exemplo, se você não quiser verificar as strings de conexão de banco de dados, execute uipathctl prereq --excluded SQL. O comando executa todas as verificações de pré-requisitos, exceto para a relacionada a SQL.
• Se quiser incluir apenas determinados componentes na execução, use o sinalizador --included. Por exemplo, se você quiser apenas verificar o DNS e o objectstore, execute uipathctl prereq --included DNS,OBJECTSTORAGE.
• Se você quiser acessar a saída da verificação de pré-requisitos detalhada, use o --verbose sinalizador. Você pode ignorar esse sinalizador para uma saída mais concisa e simplificada.

Observação:

Você pode encontrar os nomes dos componentes que pode incluir ou excluir das verificações de pré-requisitos na saída da verificação de pré-requisitos. No exemplo, a primeira palavra em cada linha sem identação representa o nome do componente. Por exemplo: SQL, OBJECTSTORE, DNS etc.

As verificações/testes de pré-requisitos e integridade são executadas no namespace. <uipath> Você deve conceder à ferramenta uipathctl as permissões necessárias para permitir a criação do namespace <uipath> ou criá-lo por conta própria antes de executar as verificações/testes. Além disso, algumas verificações/testes exigem que você habilite o uso de hostNetwork.

Para executar os testes relacionados à rede do host, você deve permitir que a ferramenta seja executada com privilégios de administrador do cluster. Caso contrário, o seguinte aviso é exibido na saída da verificação de pré-requisitos:

Ran CONNECTIVITY checks...
     ⚠  [CONNECTIVITY]
        ⚠  [NETWORK_TEST_SETUP] Failed to create the network test infrastructure: failed to create echo-host-role role: error creating role: roles.rbac.authorization.k8s.io "network-prereq-6c5mt-echo-host-role" is forbidden: user "system:serviceaccount:uipath:uipathadmin" (groups=["system:serviceaccounts" "system:serviceaccounts:uipath" "system:authenticated"]) is attempting to grant RBAC permissions not currently held:
{APIGroups:["security.openshift.io"], Resources:["securitycontextconstraints"], ResourceNames:["hostnetwork-v2"], Verbs:["use"]}

O que as verificações de pré-requisitos validam

As verificações na tabela a seguir são executadas em cada nó:

Marcar	Description
Conexão SQL	Valida que o Automation Suite pode conectar-se com sucesso ao SQL server para produtos da UiPath® e serviços compartilhados (como Identity, Portal, Gerenciamento de org, etc.) usando as strings de conexão SQL fornecidas no arquivo. input.json Isso é obrigatório para uma instalação bem-sucedida.
Funções de banco de dados SQL	Valida as funções e permissões necessárias exigidas pelos produtos da UiPath®. Isso é obrigatório para uma instalação bem-sucedida.
Compatibilidade do Banco de Dados SQL	Valida os requisitos de compatibilidade do Banco de Dados SQL.
Resolução FQDN	Valida que o FQDN e os subdomínios podem ser resolvidos com sucesso.
API de armazenamento de objetos	Valida que APIs do Objectstore são acessíveis com base em informações de acesso fornecidas no arquivo input.json . Isso é obrigatório para uma instalação bem-sucedida dos serviços da UiPath®.
Cache/Redis	Valida a conexão com o Redis. Isso é obrigatório para uma instalação bem-sucedida.
Capacidade	Valida que você tem capacidade mínima de CPU e RAM nos nós do trabalho com base nos produtos habilitados no arquivo input.json .
Classe de Armazenamento	Valida que as classes de armazenamento para o File Storage estão configuradas conforme necessário para Automation Suite Robots.
Componentes opcionais	Valida que seu cluster tem componentes que você escolheu excluir da instalação do Automation Suite .
Ingress	Valida que o ingresso do cluster está configurado corretamente e as solicitações de URL do FQDN podem alcançar produtos da UiPath®.
Políticas de rede	Verifica se as políticas de rede configuradas no Automation Suite são compatíveis com o cluster.
Registro	Valida que o Automation Suite pode acessar o registro do docker da UiPath®. Isso é obrigatório para uma instalação bem-sucedida.
Conectividade do cluster	Valida se a comunicação do cluster está configurada corretamente: - Entre dois pods aleatórios concluídos - Entre o pod e um ClusterIP de vários nós - Entre o pod e um ClusterIP de vários nós sem um clusterIP - Entre o pod e um ClusterIP de vários nós usando o HostNetwork - Entre o pod e um ClusterIP de vários nós sem um clusterIP definido usando a HostNetwork - Entre dois pods colocados no mesmo nó via ClusterIP As verificações de conectividade podem falhar no OpenShift 4.16–4.18 nós do plano de controle devido a conflitos de porta. Para resolver o problema, consulte a seção Solução de problemas .

Execução de verificações de pré-requisitos sem funções de cluster

Observação:

Esta seção se aplica apenas se você concedeu à conta de serviço do instalador do Automation Suite (uipathadmin) apenas permissões com escopo de namespace, sem quaisquer permissões com escopo de cluster. Para obter detalhes, consulte Concessão de permissões de instalação sem funções de cluster.

Se uipathadmin tiver as permissões com escopo de cluster, execute as verificações de pré-requisitos conforme descrito em Execução das verificações de pré-requisitos .

Quando uipathadmin é apenas com escopo de namespace, um conjunto fixo de verificações de uipathctl prereq run falha porque exigem acesso com escopo de cluster - uma leitura em um recurso com escopo de cluster (como nodes, namespaces, storageclasses ou customresourcedefinitions) ou, no caso da verificação de conectividade, a capacidade de usar a restrição de contexto de segurança hostnetwork-v2. Use o sinalizador --excluded para ignorar exatamente essas verificações:

uipathctl prereq run input.json \
  --kubeconfig <uipathadmin.kubeconfig> \
  --versions versions.json \
  --excluded "INGRESS,NAMESPACE,OSS,StorageClass,NODE,GPU,CONNECTIVITY"

Excluir uma verificação não remove o requisito subjacente; a propriedade ainda é necessária para uma instalação íntegro. A tabela a seguir descreve o que cada verificação excluída verifica, o acesso com escopo de cluster de que ela precisa e exatamente o que um administrador de cluster deve confirmar fora de faixa, usando um kubeconfig com privilégios de cluster-admin.

Token excluído	Acesso com escopo de cluster necessário	O que a verificação verifica
INGRESS	nodes [list]	Que o FQDN do Automation Suite seja acessível por HTTPS por meio do gateway de ingresso do Istio, de dentro do cluster, em cada nó.
NAMESPACE	namespaces [get, list]	Que os namespaces <argocd>, instalador e <uipath> existem e que <uipath> carrega os rótulos de injeção necessários.
OSS	customresourcedefinitions [list]	Que os componentes traga seu próprio que você excluiu da instalação (por exemplo, Istio e OPA Gatekeeper) estão presentes e em uma versão compatível.
StorageClass	storageclasses [get], nodes [list]	Que a classe de armazenamento em input.json existe e pode realmente provisionar e montar um volume em seus nós de trabalho (a verificação cria um teste StatefulSet e aguarda o volume ser vinculado e montado).
NODE	nodes [list, get], métricas de nó	Que cada nó de trabalho atenda aos requisitos mínimos de CPU e RAM e não seja utilizado em excesso na CPU, memória ou contagem de pods.
GPU	nodes [list]	Que existam nós rotulados por GPU suficientes com GPUs disponíveis para os produtos de GPU habilitados, com a contagem mínima de nós dependendo de quais produtos de GPU são habilitados.
CONNECTIVITY	securitycontextconstraints use em hostnetwork-v2; roles [create] para os pods de teste da rede do host	Esses pods podem se comunicar entre nós na rede de sobreposição (por IP do pod), por meio de um ClusterIP Service e usando hostNetwork.

Validação das verificações excluídas manualmente

Depois de excluir as verificações, um administrador de cluster deve validar cada requisito excluído manualmente, usando um kubeconfig com privilégios de cluster-admin:

• INGRESS: confirme se todos os nós de trabalho são Ready e se as rotas de ingresso existem:

  kubectl get nodes -o wide
  oc get routes -n <istio-system>
  curl -sko /dev/null -w "%{http_code}\n" https://<fqdn>
  

  A verificação do instalador INGRESS examina o FQDN de dentro do cluster, em cada nó, e trata o gateway como acessível quando ele responde - incluindo com um 404 ou um 503 no OpenShift - porque nenhum back-end atende o FQDN antes O Automation Suite está instalado. Não espere um 200 nesta fase. Como o comando curl acima é executado a partir da sua estação de trabalho, ele pode imprimir 000 quando o FQDN ainda não resolver ou rotear a partir da sua máquina; que reflete a acessibilidade no lado do cliente e não é por si só um problema de cluster. Os sinais que importam aqui são que os nós do trabalho são Ready e as rotas de ingresso existem.

• NAMESPACE: confirme se os namespaces existem e se <uipath> carrega os rótulos de injeção necessários:

  kubectl get ns <argocd> <uipath>
  kubectl get ns <uipath> --show-labels
  

  A saída deve mostrar istio-injection=enabled e uipath-injection=enabled.

• OSS: Confirme que os CRDs estão presentes, o Istio está em uma versão compatível e o gateway configurado está em execução:

  kubectl get crd | grep -E 'istio.io|gatekeeper'
  istioctl version
  oc get pods -l istio=ingressgateway -n <istio-system>
  

  Confirme que a versão do Istio é 1.14.0 ou superior e que o gateway_selector em input.json corresponde ao gateway em execução.

• StorageClass: confirme se a classe de armazenamento existe:

  kubectl get sc <name>
  

  Em seguida, crie um PersistentVolumeClaim de 1 GiB contra ele e um pod que o monte. Confirme que o PVC atinge Bound e o pod começa em um nó de trabalho - isso exercerá a mesma compatibilidade de zona e topologia que a verificação abrange.

• NODE: confirme a capacidade alocável e a utilização por nó:

  kubectl get nodes -o custom-columns=NAME:.metadata.name,CPU:.status.allocatable.cpu,MEM:.status.allocatable.memory
  kubectl top nodes
  

  Cada nó deve mostrar pelo menos 8 CPUs e 16 Gi alocáveis, com uso de CPU e memória abaixo de 80%. Verificação cruzada com o dimensionamento do nó no cluster e nos nós do Kubernetes.

• Confirme GPU a contagem de nós da GPU atende ao requisito (5 nós para projetos modernos do Document Understanding; caso contrário, sem mínimo) e que as GPUs alocáveis estejam disponíveis nesses nós:

  kubectl get nodes -l nvidia.com/gpu.present=true
  kubectl get nodes -o custom-columns=NAME:.metadata.name,GPU:.status.allocatable.'nvidia\.com/gpu'
  

  A saída do segundo comando deve mostrar um valor maior que 0. Para os requisitos de dimensionamento da GPU, consulte Cluster e nós do Kubernetes.

• CONNECTIVITY: A opção mais confiável é para um administrador de cluster executar apenas essa verificação com um kubeconfig de administrador:

  uipathctl prereq run input.json --versions versions.json --included CONNECTIVITY
  

  Alternativamente, agende dois pods em diferentes nós de trabalho e confirme que eles podem se alcançar pelo IP do pod e por meio de um ClusterIP Service.

Importante:

A exclusão dessas verificações não remove os requisitos subjacentes; o comportamento correspondente ainda é necessário no runtime. Valide cada propriedade na tabela acima antes de prosseguir para a instalação.