Mejores prácticas de Kubernetes. Prueba de viabilidad de Kubernetes con pruebas de preparación y vitalidad

Mejores prácticas de Kubernetes. Creación de contenedores pequeños
Las mejores prácticas de Kubernetes. Organización de Kubernetes con un espacio de nombres



Los sistemas distribuidos pueden ser difíciles de administrar debido al hecho de que tienen muchos elementos mutables móviles, y todos ellos deben funcionar correctamente para garantizar la funcionalidad del sistema. Si uno de los elementos falla, el sistema debe detectarlo, omitirlo y corregirlo, y todo esto debe hacerse automáticamente. En esta serie de mejores prácticas de Kubernetes, aprenderemos cómo configurar las pruebas de preparación y vitalidad para probar la viabilidad de un clúster de Kubernetes.

Health Check Health Check es una manera fácil de informar al sistema si la instancia de su aplicación se está ejecutando o no. Si una 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 se está ejecutando o comenzará más tarde. Además, el sistema debería devolver su aplicación a la funcionalidad perdida.

De manera predeterminada, Kubernetes comenzará a enviar tráfico al pod cuando se estén ejecutando todos los contenedores dentro de los hogares, y volverá a cargar los contenedores cuando se bloqueen. Para empezar, este comportamiento predeterminado del sistema puede ser bastante bueno, pero puede aumentar la confiabilidad de la implementación de su producto utilizando comprobaciones de estado personalizadas.



Afortunadamente, Kubernetes le permite hacer esto de manera bastante simple, por lo que no hay excusas para ignorar tales controles. Kubernetes proporciona dos tipos de pruebas de Health Check, y es importante comprender las diferencias en cada aplicación.

La Prueba de preparación de preparación está diseñada para decirle a Kubernetes que su aplicación está lista para atender el tráfico. Antes de permitir que el servicio envíe tráfico al pod, Kubernetes debe verificar que la verificación de disponibilidad sea exitosa. Si la prueba de preparación falla, Kubernetes dejará de enviar tráfico al pod hasta que la prueba sea exitosa.

La prueba de viabilidad de Liveness le dice a Kubernetes si su aplicación está viva o muerta. En el primer caso, Kubernetes lo dejará solo, en el segundo, quitará la cápsula muerta y la reemplazará por una nueva.

Imaginemos un escenario en el que su aplicación necesita 1 minuto para "calentarse" y ejecutarse. Su servicio no comenzará a funcionar hasta que la aplicación se cargue y comience por completo, aunque el flujo de trabajo ya ha comenzado. Y también tendrá problemas si desea aumentar la escala de esta implementación a varias copias, porque estas copias no deberían recibir tráfico hasta que estén completamente listas. Sin embargo, de manera predeterminada, Kubernetes comenzará a enviar tráfico inmediatamente después del inicio de los procesos dentro del contenedor.

Cuando se utiliza la prueba de disponibilidad de preparación, Kubernetes esperará hasta que la aplicación se inicie por completo y solo después de eso permitirá que el servicio envíe tráfico a una nueva copia.



Imaginemos otro escenario en el que una aplicación se congela durante mucho tiempo, deteniendo las solicitudes de servicio. Como el proceso continúa ejecutándose, Kubernetes considerará que todo está en orden y continuará enviando solicitudes al pod que no funciona. Pero al usar Liveness, Kubernetes detectará que la aplicación ya no atiende solicitudes y, por defecto, reiniciará un pod que no funciona.



Considere cómo evaluar la preparación y la vitalidad. Hay tres métodos de prueba: HTTP, ommand y TCP. Puede usar cualquiera de ellos para la verificación. El método de prueba de usuario más común es una sonda HTTP.

Incluso si su aplicación no es un servidor HTTP, aún puede crear un servidor HTTP ligero dentro de su aplicación para interactuar con la prueba Liveness. Después de eso, Kubernetes comenzará a hacer ping al pod, y si la respuesta HTTP está en el rango de 200 o 300 ms, significará que el pod está "sano". De lo contrario, el módulo se marcará como "no saludable".



Para las pruebas que utilizan Comando, Kubernetes ejecuta el comando dentro de su contenedor. Si el comando regresa con un código de salida cero, el contenedor se marcará como correcto; de lo contrario, cuando el número de estado de salida sea de 1 a 255, el contenedor se marcará como "enfermo". Este método de prueba es útil si no puede o no desea iniciar el 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 saludable, de lo contrario, no es viable. Este método puede ser útil si utiliza un script 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 para verificar con TCP serán gRPC o FTP.



Las pruebas se pueden configurar de varias maneras con varios parámetros. Puede especificar con qué frecuencia deben ejecutarse, cuáles son los umbrales para el éxito y el fracaso, y cuánto tiempo esperar las respuestas. Consulte la documentación de la prueba de preparación y vitalidad para obtener más información. Sin embargo, hay un punto muy importante en la configuración de la prueba Liveness: la configuración inicial del retraso de la prueba initialDelaySeconds. Como mencioné, al fallar esta prueba se reiniciará el módulo. Por lo tanto, debe asegurarse de que las pruebas no comiencen hasta que la aplicación esté lista para su uso; de lo contrario, comenzará a pasar. Recomiendo usar el tiempo de inicio P99 o el tiempo promedio de inicio de la aplicación desde el búfer. No olvide ajustar este valor comoa medida que el tiempo de inicio de su aplicación se hace más rápido o más lento.

La mayoría de los expertos confirmarán que Health Check es una verificación obligatoria para cualquier sistema distribuido, y Kubernetes no es una excepción. El uso de la verificación de "estado" de los servicios garantiza Kubernetes confiable y de tiempo de actividad y no hace ningún trabajo para los usuarios.

Continuará muy pronto ...

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?