Configure las sondas y las comprobaciones del estado del equilibrador de carga

Kubernetes ofrece varias formas de realizar comprobaciones del estado de las aplicaciones, además de las comprobaciones del estado del balanceador de cargas. Puedes ejecutar las siguientes sondas integradas de Kubernetes junto con la comprobación del estado del balanceador de cargas como un comando en el contexto del pod o como una sonda HTTP/TCP a kubelet o a la dirección IP del host.

Las sondas de activación y preparación deben ser diferentes e independientes (o, al menos, tener valores de tiempo de espera diferentes). Si una aplicación tiene un problema temporal, la sonda de disponibilidad marcará el módulo como no preparado hasta que se resuelva el problema. Si la configuración de la sonda de operatividad no es correcta, la sonda de operatividad podría cerrar el módulo.

Sonda de inicio

Utilice sondas de inicio para proteger las aplicaciones que tienen ciclos de inicialización largos. Hasta que la sonda de inicio se realice correctamente, las demás sondas se desactivarán.

Puedes definir un tiempo máximo que Kubernetes debe esperar para que se inicie la aplicación. Si, transcurrido el tiempo máximo configurado, el pod sigue fallando, las sondas de inicio, la aplicación se cierra y se crea un nuevo pod.

Utilice sondeos de inicio cuando la hora de inicio de una aplicación sea impredecible. Si sabe que la aplicación necesita 10 segundos para iniciarse, utilice en su lugar una sonda de actividad o una sonda de disponibilidad. initialDelaySeconds

Sonda de vitalidad

Utilice las sondas de dinámica para detectar problemas en las aplicaciones o si el proceso se está ejecutando sin problemas. Una sonda de actividad puede detectar situaciones de bloqueo en las que el proceso continúa ejecutándose pero la aplicación deja de responder. Cuando utilice una sonda de actividad, haga lo siguiente:

• Se utiliza initialDelaySeconds para retrasar la primera sonda.

• No establezca la misma especificación para las sondas de vitalidad y preparación.

• No configure una sonda de actividad para que dependa de un factor externo al pod (por ejemplo, una base de datos).

• Configura la sonda de vitalidad para una sonda específica. terminationGracePeriodSeconds Para obtener más información, consulte Documentación Kubernetes en la documentación de Kubernetes.

Sonda de preparación

Utilice una sonda de preparación para detectar lo siguiente:

• Si la aplicación está lista para aceptar tráfico

• Disponibilidad parcial, en la que la aplicación puede no estar disponible temporalmente, pero se espera que vuelva a estar en buen estado una vez finalizada una determinada operación

Los sondeos de disponibilidad ayudan a garantizar que la configuración y las dependencias de la aplicación se ejecuten sin problemas ni errores, de modo que la aplicación pueda atender el tráfico. Sin embargo, una sonda de disponibilidad mal configurada puede provocar una interrupción en lugar de evitarla. Las sondas de disponibilidad que dependen de factores externos, como la conectividad a una base de datos, pueden provocar que todos los módulos no pasen la sonda. Estos errores pueden provocar una interrupción y provocar una falla en cascada desde un servicio de back-end a otros servicios que utilizaron los pods defectuosos.

Comprobaciones de estado del balanceador de carga y recursos de Ingress

Application Load Balancer y ingress Kubernetes ofrecen funciones de comprobación de estado. Para las comprobaciones de estado de Application Load Balancer, especifique los puertos y la ruta de destino.

Nota: En el caso de Kubernetesingress, habrá una latencia de anulación del registro. El valor predeterminado de Application Load Balancer es de 300 segundos. Considere configurar el estado del recurso de entrada o del equilibrador de carga con los mismos valores que utilizó para la sonda de preparación. 

NGINX también proporciona un chequeo de estado. Para obtener más información, consulte la documentación de NGINX.

Las pasarelas de entrada y salida de Istio no tienen un mecanismo de comprobación de estado comparable al de la comprobación de estado HTTP de NGINX. Sin embargo, puede lograr una funcionalidad similar utilizando el disyuntor Istio o la detección de valores atípicos. DestinationRule

Para obtener más información, consulte las mejores prácticas de EKS: equilibrio de carga (disponibilidad y ciclo de vida del pod).