- Se descapó
- 4 de septiembre de 2026 a las 20:39 UTC
- Autor
- Kamo
- Compromit
- 2862548
Este despliegue no tenía sonda de preparación, por lo que una vaina contaba como Listo 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 atado su puerto. Solicitudes aterrizadas en un puerto no se escuchaba nada, que es de donde provenían los intermitentes 502 en el despliegue. /api/salud responde sólo para esta vaina y deliberadamente toca sin backend: una sonda de preparación decide si esta vaina sale del Servicio, y cablearlo a un backend convierte un backend en un blip de backend en un Reinicio de cada cápsula aquí. /healthz es contestado por nginx mismo en lugar de apostar al sidecar: la preparación decide si esta vaina deja el Servicio, y enrutarla a través del sidecar sacaría a toda la interfaz de usuario de la rotación para un contratiempo lateral a pesar de que nginx sigue sirviendo cada página. réplicas 1o 2. Estado del lado del servidor vive en Redis, no en la cápsula, y no hay trabajo programado para 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 mata, una sonda de vida fallida o un drenaje de nodos se llevó todo por siempre y cuando sea necesario para arrancar. topologíaSpreadConstraints (añadidas antes, inerte hasta ahora) mantener los dos en diferentes nodos donde el racimo puede manejarlo, y un PodDisruptionBudget en KlusterServices hace una espera de drenaje. El orgConfigCache del sidecar es una caché TTL de lectura, por lo que una segunda vaina significa un segundo caché, estado no divergente.