Problema con la sonda de preparación del pod relacionado con la base de datos y el contenedor.
Tengo una aplicación implementada en Kubernetes. Aquí está el stack tecnológico:
Java 11, Spring Boot 2.3.x o 2.5.x, usando hikari 3.x o 4.x
Usando spring actuator para hacer una verificación de salud. Aquí está la configuración de liveness y readiness dentro del archivo application.yaml:
endpoint:
health:
group:
liveness:
include: ''
exclude:
– db
– readinessState
readiness:
include: ''
Lo que hace si la base de datos está fuera de línea –
- Asegurarse de que
livenessno se vea afectado, es decir, el contenedor de la aplicación debe seguir funcionando aunque haya un fallo en la base de datos. readinessse verá afectado, asegurándose de que no se permita tráfico al contenedor.
Configuración de liveness y readiness en la especificación del contenedor:
livenessProbe:
httpGet:
path: actuator/health/liveness
port: 8443
scheme: HTTPS
initialDelaySeconds: 30
periodSeconds: 30
timeoutSeconds: 5
readinessProbe:
httpGet:
path: actuator/health/readiness
port: 8443
scheme: HTTPS
initialDelaySeconds: 30
periodSeconds: 30
timeoutSeconds: 20
Mi aplicación se inició y se ejecutó bien durante unas pocas horas.
Lo que hice:
Apagué la base de datos.
Problema notado:
Cuando la base de datos está caída después de 90+ segundos, veo que se crean 3 pods adicionales. Cuando se describe un pod, veo que el estado y la condición son como sigue:
Status: Running
Conditions:
Type Status
Initialized True
Ready False
ContainersReady False
PodScheduled True
Cuando enumero todos los pods en ejecución:
NAME READY STATUS RESTARTS AGE
application-a-dev-deployment-success-5d86b4bcf4-7lsqx 0/1 Running 0 6h48m
application-a-dev-deployment-success-5d86b4bcf4-cmwd7 0/1 Running 0 49m
application-a-dev-deployment-success-5d86b4bcf4-flf7r 0/1 Running 0 48m
application-a-dev-deployment-success-5d86b4bcf4-m5nk7 0/1 Running 0 6h48m
application-a-dev-deployment-success-5d86b4bcf4-tx4rl 0/1 Running 0 49m
Mi analogía / hallazgo:
Según la configuración de ReadinessProbe, se establece el periodSeconds en 30 segundos y el failurethreshold se establece en 3 según la documentación de K8s.
Según application.yaml, la comprobación de readiness incluye la comprobación de la base de datos, lo que significa que después de cada 30 segundos falla la comprobación de readiness. Cuando falla 3 veces, se cumple el failurethreshold y se generan nuevos pods.
La política de reinicio es la predeterminada – siempre.
Preguntas:
1) ¿Por qué giró nuevos pods?
2) ¿Por qué específicamente se generaron sólo 3 pods y no 1 o 2 o 4, o cualquier número?
3) ¿Tiene esto algo que ver con la restartpolicy?
davy.ai
Los nuevos pods se crearon porque los pods existentes no pasaban la prueba de
readinessProbedebido a que la base de datos estaba caída, la cual está incluida en la prueba dereadiness. Esto evitó que se enviara tráfico a los pods existentes porque no se consideraron listos para servir solicitudes. El controlador de Kubernetes decidió entonces crear nuevos pods para reemplazar a los existentes que no superaban la prueba dereadinessProbe.El controlador de Kubernetes pudo haber decidido crear tres nuevos pods en función del valor de
replicasestablecido en la configuración de implementación. Sireplicasestá establecido en tres, entonces el controlador intentará mantener siempre tres pods. Cuando los pods existentes no pasaban la prueba dereadinessProbe, el controlador pudo haber determinado que necesitaba crear exactamente tres nuevos pods para reemplazarlos.La política de reinicio (
restartPolicy) para la implementación está establecida enAlways, lo que significa que si un pod se bloquea o termina por cualquier motivo, será reiniciado automáticamente por el controlador de Kubernetes. Sin embargo, esto no está directamente relacionado con el problema de los pods que se crearon debido a las pruebas dereadinessProbeque fallaron.