Mejores prácticas de Kubernetes. Correcto Terminar Deshabilitar

Mejores prácticas de Kubernetes. Creación de contenedores pequeños
Las mejores prácticas de Kubernetes. Organización de Kubernetes con el espacio de
nombres de mejores prácticas de Kubernetes . Prueba de viabilidad de Kubernetes con pruebas de preparación y vitalidad
Mejores prácticas de Kubernetes . Configuración de solicitudes y límites de recursos



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 han dejado de funcionar. Sin embargo, Kubernetes puede cerrar sus aplicaciones por la fuerza para garantizar la viabilidad 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 la aplicación.

Antes de usar contenedores, la mayoría de las aplicaciones se ejecutaban en máquinas virtuales o físicas. Si la aplicación se bloqueó o se bloqueó, tomó mucho tiempo eliminar la tarea en curso y volver a descargar el programa. En el peor de los casos, alguien tenía que resolver este problema manualmente por la noche, en el momento más inoportuno. Si solo 1-2 máquinas de trabajo realizaran una tarea importante, tal mal funcionamiento sería completamente inaceptable.
Por lo tanto, en lugar de reiniciar manualmente, comenzaron a utilizar la supervisión a nivel de proceso para reiniciar automáticamente la aplicación en caso de finalización de emergencia. 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 ha integrado en la infraestructura.

Kubernetes utiliza el bucle de eventos "observar - confirmar diferencias - confirmar" para garantizar que los recursos estén operativos en el camino desde los contenedores hasta los propios nodos.



Esto significa que ya no necesita iniciar manualmente la supervisión del proceso. Si un recurso falla la comprobación de estado, Kubernetes simplemente proporcionará un reemplazo automáticamente. Kubernetes hace más que simplemente monitorear los bloqueos de su aplicación. Puede crear más copias de la aplicación para trabajar en múltiples máquinas, actualizar la aplicación o ejecutar simultáneamente varias versiones de su aplicación.
Por lo tanto, hay muchas razones por las cuales Kubernetes puede interrumpir un contenedor perfectamente saludable. Por ejemplo, si actualiza su implementación, Kubernetes detendrá lentamente los pods viejos mientras lanza nuevos. Si desconecta un nodo, Kubernetes terminará todos los hogares en ese nodo. Finalmente, si el nodo se queda sin recursos, Kubernetes deshabilitará todos los pods para liberar estos recursos.

Por lo tanto, es muy importante que su aplicación deje de funcionar con un impacto mínimo en el usuario final y un tiempo de recuperación mínimo. Esto significa que antes de desconectarlo debe guardar todos los datos que necesita guardar, cerrar todas las conexiones de red, completar el trabajo restante y tener tiempo para completar otras tareas urgentes.

En la práctica, esto significa que su aplicación debería poder procesar el mensaje SIGTERM: la señal de finalización del proceso, que es la señal predeterminada para la utilidad kill en el sistema operativo de la familia Unix. Después de recibir este mensaje, la aplicación debería desconectarse.

Después de que Kubernetes decidió completar el pod, se llevó a cabo una serie completa de eventos. Veamos cada paso que Kubernetes da cuando se completa un recipiente o hogar.

Supongamos que queremos completar uno de los hogares. En este punto, dejará de recibir tráfico nuevo: los contenedores que funcionan en el hogar no se verán afectados, pero se bloqueará todo el tráfico nuevo.



Veamos el enlace preStop: este es un comando especial o solicitud HTTP enviada a contenedores en el hogar. Si su aplicación no se apaga correctamente cuando se recibe SIGTERM, puede usar preStop para salir correctamente.



La mayoría de los programas cuando reciben una señal SIGTERM finalizan correctamente, pero si usa un código de terceros o algún sistema que no puede controlar por completo, el gancho preStop es una excelente manera de provocar un apagado elegante sin cambiar la aplicación.

Después de ejecutar este gancho, Kubernetes enviará una señal SIGTERM a los contenedores en el hogar, lo que les hará saber que se desconectarán pronto. Después de 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 conectarse a una base de datos o una secuencia de WebSocket, guardar el estado actual y similares.

Incluso si usa el gancho preStop, es muy importante verificar qué sucede exactamente con su aplicación cuando le envía una señal SIGTERM, cómo se comporta de tal manera que los eventos o cambios en la operación del sistema causados ​​por el apagado del hogar no sean una sorpresa para usted.

En este punto, antes de tomar más medidas, Kubernetes esperará un tiempo específico, llamado terminationGracePeriodSecond, o el período para que se apague correctamente cuando reciba una señal SIGTERM.



Por defecto, este período es de 30 segundos. Es importante tener en cuenta que dura en paralelo con el gancho preStop y la señal SIGTERM. Kubernetes no esperará a que finalice el gancho preStop y SIGTERM; si su aplicación se cierra antes de que expire TerminationGracePeriod, Kubernetes procederá 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 el apagado correcto del hogar, y si excede los 30 s, aumente el período al valor deseado en YAML. En el ejemplo anterior, son 60 años.

Y finalmente, el último paso: si los contenedores continúan funcionando después de que expire el terminationGracePeriod, enviarán una señal SIGKILL y serán eliminados por la fuerza. En este punto, Kubernetes también limpiará todos los demás objetos pod.



Kubernetes apaga los hogares por muchas razones, así que asegúrese de que, en cualquier caso, su solicitud se completará correctamente para garantizar un funcionamiento estable del servicio.

Mejores prácticas de Kubernetes. Mapeo de servicios externos

Un poco de publicidad :)

Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes? Apóyenos haciendo un pedido o recomendando a sus amigos, VPS en la nube para desarrolladores desde $ 4.99 , un análogo único de servidores de nivel básico que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2697 v3 (6 núcleos) 10GB DDR4 480GB SSD 1Gbps desde $ 19 o cómo dividir el servidor? (las opciones están disponibles 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 tenemos 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV desde $ 199 en los Países Bajos.Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $ 99! Lea sobre Cómo construir un edificio de infraestructura. clase c con servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?