🥇Las pruebas de vida en Kubernetes pueden ser peligrosas

Nota. traducir: El ingeniero jefe de Zalando, Henning Jacobs, ha notado repetidamente problemas entre los usuarios de Kubernetes a la hora de comprender el propósito de las sondas de actividad (y preparación) y su uso correcto. Por lo tanto, recogió sus pensamientos en esta amplia nota, que eventualmente pasará a formar parte de la documentación del K8.

Controles de salud, conocidos en Kubernetes como sondas de vida (es decir, literalmente, “pruebas de viabilidad” - traducción aproximada), puede ser bastante peligroso. Recomiendo evitarlos si es posible: las únicas excepciones son cuando son realmente necesarios y eres plenamente consciente de las particularidades y consecuencias de su uso. Esta publicación hablará sobre las comprobaciones de vida y preparación, y también le indicará en qué casos es y no deberías usarlos.

Mi colega Sandor compartió recientemente en Twitter los errores más comunes que encuentra, incluidos aquellos relacionados con el uso de sondas de preparación/actividad:

Configurado incorrectamente livenessProbe puede agravar situaciones de alta carga (apagado en forma de bola de nieve + tiempo de inicio potencialmente prolongado del contenedor/aplicación) y generar otras consecuencias negativas, como caídas de dependencia. (ver también mi artículo reciente sobre limitar el número de solicitudes en la combinación K3s+ACME). Es incluso peor cuando la prueba de vida se combina con una verificación de estado, que es una base de datos externa: una sola falla de base de datos reiniciará todos sus contenedores!

mensaje general "No utilices sondas de vida" en este caso no ayuda mucho, así que veamos para qué sirven las comprobaciones de preparación y actividad.

Nota: La mayor parte de la prueba siguiente se incluyó originalmente en la documentación interna para desarrolladores de Zalando.

Comprobaciones de preparación y vida

Kubernetes proporciona dos mecanismos importantes llamados sondas de vida y sondas de preparación. Periódicamente realizan alguna acción (como enviar una solicitud HTTP, abrir una conexión TCP o ejecutar un comando en el contenedor) para confirmar que la aplicación funciona como se esperaba.

Usos de Kubernetes sondas de preparaciónpara comprender cuándo el contenedor está listo para aceptar tráfico. Una cápsula se considera lista para su uso si todos sus contenedores están listos. Un uso de este mecanismo es controlar qué pods se utilizan como backends para los servicios de Kubernetes (y especialmente Ingress).

Sondas de vida Ayude a Kubernetes a comprender cuándo es el momento de reiniciar el contenedor. Por ejemplo, dicha verificación le permite interceptar un punto muerto cuando una aplicación se atasca en un lugar. Reiniciar el contenedor en este estado ayuda a que la aplicación despegue a pesar de los errores, pero también puede provocar fallas en cascada (ver más abajo).

Si intenta implementar una actualización de la aplicación que no pasa las comprobaciones de actividad/preparación, su implementación se detendrá mientras Kubernetes espera el estado. Ready de todas las vainas.

ejemplo

A continuación se muestra un ejemplo de una sonda de preparación que comprueba una ruta. /health a través de HTTP con configuración predeterminada (intervalo: 10 segundos, tiempo de espera: 1 segundo, umbral de éxito: 1, umbral de falla: 3):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

Recomendaciones

Para microservicios con punto final HTTP (REST, etc.) siempre defina una sonda de preparación, que comprueba si la aplicación (pod) está lista para aceptar tráfico.
Asegúrese de que la sonda de preparación cubre la disponibilidad del puerto real del servidor web:
- utilizar puertos con fines administrativos, llamados "admin" o "management" (por ejemplo, 9090), para readinessProbe, asegúrese de que el punto final solo devuelva OK si el puerto HTTP principal (como 8080) está listo para aceptar tráfico*;
  *Conozco al menos un caso en Zalando en el que esto no ocurrió, es decir, readinessProbe Verifiqué el puerto de "administración", pero el servidor no comenzó a funcionar debido a problemas al cargar el caché.
- conectar una sonda de preparación a un puerto separado puede provocar que la sobrecarga en el puerto principal no se refleje en la verificación de estado (es decir, el grupo de subprocesos en el servidor está lleno, pero la verificación de estado aún muestra que todo está bien). ).
Asegúrate de eso La sonda de preparación permite la inicialización/migración de la base de datos.;
- La forma más sencilla de lograr esto es contactar al servidor HTTP solo después de que se complete la inicialización (por ejemplo, migrar una base de datos desde Flyway etcétera.); es decir, en lugar de cambiar el estado de la verificación de estado, simplemente no inicie el servidor web hasta que se complete la migración de la base de datos*.
  * También puede ejecutar migraciones de bases de datos desde contenedores de inicio fuera del pod. Sigo siendo un fanático de las aplicaciones autónomas, es decir, aquellas en las que el contenedor de la aplicación sabe cómo llevar la base de datos al estado deseado sin coordinación externa.
