Un punto importante en la operación de sistemas distribuidos es el manejo de fallas. Kubernetes ayuda con esto mediante el uso de controladores que monitorean el estado de su sistema y reinician los servicios que dejaron de funcionar. Sin embargo, Kubernetes puede detener sus aplicaciones por la fuerza para garantizar el estado general del sistema. En esta serie, veremos cómo puede ayudar a Kubernetes a hacer su trabajo de manera más eficiente y reducir el tiempo de inactividad de las aplicaciones.
Antes de los contenedores, la mayoría de las aplicaciones se ejecutaban en máquinas virtuales o físicas. Si la aplicación fallaba o se congelaba, tomaba mucho tiempo cancelar la tarea en curso y recargar el programa. En el peor de los casos, alguien tenía que solucionar este problema manualmente por la noche, en las horas más inoportunas. Si sólo 1 o 2 máquinas en funcionamiento realizaban una tarea importante, tal interrupción era completamente inaceptable.
Por lo tanto, en lugar de reinicios manuales, comenzaron a utilizar la supervisión a nivel de proceso para reiniciar automáticamente la aplicación en caso de una terminación anormal. Si el programa falla, el proceso de monitoreo captura el código de salida y reinicia el servidor. Con la llegada de sistemas como Kubernetes, este tipo de respuesta a fallas del sistema simplemente se integró en la infraestructura.
Kubernetes utiliza un bucle de eventos de observar-diferencia-tomar-acción para garantizar que los recursos se mantengan en buen estado mientras viajan desde los contenedores hasta los propios nodos.
Esto significa que ya no necesita ejecutar manualmente la supervisión del proceso. Si un recurso no supera la comprobación de estado, Kubernetes simplemente le proporcionará automáticamente un reemplazo. Sin embargo, Kubernetes hace mucho más que simplemente monitorear su aplicación en busca de fallas. Puede crear más copias de la aplicación para ejecutarla en varias máquinas, actualizar la aplicación o ejecutar varias versiones de su aplicación simultáneamente.
Por lo tanto, hay muchas razones por las que Kubernetes puede terminar un contenedor en perfecto estado. Por ejemplo, si actualiza su implementación, Kubernetes detendrá lentamente los pods antiguos mientras inicia otros nuevos. Si cierra un nodo, Kubernetes dejará de ejecutar todos los pods en ese nodo. Finalmente, si un nodo se queda sin recursos, Kubernetes cerrará todos los pods para liberar esos recursos.
Por lo tanto, es fundamental que su aplicación finalice con un impacto mínimo para el usuario final y un tiempo de recuperación mínimo. Esto significa que antes de apagarse, debe guardar todos los datos que deben guardarse, cerrar todas las conexiones de red, completar el trabajo restante y administrar otras tareas urgentes.
En la práctica, esto significa que su aplicación debe poder manejar el mensaje SIGTERM, la señal de terminación del proceso que es la señal predeterminada para la utilidad Kill en los sistemas operativos Unix. Al recibir este mensaje, la aplicación debería cerrarse.
Una vez que Kubernetes decide finalizar un pod, ocurren una serie de eventos. Veamos cada paso que da Kubernetes al cerrar un contenedor o pod.
Digamos que queremos terminar uno de los pods. En este punto, dejará de recibir tráfico nuevo: los contenedores que se ejecutan en el pod no se verán afectados, pero todo el tráfico nuevo se bloqueará.
Veamos el gancho preStop, que es un comando especial o solicitud HTTP que se envía a contenedores en un pod. Si su aplicación no se cierra correctamente al recibir SIGTERM, puede usar preStop para cerrarse correctamente.
La mayoría de los programas se cerrarán correctamente cuando reciban una señal SIGTERM, pero si está utilizando código de terceros o algún sistema que no controla por completo, el gancho preStop es una excelente manera de forzar un cierre elegante sin cambiar la aplicación.
Después de ejecutar este enlace, Kubernetes enviará una señal SIGTERM a los contenedores en el pod, haciéndoles saber que pronto se desconectarán. Al recibir esta señal, su código procederá al proceso de apagado. Este proceso puede incluir detener cualquier conexión de larga duración, como una conexión de base de datos o una secuencia de WebSocket, guardar el estado actual y similares.
Incluso si usa un gancho preStop, es muy importante verificar qué sucede exactamente con su aplicación cuando le envía una señal SIGTERM y cómo se comporta, de modo que los eventos o cambios en la operación del sistema causados por el cierre de un pod no lleguen tan pronto como sea posible. una sorpresa para ti.
En este punto, Kubernetes esperará una cantidad de tiempo específica, llamada terminaciónGracePeriodSecond, o el período para cerrarse correctamente cuando reciba una señal SIGTERM, antes de tomar más medidas.
Por defecto este periodo es de 30 segundos. Es importante señalar que corre en paralelo con el gancho preStop y la señal SIGTERM. Kubernetes no esperará a que finalicen el enlace preStop y SIGTERM; si su aplicación sale antes de que finalice TerminationGracePeriod, Kubernetes pasará inmediatamente al siguiente paso. Por lo tanto, verifique que el valor de este período en segundos no sea menor que el tiempo requerido para apagar correctamente el pod y, si excede los 30 segundos, aumente el período al valor deseado en YAML. En el ejemplo dado, son 60 años.
Y finalmente, el último paso es que si los contenedores siguen ejecutándose después de la terminaciónGracePeriod, enviarán una señal SIGKILL y serán eliminados a la fuerza. En este punto, Kubernetes también limpiará todos los demás objetos del pod.
Kubernetes finaliza los pods por muchas razones, así que asegúrese de que su aplicación finalice correctamente en cualquier caso para garantizar un servicio estable.
Algunos anuncios 🙂
Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más contenido interesante? Apóyanos haciendo un pedido o recomendándonos a amigos, , un análogo único de servidores de nivel de entrada, que fue inventado por nosotros para usted: (disponible con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
Dell R730xd 2 veces más barato en el centro de datos Equinix Tier IV en Amsterdam? Solo aqui ¡en los Paises Bajos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $99! Leer acerca de
Fuente: habr.com