- Información general
- Requisitos
- Plantillas de implementación
- Manual: preparar la instalación
- Manual: preparar la instalación
- Paso 2: configurar el registro compatible con OCI para las instalaciones sin conexión
- Paso 3: configurar el almacén de objetos externo
- Paso 4: configurar High Availability Add-on
- Paso 5: configurar las bases de datos SQL
- Paso 6: configurar el equilibrador de carga
- Paso 7: configurar el DNS
- Paso 8: configurar los discos
- Paso 9: configurar los ajustes a nivel de kernel y sistema operativo
- Paso 10: configurar los puertos de nodo
- Paso 11: aplicar ajustes varios
- Paso 12: Validar e instalar los paquetes RPM necesarios
- Paso 13: Generar cluster_config.json
- Configuración de certificados
- Configuración de la base de datos
- Configuración del almacén de objetos externo
- Configuración de URL prefirmada
- Configuración de la autenticación Kerberos
- Configuración de registro externo compatible con OCI
- Disaster recovery: configuraciones activas/pasivas y activas/activas
- Configuración de High Availability Add-on
- Configuración específica de Orchestrator
- Configuración específica de Insights
- Process Mining-specific configuration
- Configuración específica de Document Understanding
- Automation Suite Robots-specific configuration
- Configuración de la supervisión
- Opcional: configurar el servidor proxy
- Opcional: habilitación de la resistencia a fallos de zona en un clúster multinodo de producción preparada para alta disponibilidad
- Opcional: pasar resolv.conf personalizado
- Optional: Increasing fault tolerance
- parámetros de install-uipath.sh
- Inclusión de un nodo agente dedicado compatible con GPU
- Añadir un nodo agente dedicado a Task Mining
- Conexión de la aplicación Task Mining
- Añadir un nodo agente dedicado a Automation Suite Robots
- Paso 15: configurar el registro temporal de Docker para las instalaciones sin conexión
- Paso 16: validar los requisitos previos para la instalación
- Manual: realizar la instalación
- Después de la instalación
- Administración de clústeres
- Gestionar los productos
- Primeros pasos con el Portal de administración del clúster
- Migrar del en el clúster a High Availability Add-on externo
- Migrar del registro en clúster a un registro externo compatible con OCI
- Cambiar manualmente al clúster secundario en una configuración activa/pasiva
- Disaster Recovery: realizar operaciones posteriores a la instalación
- Convertir una instalación existente en una configuración en varios sitios
- Directrices sobre la actualización de una implementación activa/pasiva o activa/activa
- Directrices sobre la copia de seguridad y restauración de una implementación activa/pasiva o activa/activa
- Redireccionando el tráfico de los servicios no compatibles al clúster principal
- Escalar una implementación de nodo único (evaluación) a una implementación multinodo (HA)
- Supervisión y alertas
- Migración y actualización
- Paso 1: Mover los datos de la organización de identidad de independiente a Automation Suite
- Paso 2: restaurar la base de datos del producto independiente
- Paso 3: Realizar una copia de seguridad de la base de datos de la plataforma en Automation Suite
- Paso 4: Fusionar organizaciones en Automation Suite
- Paso 5: actualizar las cadenas de conexión de los productos migrados
- Paso 6: migrar el Orchestrator independiente
- Paso 7: migrar Insights independiente
- Paso 8: Migrar Test Manager independiente
- Paso 9: eliminar el tenant predeterminado
- Realizar una migración de un solo tenant
- Migrar de Automation Suite en Linux a Automation Suite en EKS / AKS
- Actualizar Automation Suite
- Descargar los paquetes de instalación y obtener todos los archivos del primer nodo del servidor
- Recuperar la última configuración aplicada del clúster
- Actualizar la configuración del clúster
- Configurar el registro compatible con OCI para las instalaciones sin conexión
- Ejecutar la actualización
- Realizar operaciones posteriores a la actualización
- Configuración específica del producto
- Uso de la herramienta de configuración de Orchestrator
- Configurar parámetros de Orchestrator
- Configuración de Orchestrator
- Configurar AppSettings
- Configurar el tamaño máximo de la solicitud
- Anular la configuración de almacenamiento a nivel de clúster
- Configurar almacenes de credenciales
- Configurar clave de cifrado por tenant
- Limpiar la base de datos de Orchestrator
- Buenas prácticas y mantenimiento
- Solución de problemas
- Cómo solucionar los problemas de los servicios durante la instalación
- Cómo desinstalar el clúster
- Cómo limpiar los artefactos sin conexión para mejorar el espacio en disco
- Cómo borrar datos de Redis
- Cómo habilitar el registro de Istio
- Sacar a Ceph del modo solo lectura
- Cómo limpiar los registros antiguos almacenados en el depósito sf-logs
- Cómo deshabilitar los registros de transmisión para AI Center
- Cómo depurar instalaciones de Automation Suite fallidas
- Cómo eliminar imágenes del instalador antiguo después de la actualización
- Cómo deshabilitar la descarga de la suma de comprobación TX
- Cómo actualizar desde Automation Suite 2022.10.10 y 2022.4.11 a 2023.10.2
- Cómo establecer manualmente el nivel de registro de ArgoCD en Info
- Cómo expandir el almacenamiento de AI Center
- Cómo generar el pull_secret_value codificado para registros externos
- Cómo abordar los cifrados débiles en TLS 1.2
- Cómo trabajar con certificados
- Cómo reenviar registros de aplicaciones a Splunk
- Cómo limpiar las imágenes de Docker no utilizadas de los pods de registro
- Cómo recopilar datos de uso de DU con el almacén de objetos en el clúster (Ceph)
- Cómo instalar RKE2 SELinux en entornos aislados
- Cómo limpiar copias de seguridad diferenciales antiguas en un servidor NFS
- No se puede ejecutar una instalación sin conexión en el sistema operativo RHEL 8.4
- Error al descargar el paquete
- La instalación sin conexión falla porque falta un binario
- Error en la comprobación de requisitos previos para el módulo iscsid de selinux
- Azure disk not marked as SSD
- Fallo tras la actualización del certificado
- El antivirus causa problemas de instalación
- Automation Suite not working after OS upgrade
- Automation Suite requiere que backlog_wait_time se establezca en 0
- El volumen no se puede montar porque no está listo para las cargas de trabajo
- Error de recopilación de registros del paquete de soporte
- Se ignora la cadena de conexión SQL de la automatización de pruebas
- Configuración de DNS no respetada por CoreDNS
- Pérdida de datos al reinstalar o actualizar Insights tras la actualización de Automation Suite
- La actualización de nodo único falla en la etapa de tejido
- Upgrade fails due to unhealthy Ceph
- El volumen no se puede montar y permanece en estado de bucle de conexión/desconexión
- La actualización falla debido a objetos clásicos en la base de datos de Orchestrator
- El clúster de Ceph se encuentra en un estado degradado tras una actualización en paralelo.
- Un componente Insights en mal estado provoca el fallo de la migración
- La actualización del servicio falla para Apps
- Tiempos de actualización in situ
- La migración del registro de Docker se atasca en la fase de eliminación de PVC
- Error de aprovisionamiento de AI Center después de actualizar a 2023.10 o posterior
- La actualización falla en entornos sin conexión
- La validación SQL falla durante la actualización
- pod de snapshot-controller-crds en estado CrashLoopBackOff después de la actualización
- Error de actualización/reinstalación del punto final de la API REST de Longhorn
- La actualización falla debido a los tamaños de PVC de Insights anulados
- La actualización del servicio falla durante la ejecución del script previo al servicio
- Fallo al cargar o descargar datos en el almacén de objetos
- PVC resize does not heal Ceph
- Fallo en el redimensionamiento de PVC de objectstore
- Error de archivo adjunto de volumen de StatefulSet
- Rook Ceph o Looker pod atascados en estado Init
- Error al compactar las métricas debido a bloques corruptos en Thanos
- Establecer un intervalo de tiempo de espera para los portales de gestión
- La autenticación no funciona tras la migración
- kinit: no se puede encontrar la KDC para el territorio <AD Domain> mientras se obtienen las credenciales iniciales
- kinit: keytab no contiene claves adecuadas para *** mientras se obtienen las credenciales iniciales
- Error en la operación GSSAPI debido a un código de estado no válido
- Alarma recibida por un error en el trabajo de Kerberos-tgt-update
- Proveedor de SSPI: servidor no encontrado en la base de datos de Kerberos
- Error en inicio de sesión de un usuario AD debido a una cuenta deshabilitada
- ArgoCD login failed
- Fallo en la obtención de la imagen de Sandbox
- Los pods no se muestran en la interfaz de usuario de ArgoCD
- Fallo de la sonda Redis
- El servidor RKE2 no se inicia
- ArgoCD entra en estado de progreso tras la primera instalación
- Mitigación manual de Política de red de ArgoCD (GHSA-47m3-95c7-g2g8)
- Unhealthy services after cluster restore or rollback
- Faltan métricas de Ceph-rook en los paneles de supervisión
- Los pods no pueden comunicarse con FQDN en un entorno de proxy
- Error al configurar las alertas de correo electrónico después de la actualización
- No hay problema ascendente en buen estado
- Error al añadir nodos agente en entornos sin conexión
- El acceso a FQDN devuelve RBAC: error de acceso denegado
- Document Understanding no se encuentra en la barra izquierda de Automation Suite
- Estado fallido al crear una sesión de etiquetado de datos
- Estado fallido al intentar implementar una habilidad ML
- El trabajo de migración falla en ArgoCD
- El reconocimiento de la escritura manual con el extractor de formularios inteligente no funciona
- Error en la implementación de la habilidad ML debido a la caducidad del token
- Ejecutar alta disponibilidad con Process Mining
- La ingestión de Process Mining falló al iniciar sesión con Kerberos
- Después de Disaster Recovery, Dapr no funciona correctamente para Process Mining
- Configurar Dapr con Redis en modo clúster
- No se puede conectar a la base de datos AutomationSuite_ProcessMining_Warehouse utilizando una cadena de conexión en formato pyodbc
- La instalación de Airflow falla con sqlalchemy.exc.ArgumentError: no se pudo analizar la URL rfc1738 de la cadena ''
- Cómo añadir una regla de tabla de IP para utilizar el puerto 1433 de SQL Server
- El certificado de Automation Suite no es de confianza desde el servidor donde se ejecuta CData Sync
- Ejecutar la herramienta de diagnóstico
- Uso del paquete de soporte de Automation Suite
- Explorar registros
Iniciar y apagar un nodo
Iniciar y apagar nodos en un clúster de Automation Suite, incluido el comportamiento de inicio y apagado manual y automático.
Esta página explica el ComportamientoDeApagado y de inicio manuales y automáticos de Automation Suite.
Siempre debes proceder apagando un nodo, realizando la operación requerida, esperando hasta que el nodo esté en buen estado y luego apagando el otro nodo para realizar la misma operación.
La siguiente tabla describe diferentes escenarios que puedes experimentar al apagar los servicios o nodos del clúster. La tabla proporciona acciones detalladas que debes realizar para cada situación, junto con orientación para comprender el comportamiento esperado en respuesta a estas acciones.
| Escenario | Acción | Comportamiento esperado |
|---|---|---|
| Apagar los servicios del clúster en un nodo sin apagar el nodo, por mantenimiento o por cualquier otro motivo. |
| En un escenario de alta disponibilidad, la mayoría de los servicios permanecerán activos. El nodo debería iniciarse sin problemas y cualquier servicio inactivo debería reiniciarse. |
| Cerrar todos los servicios del clúster sin apagar los nodos, por mantenimiento o por cualquier otro motivo. |
| Los servicios dejarán de estar disponibles. Los nodos deberían iniciarse sin problemas. |
| Apagando todos los nodos. | Si tu portal de gestión de hipervisor (como VMware, AWS) permite que los servicios se apaguen correctamente sin forzar la terminación de la máquina, realiza un apagado normal. De forma predeterminada, el subsistema systemd permite un período de gracia para que los servicios se apaguen antes de que se terminen por la fuerza. Sin embargo, si tu sistema sobrescribe los tiempos de apagado configurados, puede interferir con un apagado correcto. Por ejemplo, en AWS, la plataforma puede forzar la terminación de una máquina virtual después de dos minutos. Como tal, los servicios deben apagarse manualmente, ya que un drenaje de nodo puede tardar hasta 5 minutos (este es un requisito para un apagado correcto). | Si el apagado es correcto, los nodos deberían iniciarse sin problemas. |
| Apagar un nodo individual. | Si tu portal de gestión de hipervisor (como VMware, AWS) permite que los servicios se apaguen correctamente sin forzar la terminación de la máquina, realiza un apagado normal. De forma predeterminada, el subsistema systemd permite un período de gracia para que los servicios se apaguen antes de que se terminen por la fuerza. Sin embargo, si tu sistema sobrescribe los tiempos de apagado configurados, puede interferir con un apagado correcto. Por ejemplo, en AWS, la plataforma puede forzar la terminación de una máquina virtual después de dos minutos. Como tal, los servicios deben apagarse manualmente, ya que un drenaje de nodo puede tardar hasta 5 minutos (este es un requisito para un apagado correcto). | Si el proceso de apagado no es forzado, el nodo debería reiniciarse sin problemas. |
| Terminar a la fuerza un nodo de servidor. | No aplicable. | En la mayoría de los casos, el nodo se iniciará, pero puede haber problemas con algunos servicios que utilizan datos persistentes. Aunque estos problemas suelen ser recuperables, se recomienda encarecidamente configurar copias de seguridad. El pod de Insights no se reiniciará hasta que el nodo original vuelva a estar en línea, para evitar una posible pérdida de datos. Si el nodo no es recuperable, ponte en contacto con el equipo de soporte. |
Comportamiento de la puesta en marcha
Se rke2-serviceinicia y va seguido de node-drainery node-uncordon. node-drainer no realiza ninguna acción al inicio, solo devuelve la confirmación de que el servicio está activo.
El node-uncordonsolo se ejecuta una vez e inicia /opt/node-drain.sh nodestart, que descordona el nodo. Como parte del procedimiento de drenaje que ocurre al apagado, esto cordona el nodo y lo hace no programable. Este estado persiste cuando se inicia el servicio rke2. Por ello, el nodo no debe estar acordonado después de los rke2-servicereinicios .
Inicio manual
El servicio se inicia automáticamente con Automation Suite. Sin embargo, si rke2-service se detuvo manualmente, debes iniciar el servicio de nuevo ejecutando los siguientes comandos:
- Inicia el proceso de Kubernetes que se ejecuta en el nodo del servidor:
systemctl start rke2-serversystemctl start rke2-server - Inicia el proceso de Kubernetes que se ejecuta en el nodo del servidor:
systemctl start rke2-agentsystemctl start rke2-agent - Una vez iniciado el servicio
rke2, desacordona el nodo para asegurarte de que Kubernetes ahora pueda programar cargas de trabajo en este nodo.systemctl restart node-uncordonsystemctl restart node-uncordon - Una vez iniciado el nodo, debes drenar el nodo:
systemctl start node-drain.servicesystemctl start node-drain.serviceImportante:Omitir este paso podría hacer que el servicio Kubelet se apague de forma no saludable si se reinicia el sistema.
ComportamientoDeApagado
Durante el apagado, systemddetiene los servicios en el orden en que se iniciaron. Dado que el node-drain servicio tiene la directiva After=rke2-server.service o After=rke2-agent.service, ejecuta la secuencia de apagado antes del apagado de rke2-service. Esto significa que en un sistema configurado correctamente, simplemente apagar el nodo es una operación segura.
Reinicio manual
Si planeas detener el servicio RKE2 y reiniciar la máquina, ejecuta los siguientes pasos:
- Para asegurarse de que el clúster está sano mientras realizas la actividad de mantenimiento del nodo, debes drenar las cargas de trabajo que se ejecutan en ese nodo a otros nodos. Para vaciar el nodo, ejecuta el siguiente comando:
systemctl stop node-drain.servicesystemctl stop node-drain.service - Detener el proceso de Kubernetes que se ejecuta en el nodo del servidor:
systemctl stop rke2-serversystemctl stop rke2-server - Detener el proceso Kubernetes que se ejecuta en el nodo del agente:
systemctl stop rke2-agentsystemctl stop rke2-agent - Termina los servicios rke2 y containerd y todos los procesos secundarios:
rke2-killall.shrke2-killall.sh
Para descargar el script rke2-killall.sh , consulta Enlaces de descarga de paquetes de instalación.
Archivos creados durante la instalación
Los siguientes archivos de unidad se crean durante la instalación:
- (solo servidor):
rke2-server.serviceelrke2-server, que inicia el nodo del servidor. - (solo agente):
rke2-agent.serviceelrke2-agent, que inicia el nodo agente. node-drain.service: se utiliza en el momento del apagado. Se ejecuta antes de apagarrke2-agentorke2-servery realiza un drenaje. Tiene un tiempo de espera de 300 segundos.node-uncordon.service: se utiliza al inicio para desacordonar un nodo.var-lib-kubelet.mount: generado automáticamente por el generador fstab.var-lib-rancher-rke2-server-db.mount: generado automáticamente por el generador fstab.var-lib-rancher.mount: generado automáticamente por el generador fstab.
No existen dependencias sólidas entre los archivos de la unidad. Sin embargo, node-drain y node-uncordon tienen la directiva After=rke2-server.service o After=rke2-agent.service. Esto significa que esos servicios se iniciarán después del rke2-server.service.