Iniciar y apagar un nodo

Esta página explica el ComportamientoDeApagado y de inicio manuales y automáticos de Automation Suite.

Importante:

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.	Ejecuta manualmente los pasos de apagado. Reinicia los servicios utilizando el inicio manual o reiniciando la máquina.	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.	En todos los nodos, empezando por los nodos agente, ejecuta manualmente los pasos de apagado. Reinicia los servicios utilizando el inicio manual o reiniciando las máquinas, comenzando por los nodos del servidor.	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:

1. Inicia el proceso de Kubernetes que se ejecuta en el nodo del servidor:

   systemctl start rke2-server
   

2. Inicia el proceso de Kubernetes que se ejecuta en el nodo del servidor:

   systemctl start rke2-agent
   

3. 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-uncordon
   

4. Una vez iniciado el nodo, debes drenar el nodo:

   systemctl start node-drain.service
   

   Importante:

   Omitir el paso 4 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:

1. 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.service
   

2. Detener el proceso de Kubernetes que se ejecuta en el nodo del servidor:

   systemctl stop rke2-server
   

3. Detener el proceso Kubernetes que se ejecuta en el nodo del agente:

   systemctl stop rke2-agent
   

4. Elimina los servicios rke2 y containerd y todos los procesos secundarios:

   rke2-killall.sh
   

   Esto ya debería estar en la ruta, pero se encuentra en /bin/rke2-killall.sh.

Archivos creados durante la instalación

1. Los siguientes archivos de unidad se crean durante la instalación:
   • rke2-server.service (solo servidor). Inicia el rke2-server, esto inicia el servidor del nodo.
   • rke2-agent.service (solo agente). Inicia el rke2-agent, esto inicia el agente del nodo.
   • node-drain.service. Se utiliza en el periodo de apagado. Se ejecuta antes del apagado de rke2-agento rke2-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-service.