Drei Mechanismen, die in jedem Daemon enthalten sind, machen ein Rolling Upgrade von Grund auf sicher. Die <code>/readyz</code>-Probe wechselt auf <code>503</code>, sobald der Shutdown beginnt, sodass ein Load Balancer oder Gateway den Knoten aus der Rotation nimmt, während <code>/livez</code> <code>200</code> bleibt, damit der Prozess nicht sofort beendet wird <a href="#ref-1">[1]</a>. Ein konfigurierbarer Drain-Hold hält den Knoten lange genug im Drain-Zustand, damit Scheduler keine neue Arbeit mehr senden, bevor der Prozess diese nicht mehr annimmt. Das Gateway prüft <code>/readyz</code>, nicht nur die Liveness, und sein per-Anfrage-Failover deckt die wenigen Anfragen ab, die dem Drain-Fenster voraus sind <a href="#ref-1">[1]</a>.
Draining, nicht Droppen
Wenn ein Worker ein Stop-Signal erhält, wechselt er in den Drain-Zustand: <code>/readyz</code> liefert <code>503</code>, laufende Anfragen werden abgeschlossen, und erst danach beendet sich der Prozess <a href="#ref-2">[2]</a>. Die Drain-Dauer wird mit <code>AISUITE_DRAIN_SECONDS</code> eingestellt, und ein separates Shutdown-Budget begrenzt, wie lange der Prozess auf den Abschluss laufender Arbeit wartet. Der Pool-Eintrag ändert sich nie; dieselbe Adresse wird in der neuen Version wieder als gesund gemeldet, und das Gateway leitet den Verkehr wieder dorthin weiter.
Das Gateway erledigt den Rest
In einem Farm-Setup wird jeweils ein Worker gestoppt. Das Dashboard des Gateways zeigt, dass dieser Worker auf DRAINING wechselt, dann auf DOWN, während der Verkehr auf den anderen Peers weiterläuft; Sie ersetzen das Image, und der Knoten meldet sich in der neuen Version als HEALTHY zurück, bevor Sie zum nächsten Worker übergehen <a href="#ref-1">[1]</a>. Währenddessen ändert sich keine Gateway-Konfiguration. Das Health-Probing, nicht eine Konfigurationsänderung, steuert den Verkehrsfluss.
Kubernetes: von Grund auf ohne Ausfallzeiten
Unter Kubernetes machen dieselben Probes <code>kubectl rollout</code> ohne zusätzliche Werkzeuge sicher: eine Liveness-Probe auf <code>/livez</code>, eine Readiness-Probe auf <code>/readyz</code> und ein <code>terminationGracePeriodSeconds</code>, das auf oder über dem Drain- plus Shutdown-Budget liegt <a href="#ref-2">[2]</a>. Der Orchestrator stoppt die Weiterleitung zu einem auslaufenden Pod, wartet die Schonfrist ab und rollt den nächsten aus.
Warum das wichtig ist
„Update Tuesday“ sollte für einen AI-Endpunkt, von dem andere Apps abhängen, nicht existieren. Dies ist auch der Mechanismus, der die Verfügbarkeitsposition einer Gateway-Farm von Anfang bis Ende beweist: Patchen ist keine Ausfallzeit und hält unter Last, nicht nur auf einer ruhigen Konsole <a href="#ref-1">[1]</a><a href="#ref-3">[3]</a>.