- Se descapó
- 4 de septiembre de 2026 a las 20:39 UTC
- Autor
- Kamo
- Compromit
- 4fdff18
Este despliegue no tenía sonda de preparación, por lo que una vaina contaba como Ready el instante de su contenedor proceso iniciado. Con maxUnavailable 0 Kubernetes lee que como "la nueva vaina está sirviendo" y retira el antiguo, mientras que Next sigue rubricando y no ha obligado a su puerto. Solicitudes aterrizadas En un puerto nada estaba escuchando, que es de donde provenían los intermitentes 502 en despliegue. /api/salud responde sólo para esta vaina y deliberadamente toca sin backend: una sonda de preparación decide si esta cápsula deja el Servicio, y cablearlo a un backend gira un backend blip en un Reinicio de cada cápsula aquí. El drenaje y el período de gracia de los 660 ya estaban aquí; la sonda faltante es lo que los detuvo Contando. Kubernetes estaba retirando la vaina drenante antes de que el reemplazo pudiera servir. réplicas 1 - 2. Estado del lado del servidor vive en Redis, no en la cápsula, y no hay trabajo programado duplicar, por lo que una segunda réplica no cambia nada excepto que perder una vaina deja de ser un apagón. En una réplica una OOM matar, una sonda de vida fallida o un drenaje de ganglios se llevó todo por el tiempo que sea necesario para arrancar. topologíaSpreadConstraints (añadidas antes, inerte hasta ahora) mantienen los dos en diferentes nodos donde el racimo puede manejarlo, y un PodDisruptionBudget en KlusterServices hace una espera de drenaje.