uso httpGet para verificaciones de preparación a través de puntos finales de verificación de estado típicos (por ejemplo, /health).
Comprender los parámetros de verificación predeterminados (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- las opciones predeterminadas significan que el pod se convertirá no está listo después de unos 30 segundos (3 controles de cordura fallidos).
Utilice un puerto separado para "admin" o "administración" si la pila de tecnología (por ejemplo, Java/Spring) lo permite, para separar la administración de salud y métricas del tráfico normal:
- pero no te olvides del punto 2.
Si es necesario, la sonda de preparación se puede utilizar para calentar/cargar el caché y devolver un código de estado 503 hasta que el contenedor se caliente:
- También te recomiendo que leas el nuevo cheque. startupProbe, apareció en la versión 1.16 (escribimos sobre esto en ruso aquí - aprox. trad.).

Advertencias

No confíes en dependencias externas (como almacenes de datos) al ejecutar pruebas de preparación/actividad; esto puede provocar fallas en cascada:
- Como ejemplo, tomemos un servicio REST con estado con 10 pods dependiendo de una base de datos Postgres: cuando la verificación depende de una conexión funcional a la base de datos, los 10 pods pueden fallar si hay un retraso en el lado de la red/DB; todo termina peor de lo que podría;
- Tenga en cuenta que Spring Data comprueba la conexión de la base de datos de forma predeterminada*;
  * Este es el comportamiento predeterminado de Spring Data Redis (al menos así fue la última vez que lo verifiqué), lo que provocó una falla "catastrófica": cuando Redis no estuvo disponible por un corto tiempo, todos los pods "fallaron".
- "externo" en este sentido también puede significar otros pods de la misma aplicación, es decir, idealmente la verificación no debería depender del estado de otros pods del mismo clúster para evitar fallas en cascada:
  - Los resultados pueden variar para aplicaciones con estado distribuido (por ejemplo, almacenamiento en caché en memoria en pods).
No utilices una sonda de vida para pods (las excepciones son los casos en los que son realmente necesarios y usted es plenamente consciente de las particularidades y consecuencias de su uso):
- Una prueba de actividad puede ayudar a recuperar contenedores bloqueados, pero dado que usted tiene control total sobre su aplicación, lo ideal es que no ocurran cosas como procesos bloqueados y bloqueos: la mejor alternativa es bloquear deliberadamente la aplicación y devolverla al estado estable anterior;
- una prueba de actividad fallida hará que el contenedor se reinicie, lo que podría exacerbar las consecuencias de los errores relacionados con la carga: reiniciar el contenedor provocará un tiempo de inactividad (al menos durante el inicio de la aplicación, digamos 30 segundos y pico), lo que provocará nuevos errores. , aumentando la carga sobre otros contenedores y aumentando la probabilidad de que fallen, etc.;
- Las comprobaciones de actividad combinadas con una dependencia externa son la peor combinación posible, que amenaza con fallas en cascada: ¡un ligero retraso en el lado de la base de datos provocará un reinicio de todos sus contenedores!
Parámetros de comprobaciones de vida y preparación. debe ser diferente:
- puede utilizar una sonda de vida con la misma verificación de estado, pero con un umbral de respuesta más alto (failureThreshold), por ejemplo, asignar el estado no está listo después de 3 intentos y considerar que la sonda de vida ha fallado después de 10 intentos;
No utilices controles ejecutivos, ya que están asociados a problemas conocidos que conducen a la aparición de procesos zombies:
- detalles: ver presentación de especialistas de Datadog.

Resumen

Utilice sondas de preparación para determinar cuándo un pod está listo para recibir tráfico.
Utilice sondas de vida sólo cuando sean realmente necesarias.
El uso inadecuado de las sondas de preparación/actividad puede provocar una disponibilidad reducida y fallas en cascada.

Materiales adicionales sobre el tema

Documentos de Kubernetes: Configurar sondas de actividad y preparación;
Revisión de las sondas de vida y preparación de Kubernetes: cómo evitar dispararse en el otro pie;
Post-mortem de interrupción de los laboratorios de NRE (también habla de livenessProbe).

Actualización No. 1 del 2019-09-29

Acerca de los contenedores de inicio para la migración de bases de datos: Nota a pie de página añadida.

EJ me recordó Acerca de PDB: uno de los problemas con los controles de vida es la falta de coordinación entre los grupos. Kubernetes tiene Presupuestos de disrupción de cápsulas (PDB) para limitar el número de fallos simultáneos que puede experimentar una aplicación; sin embargo, las comprobaciones no tienen en cuenta el PDB. Idealmente, podríamos decirle a los K8 que "reinicien un pod si su prueba falla, pero no los reinicien todos para evitar empeorar las cosas".

Bryan lo expresó perfectamente.: “Utilice el sondeo de vida cuando sepa exactamente qué lo mejor que puedes hacer es cerrar la aplicación"(nuevamente, no te dejes llevar).

Actualización No. 2 del 2019-09-29

Respecto a la lectura de la documentación antes de su uso.: Creé la solicitud correspondiente (solicitud de función) para agregar documentación sobre sondas de vida.

PD del traductor

Lea también en nuestro blog:

Fuente: habr.com

Las pruebas de vida en Kubernetes pueden ser peligrosas