Tiempo de inicio del pod
En esta sección, se explican los problemas comunes de Cloud Service Mesh con el tiempo de inicio del pod y cómo resolverlos. Si necesitas asistencia adicional, consulta Obtén asistencia.
Inicio del pod y sincronización de la configuración de Envoy
Un problema común que se observa durante el inicio de los pods en algunos entornos de Cloud Service Mesh y Istio implica la sincronización entre el nivel de preparación de la aplicación y la configuración del proxy de Envoy. El problema surge del inicio simultáneo del contenedor de la aplicación y el sidecar de Envoy. La aplicación puede indicar que está lista antes de que el proxy de Envoy haya completado su inicialización y haya 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 de Envoy no configurado que no está listo para recibir tráfico. Esto puede provocar que las solicitudes se descarten, se redirijan o se controlen de forma incorrecta durante la fase inicial del inicio de la aplicación, ya que no hay un sidecar para reenviar el tráfico.
Estrategias de mitigación
En las siguientes secciones, se describen los métodos que pueden mitigar este problema.
Configuración de malla global: holdApplicationUntilProxyStarts
La primera opción es configurar holdApplicationUntilProxyStarts: true en la configuración del entramado de Istio. Ten en cuenta que está desactivada de forma predeterminada. La marca agrega hooks para retrasar el inicio de la aplicación hasta que el proxy del pod esté listo para aceptar tráfico.
Si agregas la configuración, se elimina esta competencia, pero es posible que se produzca una demora en los tiempos de preparación de la aplicación para pods nuevos si no se habilitó anteriormente.
Pruebas de disponibilidad
Otra solución es implementar sondas de preparación que incorporen verificaciones de estado de la aplicación y de Envoy. Los sondeos de preparación informen a Kubernetes cuándo un pod está listo para aceptar tráfico. Es fundamental que la lógica de la prueba de preparación verifique no solo la preparación de la aplicación, sino también el estado del proxy de Envoy. Para ello, consulta el puerto de administrador de Envoy para conocer su estado. Cuando se combinan ambas verificaciones, Kubernetes evita que el tráfico se dirija al pod hasta que la aplicación y Envoy se inicialicen y configuren por completo.
Este enfoque es más flexible y permite una lógica de inicio y preparación más complicada, pero a costa de 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
Reemplaza la IP o los puertos por los del contenedor de tu aplicación y de Envoy.
El siguiente archivo YAML define un sondeo de preparación que usa la secuencia de comandos que creaste 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
<…>