Tre meccanismi presenti in ogni daemon rendono sicuro per costruzione un aggiornamento rolling. La probe <code>/readyz</code> passa a <code>503</code> nel momento in cui inizia lo shutdown, così un bilanciatore di carico o un gateway vedono il nodo uscire dalla rotazione, mentre <code>/livez</code> resta <code>200</code> così il processo non viene terminato brutalmente <a href="#ref-1">[1]</a>. Una pausa di draining configurabile mantiene il nodo in quello stato abbastanza a lungo affinché gli scheduler smettano di inviare nuovo lavoro prima che il processo smetta di accettarlo. Il gateway interroga <code>/readyz</code>, non solo la liveness, e il suo failover per singola richiesta copre la manciata di richieste che competono con la finestra di draining <a href="#ref-1">[1]</a>.
Draining, non scarto
Quando un worker riceve un segnale di stop, entra in draining: <code>/readyz</code> restituisce <code>503</code>, le richieste in corso terminano, e solo allora il processo esce <a href="#ref-2">[2]</a>. La durata del draining è impostata con <code>AISUITE_DRAIN_SECONDS</code>, e un budget di shutdown separato limita quanto a lungo il processo attende il completamento del lavoro in corso. L’entry nel pool non cambia mai; lo stesso indirizzo torna sano sulla nuova versione, e il gateway riprende a instradare verso di esso.
Il gateway fa il resto
In una farm, si ferma un worker alla volta. La dashboard del gateway mostra quel worker passare a DRAINING, poi DOWN, mentre il traffico continua sui peer; si sostituisce l’immagine e il nodo torna HEALTHY sulla nuova build prima di passare al successivo <a href="#ref-1">[1]</a>. Non c’è alcuna modifica alla configurazione del gateway durante tutto questo. È il probing di salute, non una modifica di configurazione, a spostare il traffico.
Kubernetes: zero downtime per costruzione
Su Kubernetes le stesse probe rendono <code>kubectl rollout</code> sicuro senza strumenti aggiuntivi: una probe di liveness su <code>/livez</code>, una probe di readiness su <code>/readyz</code>, e un <code>terminationGracePeriodSeconds</code> impostato uguale o superiore al budget di drain e shutdown <a href="#ref-2">[2]</a>. L'orchestratore smette di instradare verso un pod in draining, attende il periodo di grazia e avvia il rollout del successivo.
Perché è importante
"Update Tuesday" non dovrebbe esistere per un endpoint AI da cui dipendono altre app. Questo è anche il meccanismo che dimostra la posizione di disponibilità di una farm di gateway end to end: la patch non è downtime, e regge sotto carico anziché solo su una console silenziosa <a href="#ref-1">[1]</a><a href="#ref-3">[3]</a>.