Trois mécanismes intégrés dans chaque daemon rendent une mise à niveau progressive sûre par construction. La sonde <code>/readyz</code> passe à <code>503</code> dès le début de l'arrêt, de sorte qu'un load balancer ou une gateway voit le nœud sortir de la rotation, tandis que <code>/livez</code> reste à <code>200</code> pour que le processus ne soit pas tué brutalement <a href="#ref-1">[1]</a>. Une temporisation de drainage configurable maintient le nœud dans cet état de drainage assez longtemps pour que les planificateurs cessent d'envoyer de nouvelles tâches avant que le processus n'arrête de les accepter. La gateway sonde <code>/readyz</code>, pas seulement la vivacité, et son basculement par requête couvre la poignée de requêtes qui arrivent pendant la fenêtre de drainage <a href="#ref-1">[1]</a>.
Drainage, pas abandon
Lorsqu'un worker reçoit un signal d'arrêt, il entre en drainage : <code>/readyz</code> renvoie <code>503</code>, les requêtes en cours se terminent, puis seulement le processus se termine <a href="#ref-2">[2]</a>. La durée du drainage est définie par <code>AISUITE_DRAIN_SECONDS</code>, et un budget d'arrêt distinct limite le temps d'attente du processus pour que les tâches en cours se terminent. L'entrée du pool ne change jamais ; la même adresse redevient saine sur la nouvelle version, et la gateway reprend le routage vers elle.
La gateway fait le reste
Dans une ferme, vous arrêtez un worker à la fois. Le tableau de bord de la gateway affiche ce worker en état DRAINING, puis DOWN, tandis que le trafic continue sur ses pairs ; vous remplacez l'image et le nœud redevient HEALTHY sur la nouvelle version avant de passer au suivant <a href="#ref-1">[1]</a>. Il n'y a aucun changement de configuration de la gateway durant tout ce processus. Ce sont les sondes de santé, et non une modification de configuration, qui déplacent le trafic.
Kubernetes : zéro interruption de service par conception
Sur Kubernetes, les mêmes sondes rendent <code>kubectl rollout</code> sûr sans outils supplémentaires : une sonde de vivacité sur <code>/livez</code>, une sonde de disponibilité sur <code>/readyz</code>, et un <code>terminationGracePeriodSeconds</code> fixé au minimum à la somme du délai d’évacuation et du budget d’arrêt <a href="#ref-2">[2]</a>. L’orchestrateur cesse de router vers un pod en cours d’évacuation, attend la période de grâce, puis déploie le suivant.
Pourquoi c’est important
Le « Mardi de mise à jour » ne devrait pas exister pour un point de terminaison AI dont dépendent d’autres applications. C’est aussi le mécanisme qui prouve la position de disponibilité d’une ferme de passerelles de bout en bout : le patching n’est pas une interruption de service, et cela tient sous charge plutôt que seulement sur une console inactive <a href="#ref-1">[1]</a><a href="#ref-3">[3]</a>.