Tiempo de inicio del pod
En esta sección se explican los problemas habituales de Cloud Service Mesh con el tiempo de inicio de los pods y cómo resolverlos. Si necesitas más ayuda, consulta el artículo Obtener asistencia.
Sincronización de la configuración de Envoy y del inicio de pods
Un problema habitual que se observa durante el inicio de pods en algunos entornos de Cloud Service Mesh e Istio es la sincronización entre la disponibilidad de la aplicación y la configuración del proxy de Envoy. El problema se debe al inicio simultáneo del contenedor de la aplicación y del sidecar de Envoy. La aplicación puede indicar que está lista antes de que el proxy de Envoy haya completado su inicialización y recibido su configuración del plano de control. Esto crea una condición de carrera en la que las solicitudes entrantes se dirigen a un proxy Envoy sin configurar que no está listo para recibir tráfico. Esto puede provocar que las solicitudes se omitan, se enruten incorrectamente o se gestionen de forma incorrecta durante la fase inicial del inicio de la aplicación, ya que no hay ningún sidecar para reenviar el tráfico.
Estrategias de mitigación
En las siguientes secciones se describen métodos que pueden mitigar este problema.
Configuración global de la malla: holdApplicationUntilProxyStarts
La primera opción es definir holdApplicationUntilProxyStarts: true en la configuración de la malla de Istio. Ten en cuenta que está desactivada de forma predeterminada. La marca añade hooks para retrasar el inicio de la aplicación hasta que el proxy del pod esté listo para aceptar tráfico.
Si se añade la configuración, se elimina esta condición de carrera, pero puede que se produzca un retraso en los tiempos de preparación de la aplicación para los nuevos pods si no se había habilitado anteriormente.
Comprobaciones de preparación
Otra solución es implementar sondas de disponibilidad que incorporen comprobaciones del estado de la aplicación y de Envoy. Las comprobaciones de preparación informan a Kubernetes de cuándo un pod está listo para aceptar tráfico. Es fundamental que la lógica de la sonda de disponibilidad verifique no solo la disponibilidad de la aplicación, sino también el estado del proxy de Envoy. Para ello, se puede consultar el puerto de administrador de Envoy para conocer su estado de salud. Al combinar ambas comprobaciones, Kubernetes evita que el tráfico se dirija al pod hasta que la aplicación y Envoy se hayan inicializado y configurado por completo.
Esta estrategia es más flexible y permite una lógica de inicio y preparación más complicada, pero conlleva una mayor complejidad.
Crea el archivo healthcheck.sh a partir del siguiente código:
#!/bin/sh
APP_HEALTH=$(curl -s -o /dev/null -w "%{http_code}" \
http://localhost:8080/health)
ENVOY_HEALTH=$(curl -s -o /dev/null -w "%{http_code}" \
http://localhost:9901/ready)
if [[ "$APP_HEALTH" -eq 200 && "$ENVOY_HEALTH" -eq 200 ]]; then
exit 0
else
exit 1
fi
Sustituye las IPs y los puertos por los de tu contenedor de aplicación y Envoy.
El siguiente archivo YAML define una sonda de disponibilidad que usa la secuencia de comandos que has creado anteriormente:
apiVersion: v1
kind: Pod
metadata:
name: my-app-with-envoy
spec:
containers:
- name: application
<…>
readinessProbe:
initialDelaySeconds: 15
periodSeconds: 10
failureThreshold: 3
exec:
command:
- /healthcheck.sh # using the script
- name: envoy
<…>