Comprobaciones de requisitos previos

Ejecuta uipathctl prereq run para validar los requisitos previos de la infraestructura para Automation Suite en OpenShift, incluido el flujo de espacio de nombres.

Se recomienda ejecutar las comprobaciones de requisitos previos para garantizar que configuraste correctamente la infraestructura en la nube y validar input.json antes de iniciar la instalación de Automation Suite.

Esta página cubre:

• Ejecutar las comprobaciones de requisitos previos
• Qué validan las comprobaciones de requisitos previos
• Ejecutar comprobaciones de requisitos previos sin roles de clúster
• Validar las comprobaciones excluidas manualmente

Ejecutar las comprobaciones de requisitos previos

Ejecuta las comprobaciones de requisitos previos con un kubeconfig que tenga acceso al ámbito del clúster. Si uipathadmin solo tiene ámbito de espacio de nombres, sigue Ejecutar comprobaciones de requisitos previos sin roles de clúster en su lugar.

Para comprobar los requisitos previos en función de las entradas que configuraste en el input.json, ejecuta el siguiente comando desde una máquina con acceso a la API de Kubernetes del clúster:

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

For details on the flags that you can use with the uipathctl prereq run command, refer to uipathctl prereq run.

De forma predeterminada, el comando uipathctl prereq comprueba todos los requisitos previos. Alternativamente, el comando también te permite ejecutar estrictamente las comprobaciones que son relevantes para ti, de la siguiente manera:

• Si quieres excluir componentes de la ejecución, utiliza la marca --excluded. Por ejemplo, si no quieres comprobar las cadenas de conexión de la base de datos, ejecuta uipathctl prereq --excluded SQL. El comando ejecuta todas las comprobaciones de requisitos previos excepto la relacionada con SQL.
• Si quieres incluir solo ciertos componentes en la ejecución, utiliza la marca --included. Por ejemplo, si solo quieres comprobar el DNS y el almacén de objetos, ejecuta uipathctl prereq --included DNS,OBJECTSTORAGE.
• Si quieres acceder a la salida detallada de la comprobación de requisitos previos, utiliza el --verbose marcador. Puedes omitir este marcador para obtener una salida más concisa y simplificada.

Nota:

You can find the names of the components you can include or exclude from the prerequisite checks in the prerequisite check output. In the example, the first word on each outdented line represents the component name. For example: SQL, OBJECTSTORE, DNS, etc.

Los requisitos previos y las comprobaciones/pruebas de estado se ejecutan en el espacio de nombres <uipath> . Debes conceder a la herramienta uipathctl los permisos necesarios para permitir la creación del espacio de nombres <uipath> o crearlo tú mismo antes de ejecutar las comprobaciones/pruebas. Además, algunas comprobaciones/pruebas requieren que habilites el uso de hostNetwork.

Para ejecutar las pruebas relacionadas con la red del host, debes permitir que la herramienta se ejecute con privilegios de administrador del clúster. De lo contrario, se muestra la siguiente advertencia en la salida de la comprobación de requisitos previos:

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"]}

Qué validan las comprobaciones de requisitos previos

Las comprobaciones de la siguiente tabla se ejecutan en cada nodo:

