Tres mecanismos que se incluyen en cada daemon hacen que una actualización continua sea segura por construcción. La sonda <code>/readyz</code> cambia a <code>503</code> en el momento en que comienza el apagado, por lo que un balanceador de carga o gateway ve que el nodo sale de la rotación, mientras que <code>/livez</code> permanece en <code>200</code> para que el proceso no sea terminado abruptamente <a href="#ref-1">[1]</a>. Una retención de drenaje configurable mantiene el nodo en ese estado de drenaje el tiempo suficiente para que los planificadores de tareas dejen de enviar nuevo trabajo antes de que el proceso deje de aceptarlo. El gateway sondea <code>/readyz</code>, no solo la vivacidad, y su failover por solicitud cubre el pequeño número de solicitudes que compiten con la ventana de drenaje <a href="#ref-1">[1]</a>.
Drenando, no descartando
Cuando un worker recibe una señal de parada, entra en drenaje: <code>/readyz</code> devuelve <code>503</code>, las solicitudes en curso terminan, y solo entonces el proceso finaliza <a href="#ref-2">[2]</a>. La duración del drenaje se establece con <code>AISUITE_DRAIN_SECONDS</code>, y un presupuesto de apagado separado limita cuánto tiempo espera el proceso para que el trabajo en curso se complete. La entrada del pool nunca cambia; la misma dirección vuelve saludable en la nueva versión, y el gateway reanuda el enrutamiento hacia ella.
El gateway hace el resto
En una granja, se detiene un worker a la vez. El panel del gateway muestra que ese worker cambia a DRENANDO, luego a CAÍDO, mientras el tráfico continúa en sus pares; reemplazas la imagen y el nodo vuelve a estar SALUDABLE en la nueva versión antes de pasar al siguiente <a href="#ref-1">[1]</a>. No hay ningún cambio en la configuración del gateway durante todo este proceso. La sonda de salud, no una edición de configuración, es lo que mueve el tráfico.
Kubernetes: sin tiempo de inactividad por diseño
En Kubernetes, las mismas sondas hacen que <code>kubectl rollout</code> sea seguro sin herramientas adicionales: una sonda de disponibilidad en <code>/livez</code>, una sonda de preparación en <code>/readyz</code>, y un <code>terminationGracePeriodSeconds</code> establecido en o por encima del presupuesto de drenaje más apagado <a href="#ref-2">[2]</a>. El orquestador deja de enrutar a un pod en drenaje, espera el período de gracia y despliega el siguiente.
Por qué es importante
"Martes de actualización" no debería existir para un endpoint de AI del que dependen otras aplicaciones. Este es también el mecanismo que demuestra la posición de disponibilidad de una granja de gateways de extremo a extremo: parchear no es tiempo de inactividad, y se mantiene bajo carga en lugar de solo en una consola tranquila <a href="#ref-1">[1]</a><a href="#ref-3">[3]</a>.