Gestionar sistemas distribuidos puede ser complicado debido a la presencia de numerosos elementos móviles que deben funcionar correctamente para garantizar la funcionalidad del sistema. Si uno de los elementos falla, el sistema debe detectarlo, eludirlo y corregirlo, todo de manera automática. En esta serie de "Mejores Prácticas de Kubernetes", aprenderemos a configurar las pruebas de Readiness y Liveness para verificar la viabilidad del clúster de Kubernetes.
La verificación de salud Health Check es una forma sencilla de ayudar al sistema a saber si la instancia de su aplicación está funcionando o no. Si la instancia de su aplicación no está operativa, otros servicios no deben intentar acceder a ella o enviarle solicitudes. En su lugar, la solicitud debe dirigirse a otra instancia de la aplicación que ya esté en ejecución o que se inicie más tarde. Además, el sistema debe restaurar la funcionalidad perdida de su aplicación.
Por defecto, Kubernetes comenzará a enviar tráfico al pod cuando todos los contenedores dentro de los pods estén en funcionamiento y reiniciará los contenedores si terminan de manera inesperada. Este comportamiento predeterminado del sistema puede ser suficiente al principio, sin embargo, puede aumentar la confiabilidad de la implementación de su producto utilizando verificaciones de salud personalizadas.
Afortunadamente, Kubernetes permite realizar esto de manera bastante sencilla, por lo que no hay justificación para ignorar tales verificaciones. Kubernetes proporciona dos tipos de pruebas de Health Check, y es importante entender las diferencias en la aplicación de cada una de ellas.
La prueba de Readiness está destinada a informar a Kubernetes si su aplicación está lista para atender el tráfico. Antes de permitir que el servicio envíe tráfico al pod, Kubernetes debe asegurarse de que la verificación de Readiness haya sido exitosa. Si la prueba de Readiness falla, Kubernetes dejará de enviar tráfico al pod hasta que la prueba se complete con éxito.
La prueba de Liveness informa a Kubernetes si su aplicación está viva o muerta. En el primer caso, Kubernetes la dejará en paz; en el segundo, eliminará el pod muerto y lo reemplazará por uno nuevo.
Imaginemos un escenario en el que su aplicación tarda 1 minuto en calentarse y lanzarse. Su servicio no comenzará a funcionar hasta que la aplicación se haya cargado y ejecutado completamente, aunque el proceso de trabajo ya haya comenzado. Además, también tendrá problemas si desea escalar esta implementación a varias copias, ya que estas copias no deben recibir tráfico hasta que estén completamente listas. Sin embargo, de forma predeterminada, Kubernetes comenzará a enviar tráfico tan pronto como inicien los procesos dentro del contenedor.
Al utilizar la prueba de disponibilidad Readiness, Kubernetes esperará a que la aplicación esté completamente ejecutada y solo después permitirá al servicio enviar tráfico a la nueva copia.
Imaginemos otro escenario en el que la aplicación se detiene durante un largo período, dejando de atender solicitudes. Dado que el proceso sigue en funcionamiento, de forma predeterminada, Kubernetes asumirá que todo está bien y continuará enviando solicitudes al pod que no está funcionando. Pero al usar Liveness, Kubernetes detectará que la aplicación ya no está atendiendo solicitudes y, por defecto, reiniciará el pod que no está funcionando.
Veamos cómo se prueba la disponibilidad y la viabilidad. Hay tres formas de realizar la prueba: HTTP, Comando y TCP. Puede utilizar cualquiera de ellos para comprobar. La forma más común de prueba del usuario es a través de la sondeo HTTP.
Incluso si su aplicación no es un servidor HTTP, aún puede crear un servidor HTTP liviano dentro de su aplicación para interactuar con la prueba Liveness. Después de esto, Kubernetes comenzará a hacer ping al pod, y si la respuesta HTTP se encuentra en el rango de 200 o 300 ms, eso significará que el pod está "saludable". De lo contrario, el módulo será marcado como "no saludable".
Para las pruebas mediante Comando, Kubernetes ejecuta un comando dentro de su contenedor. Si el comando devuelve un código de salida cero, el contenedor se marcará como saludable; de lo contrario, al recibir un código de salida entre 1 y 255, el contenedor será marcado como "enfermo". Este método de prueba es útil si no puede o no quiere ejecutar un servidor HTTP, pero puede ejecutar un comando que verifique la "salud" de su aplicación.
El último mecanismo de verificación es la prueba TCP. Kubernetes intentará establecer una conexión TCP en el puerto especificado. Si tiene éxito, el contenedor se considera saludable; de lo contrario, se considera no operativo. Este método puede ser útil si utiliza un script en el que la prueba mediante solicitudes HTTP o la ejecución de comandos no funciona muy bien. Por ejemplo, los principales servicios para la verificación mediante TCP son gRPC o FTP.
Las pruebas se pueden configurar de varias maneras con diferentes parámetros. Puede especificar con qué frecuencia deben ejecutarse, cuáles son los umbrales de éxito y fracaso, y cuánto tiempo esperar respuestas. Se proporciona información más detallada en la documentación sobre pruebas de Readiness y Liveness. Sin embargo, hay un punto muy importante en la configuración de la prueba Liveness: la configuración inicial de la demora de la prueba initialDelaySeconds. Como mencioné, una ejecución fallida de esta prueba resultará en el reinicio del módulo. Por lo tanto, debe asegurarse de que la prueba no comience hasta que la aplicación esté lista para funcionar; de lo contrario, comenzará a reiniciarse cíclicamente. Recomiendo utilizar el tiempo de inicio P99 o el tiempo promedio de arranque de la aplicación desde el búfer. No olvide ajustar este valor a medida que el tiempo de inicio de su aplicación se vuelva más rápido o más lento.
La mayoría de los especialistas confirmará que la verificación de salud es una comprobación obligatoria para cualquier sistema distribuido, y Kubernetes no es la excepción. El uso de la verificación de "salud" de los servicios asegura un funcionamiento fiable y sin fallos de Kubernetes y no supone ningún esfuerzo para los usuarios.
La continuación será muy pronto...
Un poco de publicidad 🙂
Gracias por permanecer con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más contenido interesante? Apóyanos haciendo un pedido o recomendando a tus conocidos, , un análogo único de servidores entry-level que hemos diseñado para Ti: (disponibles opciones con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
¿Dell R730xd a mitad de precio en el centro de datos Equinix Tier IV en Ámsterdam? Solo aquí ¡en los Países Bajos! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — ¡desde $99! Lee sobre cómo
Fuente: habr.com
