- Se descapó
- 4 de septiembre de 2026 a las 19:50 UTC
- Autor
- Kamo
- Compromit
- ddc2b0f
Los despliegues sustituyeron a la única cápsula de cada servicio sin nada para captar las solicitudes en vuelo. Tres ajustes, aplicados en toda la flota: - preStop duerme 10s antes de que el proceso vea SIGTERM. Kubernetes elimina la cápsula de su EndpointSlice y lo señala al mismo momento, y Traefik sólo se entera de la eliminación por reloj, por lo que por un momento sigue enviando nuevas solicitudes en una cápsula que ya ha comenzado de ellos. Esa brecha es de donde vinieron los 502 en un despliegue por lo demás limpio. - terminaciónGracePeriodSeconds levantado por encima del sueño pre-parada, por lo que el gancho no es en sí mismo SIGKILLed, y en vuelo el trabajo tiene espacio para terminar. Es un techo, no una espera: una vaina ociosa todavía sale en aproximadamente un segundo. - minListoSegundos 15, por lo que una vaina que pasa de la preparación una vez y luego cae sobre no puede retirarse el vaina saludable que reemplazó después de que CI ya haya llamado al despliegue bueno. topologíaSpreadConstraints se añaden listos para una segunda réplica; son inertes en uno. Auditoría del grupo en vivo: 63 de los 65 despliegues en el caso de la página web, 1 de 65 un gancho preStop, y ninguno tenía minReadySeconds. El punto de entrada ya drena correctamente en SIGTERM y el período de gracia ya es de 660, pero Nada mantuvo la cápsula en rotación por el momento entre la eliminación EndpointSlice y Traefik notarlo, por lo que las solicitudes enviadas en esa ventana fueron rechazadas por un servidor que acababa de tener Terminación de GracePeriodSeconds se deja en su considerado 660.