すべてのデーモンに搭載されている3つの仕組みにより、ローリングアップグレードは設計上安全に行えます。シャットダウンが始まるとすぐに<code>/readyz</code>プローブが<code>503</code>に切り替わるため、ロードバランサーやゲートウェイはノードがローテーションから外れたことを認識します。一方、<code>/livez</code>は<code>200</code>のまま維持されるため、プロセスは強制終了されません。 <a href="#ref-1">[1]</a>. 設定可能なドレインホールドにより、ノードはドレイン状態を十分な時間維持し、スケジューラーが新しい作業の送信を停止してからプロセスが受け入れを停止します。ゲートウェイは<code>/readyz</code>をプローブし、単なる生存確認だけでなく、リクエストごとのフェイルオーバーにより、ドレインウィンドウと競合するわずかなリクエストもカバーします。 <a href="#ref-1">[1]</a>。
ドレイン中、切断なし
ワーカーが停止信号を受け取ると、ドレイニング状態に入ります：<code>/readyz</code>は<code>503</code>を返し、進行中のリクエストが完了してからプロセスが終了します <a href="#ref-2">[2]</a>ドレイン時間は<code>AISUITE_DRAIN_SECONDS</code>で設定され、別のシャットダウン予算により、進行中の作業が完了するまでの待機時間が制限されます。プールエントリは変更されず、同じアドレスが新しいバージョンで正常に戻り、ゲートウェイはルーティングを再開します。
ゲートウェイが残りの処理を行います
ファーム環境では、ワーカーを一度に一台ずつ停止します。ゲートウェイのダッシュボードには、そのワーカーがDRAINING（排水中）からDOWN（停止）に変わる様子が表示され、その間も他のピアはトラフィックを継続します。イメージを差し替え、新しいビルドでノードがHEALTHY（正常）に戻ったことを確認してから、次のワーカーに移ります。 <a href="#ref-1">[1]</a>. この間、ゲートウェイの設定変更は一切ありません。トラフィックの切り替えは設定編集ではなく、ヘルスプロービングによって行われます。
Kubernetes: ゼロダウンタイムを設計で実現
Kubernetesでは、同じプローブにより<code>kubectl rollout</code>が追加ツールなしで安全になります：<code>/livez</code>のリブネスプローブ、<code>/readyz</code>のレディネスプローブ、そしてドレインとシャットダウンの予算を含む<code>terminationGracePeriodSeconds</code>の設定 <a href="#ref-2">[2]</a>オーケストレーターはドレイン中のポッドへのルーティングを停止し、猶予期間を待ってから次のポッドをロールアウトします。
なぜ重要か
他のアプリが依存するAIエンドポイントに対して「アップデート火曜日」はあってはなりません。これはゲートウェイファームの可用性をエンドツーエンドで証明するメカニズムでもあります：パッチ適用はダウンタイムではなく、静かなコンソール上だけでなく負荷下でも維持されます <a href="#ref-1">[1]</a><a href="#ref-3">[3]</a>。