Comprobar	Descripción
Conexión SQL	Valida que Automation Suite pueda conectarse correctamente al servidor SQL para los productos y servicios compartidos de UiPath® (como Identity, Portal, Gestión de la organización, etc.) utilizando las cadenas de conexión SQL proporcionadas en el archivo input.json . Esto es obligatorio para una instalación correcta.
Roles de SQL DB	Valida los roles y permisos necesarios para los productos de UiPath®. Esto es obligatorio para una instalación correcta.
Compatibilidad SQL DB	Valida los requisitos de compatibilidad de SQL DB.
Resolución FQDN	Valida que el FQDN y los subdominios se puedan resolver correctamente.
API de almacenamiento de objetos	Valida que las API del almacén de objetos sean accesibles en función de la información de acceso proporcionada en el archivo input.json . Esto es obligatorio para una instalación correcta de los servicios de UiPath®.
Caché / Redis	Valida la conexión a Redis. Esto es obligatorio para una instalación correcta.
Capacidad	Valida que tienes una capacidad mínima de CPU y RAM en los nodos trabajadores en función de los productos habilitados en el archivo input.json .
ClaseDeAlmacenamiento	Valida que las clases de almacenamiento para el almacenamiento de archivos estén configuradas según sea necesario para los Robots de Automation Suite.
Componentes opcionales	Valida que su clúster tenga componentes que eligió excluir de la instalación de Automation Suite .
Ingress	Valida que la entrada del clúster esté configurada correctamente y que las solicitudes de URL FQDN puedan llegar a los productos de UiPath®.
Políticas de red	Comprueba si las políticas de red configuradas en Automation Suite son compatibles con el clúster.
Registro	Valida que Automation Suite pueda acceder al registro de UiPath® docker. Esto es obligatorio para una instalación correcta.
Conectividad de clúster	Valida si la comunicación del clúster está configurada correctamente: - Entre dos pods aleatorios completados - Entre pod y un ClusterIP multinodo - Entre el pod y un ClusterIP multinodo sin un clusterIP - Entre el pod y un ClusterIP multinodo utilizando HostNetwork - Entre el pod y un ClusterIP multinodo sin un conjunto de IP de clúster utilizando HostNetwork - Entre dos pods colocados en el mismo nodo a través de ClusterIP Connectivity checks can fail on OpenShift 4.16–4.18 control-plane nodes due to port conflicts. To address the issue, refer to the Troubleshooting section.

Ejecutar comprobaciones de requisitos previos sin roles de clúster

Nota:

Esta sección solo se aplica si concediste a la cuenta de servicio del instalador de Automation Suite (uipathadmin) permisos de ámbito de espacio de nombres, sin ningún permiso de ámbito de clúster. Para obtener más información, consulta Conceder permisos de instalación sin roles de clúster.

Si uipathadmin tiene los permisos de ámbito de clúster, ejecuta las comprobaciones de requisitos previos como se describe en Ejecutar las comprobaciones de requisitos previos .

Cuando uipathadmin solo tiene ámbito de espacio de nombres, un conjunto fijo de comprobaciones uipathctl prereq run fallan porque requieren acceso al ámbito del clúster: ya sea una lectura en un recurso del ámbito del clúster (como nodes, namespaces, storageclasses o customresourcedefinitions) o, en el caso de la comprobación de conectividad, la capacidad de utilizar la restricción de contexto de seguridad hostnetwork-v2. Usa la marca --excluded para omitir exactamente esas comprobaciones:

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

Excluir una comprobación no elimina el requisito subyacente; la propiedad sigue siendo necesaria para una instalación en buen estado. La siguiente tabla describe lo que verifica cada comprobación excluida, el acceso al ámbito del clúster que necesita y exactamente lo que un administrador del clúster debe confirmar fuera de banda, utilizando un kubeconfig con privilegios de administrador del clúster.

