Iniciar y apagar un nodo

Inicie y apague los nodos de forma segura en Automation Suite, que abarca 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.

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. Si el clúster estuvo apagado durante más de 6 horas y la autenticación Kerberos está configurada, es posible que debas renovar los tickets Kerberos después del reinicio. Para obtener más información, consulta Recuperar la autenticación Kerberos después de reiniciar la máquina virtual.
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.

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. Detén el proceso de Kubernetes en el nodo, dependiendo del tipo de nodo:

   • En un nodo servidor:

     systemctl stop rke2-server
     

   • En un nodo agente:

     systemctl stop rke2-agent
     

3. Termina los servicios rke2 y containerd y todos los procesos secundarios:

   rke2-killall.sh
   

Para descargar el script rke2-killall.sh , consulta Enlaces de descarga de paquetes de instalación.

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 en el nodo, dependiendo del tipo de nodo:

   • En un nodo servidor:

     systemctl start rke2-server
     

   • En un nodo agente:

     systemctl start rke2-agent
     

2. 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
   

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

   systemctl start node-drain.service
   

   Importante:

   Omitir este paso podría hacer que el servicio Kubelet se apague de forma no saludable si se reinicia el sistema.

Aplicar parches a los nodos del clúster

Al parchear o reiniciar los nodos del servidor, el orden en el que aplicas los cambios afecta directamente a la estabilidad del clúster.

Comprobaciones previas al parche

Antes de tocar cualquier nodo, confirma que el clúster está en buen estado:

1. Confirma que los tres miembros etcd están en buen estado:

   ETCD_CONTAINER="$(/var/lib/rancher/rke2/bin/crictl ps --name etcd --state Running -q | head -n1)"
   /var/lib/rancher/rke2/bin/crictl exec "$ETCD_CONTAINER" etcdctl \
     --endpoints=https://127.0.0.1:2379 \
     --cacert=/var/lib/rancher/rke2/server/tls/etcd/server-ca.crt \
     --cert=/var/lib/rancher/rke2/server/tls/etcd/server-client.crt \
     --key=/var/lib/rancher/rke2/server/tls/etcd/server-client.key \
     endpoint health --cluster
   

2. Comprueba si hay bucles de bloqueo en cualquier nodo:

   journalctl -u rke2-server --since "2 hours ago" | grep -i "FAILURE\|left-over\|unclean"
   

3. Verifica que exista una instantánea reciente de etcd:

   ls -lth /var/lib/rancher/rke2/server/db/snapshots/ | head -5
   

Importante:

No comiences a aplicar parches si algún nodo ya está bloqueando el bucle o si las comprobaciones de estado de etcd fallan. Resuelva la inestabilidad antes de continuar.

Identificar el nodo de arranque

El nodo de arranque suele ser el líder etcd actual. Para identificarlo, ejecuta el siguiente comando y busca IS LEADER: true:

ETCD_CONTAINER="$(/var/lib/rancher/rke2/bin/crictl ps --name etcd --state Running -q | head -n1)"
/var/lib/rancher/rke2/bin/crictl exec "$ETCD_CONTAINER" etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/var/lib/rancher/rke2/server/tls/etcd/server-ca.crt \
  --cert=/var/lib/rancher/rke2/server/tls/etcd/server-client.crt \
  --key=/var/lib/rancher/rke2/server/tls/etcd/server-client.key \
  endpoint status --cluster

Orden de parches

Parche siempre el nodo de arranque primero, luego los nodos secundarios, uno a la vez.

Importante:

Parchar primero el nodo de arranque garantiza que cuando se cae, los dos nodos secundarios mantienen el quórum y eligen un nuevo líder. El nodo de arranque se vuelve a unir como seguidor en un estado limpio. Parchar los nodos secundarios primero y dejar el nodo de arranque para el final puede causar una inestabilidad más amplia si el nodo de arranque no se reincorpora limpiamente.

Después de que cada nodo se parche y se reinicie, confirma que está completamente de vuelta antes de continuar con el siguiente nodo:

1. Verifique que el estado del nodo sea Ready:

   kubectl get nodes
   

2. Confirma que los tres miembros etcd están en buen estado:

   ETCD_CONTAINER="$(/var/lib/rancher/rke2/bin/crictl ps --name etcd --state Running -q | head -n1)"
   /var/lib/rancher/rke2/bin/crictl exec "$ETCD_CONTAINER" etcdctl \
     --endpoints=https://127.0.0.1:2379 \
     --cacert=/var/lib/rancher/rke2/server/tls/etcd/server-ca.crt \
     --cert=/var/lib/rancher/rke2/server/tls/etcd/server-client.crt \
     --key=/var/lib/rancher/rke2/server/tls/etcd/server-client.key \
     endpoint health --cluster
   

3. Comprueba si hay errores en los registros del servidor RKE2:

   journalctl -u rke2-server -n 30
   

Actualizaciones del kernel

Al realizar una actualización del kernel, borra el almacén de instantáneas containerd después de ejecutar rke2-killall.sh y antes de aplicar la actualización del kernel. Esto evita la corrupción del estado del contenedor en cualquier nodo, independientemente del orden de los parches.

Archivos creados durante la instalación

Los siguientes archivos de unidad se crean durante la instalación:

• (solo servidor): rke2-server.service el rke2-server, que inicia el nodo del servidor.
• (solo agente): rke2-agent.service el rke2-agent, que inicia el nodo agente.
• node-drain.service : se utiliza en el momento del apagado. Se ejecuta antes de apagar rke2-agent o rke2-server y 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.