Los sistemas distribuidos pueden ser difíciles de administrar porque tienen muchos elementos móviles y cambiantes que necesitan funcionar correctamente para que el sistema funcione. Si alguno de los elementos falla, el sistema debe detectarlo, evitarlo y repararlo, y todo esto debe hacerse de forma automática. En esta serie de mejores prácticas de Kubernetes, aprenderemos cómo configurar pruebas de preparación y actividad para probar el estado de un clúster de Kubernetes.
Health Check es una forma sencilla de informarle al sistema si la instancia de su aplicación se está ejecutando o no. Si la instancia de su aplicación no funciona, otros servicios no deberían acceder a ella ni enviarle solicitudes. En cambio, la solicitud debe enviarse a otra instancia de la aplicación que ya esté ejecutándose o que se iniciará más adelante. Además, el sistema debería restaurar la funcionalidad perdida de su aplicación.
De forma predeterminada, Kubernetes comenzará a enviar tráfico a un pod cuando todos los contenedores dentro de los pods se estén ejecutando y reiniciará los contenedores cuando fallen. Para empezar, este comportamiento predeterminado del sistema puede ser lo suficientemente bueno, pero puede mejorar la confiabilidad de la implementación de su producto mediante el uso de comprobaciones de estado personalizadas.
Afortunadamente, Kubernetes hace que esto sea bastante fácil de hacer, por lo que no hay excusa para ignorar estas comprobaciones. Kubernetes proporciona dos tipos de comprobaciones de estado y es importante comprender las diferencias en cómo se utiliza cada una.
La prueba de preparación está diseñada para indicarle a Kubernetes que su aplicación está lista para manejar el tráfico. Antes de permitir que un servicio envíe tráfico a un pod, Kubernetes debe verificar que la verificación de preparación sea exitosa. Si la prueba de preparación falla, Kubernetes dejará de enviar tráfico al pod hasta que pase la prueba.
La prueba de vida le dice a Kubernetes si su aplicación está viva o muerta. En el primer caso, Kubernetes lo dejará en paz, en el segundo eliminará el pod inactivo y lo reemplazará por uno nuevo.
Imaginemos un escenario en el que su aplicación tarda 1 minuto en calentarse y ejecutarse. Su servicio no comenzará a funcionar hasta que la aplicación esté completamente cargada y en ejecución, aunque el flujo de trabajo ya haya comenzado. También tendrá problemas si desea ampliar esta implementación a varias copias, porque esas copias no deberían recibir tráfico hasta que estén completamente listas. Sin embargo, de forma predeterminada, Kubernetes comenzará a enviar tráfico tan pronto como se inicien los procesos dentro del contenedor.
Al utilizar la prueba de preparación, Kubernetes esperará hasta que la aplicación se esté ejecutando por completo antes de permitir que el servicio envíe tráfico a la nueva copia.
Imaginemos otro escenario en el que la aplicación se cuelga durante mucho tiempo y detiene las solicitudes de servicio. A medida que el proceso continúa ejecutándose, de forma predeterminada, Kubernetes asumirá que todo está bien y continuará enviando solicitudes al pod que no funciona. Pero al usar Liveness, Kubernetes detectará que la aplicación ya no atiende solicitudes y reiniciará el pod inactivo de forma predeterminada.
Veamos cómo se prueban la preparación y la viabilidad. Hay tres métodos de prueba: HTTP, Comando y TCP. Puedes utilizar cualquiera de ellos para comprobarlo. La forma más común de probar a un usuario es una sonda 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 de Liveness. Después de esto, Kubernetes comenzará a hacer ping al pod y, si la respuesta HTTP está en el rango de 200 o 300 ms, indicará que el pod está en buen estado. De lo contrario, el módulo se marcará como "en mal estado".
Para las pruebas de comando, Kubernetes ejecuta el comando dentro de su contenedor. Si el comando regresa con un código de salida cero, entonces el contenedor se marcará como saludable; de lo contrario, al recibir un número de estado de salida del 1 al 255, el contenedor se marcará como "enfermo". Este método de prueba es útil si no puede o no desea ejecutar un servidor HTTP, pero puede ejecutar un comando que verificará el estado de su aplicación.
El mecanismo de verificación final es la prueba TCP. Kubernetes intentará establecer una conexión TCP en el puerto especificado. Si esto se puede hacer, el contenedor se considera sano; si no, se considera inviable. Este método puede resultar útil si utiliza un escenario en el que las pruebas con una solicitud HTTP o la ejecución de un comando no funcionan muy bien. Por ejemplo, los principales servicios de verificación mediante TCP serían gRPC o FTP.
Las pruebas se pueden configurar de varias maneras con diferentes parámetros. Puede especificar con qué frecuencia se deben ejecutar, cuáles son los umbrales de éxito y fracaso y cuánto tiempo esperar las respuestas. Para obtener más información, consulte la documentación de las pruebas de preparación y vida. Sin embargo, hay un punto muy importante al configurar la prueba de vida: la configuración inicial del retraso de la prueba inicialDelaySeconds. Como mencioné, si falla esta prueba, el módulo se reiniciará. Por lo tanto, debe asegurarse de que las pruebas no comiencen hasta que la aplicación esté lista para funcionar; de lo contrario, comenzará a reiniciarse. Recomiendo usar el tiempo de inicio P99 o el tiempo promedio de inicio de la aplicación desde el búfer. Recuerde ajustar este valor a medida que el tiempo de inicio de su aplicación se vuelve más rápido o más lento.
La mayoría de los expertos confirmarán que los controles de estado son obligatorios para cualquier sistema distribuido, y Kubernetes no es una excepción. El uso de comprobaciones del estado del servicio garantiza un funcionamiento fiable y sin problemas de Kubernetes y no supone ningún esfuerzo para los usuarios.
Continuará muy pronto...
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