Token excluido	Acceso al clúster que requiere	Lo que verifica la comprobación
INGRESS	nodes [list]	Que el FQDN de Automation Suite sea accesible a través de HTTPS a través de la puerta de enlace de entrada de Istio, desde el clúster, en cada nodo.
NAMESPACE	namespaces [get, list]	Que los espacios de nombres <argocd>, el instalador y <uipath> existan, y que <uipath> lleve las etiquetas de inyección necesarias.
OSS	customresourcedefinitions [list]	Que los componentes propios que excluiste de la instalación (por ejemplo, Istio y OPA Gatekeeper) estén presentes y en una versión compatible.
StorageClass	storageclasses [get], nodes [list]	Que la clase de almacenamiento en input.json exista y pueda aprovisionar y montar un volumen en tus nodos de trabajo (la comprobación crea un StatefulSet de prueba y espera a que el volumen se vincule y monte).
NODE	nodes [list, get], métricas de nodo	Que cada nodo trabajador cumpla los requisitos mínimos de CPU y RAM y no se sobreutilice en CPU, memoria o recuento de pods.
GPU	nodes [list]	Que existan suficientes nodos etiquetados con GPU con GPU disponibles para los productos de GPU habilitados, con el recuento mínimo de nodos dependiendo de qué productos de GPU estén habilitados.
CONNECTIVITY	securitycontextconstraints use en hostnetwork-v2; roles [create] para los pods de prueba de la red del host	Que los pods puedan comunicarse a través de nodos a través de la red de superposición (por IP de pod), a través de un ClusterIP Service, y utilizando hostNetwork.

Validar las comprobaciones excluidas manualmente

Después de excluir las comprobaciones, un administrador del clúster debe validar cada requisito excluido manualmente, utilizando un kubeconfig con privilegios de administrador del clúster:

• INGRESS: confirma que todos los nodos de trabajo son Ready y que las rutas de entrada existen:

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

  La comprobación INGRESS del instalador sondea el FQDN desde dentro del clúster, en cada nodo, y trata la puerta de enlace como accesible cuando responde, incluso con un 404 o un 503 en OpenShift, porque ningún backend sirve el FQDN antes Automation Suite está instalado. No espere un 200 en esta etapa. Debido a que el comando curl anterior se ejecuta desde tu estación de trabajo, puede imprimir 000 cuando el FQDN aún no se resuelve o enruta desde tu máquina; que refleje la accesibilidad del lado del cliente y no sea en sí mismo un problema del clúster. Las señales que importan aquí son que los nodos de trabajo son Ready y las rutas de entrada existen.

• NAMESPACE: confirma que los espacios de nombres existen y que <uipath> lleva las etiquetas de inyección necesarias:

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

  La salida debe mostrar istio-injection=enabled y uipath-injection=enabled.

• OSS: confirma que los CRD están presentes, que Istio tiene una versión compatible y que la puerta de enlace configurada se está ejecutando:

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

  Confirma que la versión de Istio es 1.14.0 o superior, y que gateway_selector en input.json coincide con la puerta de enlace en ejecución.

• StorageClass: confirma que la clase de almacenamiento existe:

  kubectl get sc <name>
  

  A continuación, crea un PersistentVolumeClaim de 1 GiB para él y un pod que lo monte. Confirma que el PVC llega a Bound y que el pod se inicia en un nodo de trabajo: esto ejerce la misma compatibilidad de zona y topología que cubre la comprobación.

• NODE: confirmar la capacidad asignable y la utilización por nodo:

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

  Cada nodo debe mostrar al menos 8 CPU y 16 Gi asignables, con un uso de CPU y memoria inferior al 80 %. Comprueba el tamaño del nodo en el clúster y los nodos de Kubernetes.

• GPU: confirma que el recuento de nodos de la GPU cumple el requisito (5 nodos para proyectos modernos de Document Understanding; de lo contrario no hay mínimo) y que las GPU asignables están disponibles en esos nodos:

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

  La salida del segundo comando debe mostrar un valor mayor que 0. Para conocer los requisitos de tamaño de la GPU, consulta Clúster y nodos de Kubernetes.

• CONNECTIVITY: la opción más fiable es que un administrador de clúster ejecute solo esta comprobación con un administrador kubeconfig:

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

  Como alternativa, programa dos pods en diferentes nodos de trabajo y confirma que pueden comunicarse entre sí por la IP del pod y a través de un ClusterIP Service.

Importante:

Excluir estas comprobaciones no elimina los requisitos subyacentes; el comportamiento correspondiente sigue siendo necesario en runtime. Valida cada propiedad de la tabla anterior antes de continuar con la instalación.