Três mecanismos presentes em todo daemon tornam a atualização contínua segura por construção. A sondagem <code>/readyz</code> muda para <code>503</code> no momento em que o desligamento começa, para que um balanceador de carga ou gateway veja o nó sair da rotação, enquanto <code>/livez</code> permanece <code>200</code> para que o processo não seja finalizado abruptamente <a href="#ref-1">[1]</a>. Uma espera configurável para drenagem mantém o nó nesse estado de drenagem tempo suficiente para que os escalonadores parem de enviar novos trabalhos antes que o processo pare de aceitá-los. O gateway faz sondagens em <code>/readyz</code>, não apenas na vivacidade, e seu failover por requisição cobre o pequeno número de requisições que competem com a janela de drenagem <a href="#ref-1">[1]</a>.
Drenando, não descartando
Quando um worker recebe um sinal de parada, ele entra em drenagem: <code>/readyz</code> retorna <code>503</code>, as requisições em andamento são concluídas e só então o processo é finalizado <a href="#ref-2">[2]</a>. A duração da drenagem é definida com <code>AISUITE_DRAIN_SECONDS</code>, e um orçamento de desligamento separado limita quanto tempo o processo espera para que o trabalho em andamento seja concluído. A entrada no pool nunca muda; o mesmo endereço volta saudável na nova versão, e o gateway retoma o roteamento para ele.
O gateway faz o resto
Em uma fazenda, você para um worker por vez. O painel do gateway mostra esse worker mudando para DRENAGEM, depois PARA, enquanto o tráfego continua nos seus pares; você substitui a imagem e o nó retorna SAUDÁVEL na nova versão antes de passar para o próximo <a href="#ref-1">[1]</a>. Não há nenhuma alteração na configuração do gateway durante todo esse processo. A sondagem de saúde, não uma edição de configuração, é o que move o tráfego.
Kubernetes: zero tempo de inatividade por construção
No Kubernetes, as mesmas sondas tornam o <code>kubectl rollout</code> seguro sem ferramentas extras: uma sonda de vivacidade em <code>/livez</code>, uma sonda de prontidão em <code>/readyz</code> e um <code>terminationGracePeriodSeconds</code> definido no mínimo igual ao orçamento de drenagem mais desligamento <a href="#ref-2">[2]</a>. O orquestrador para de direcionar para um pod em drenagem, espera o período de carência e realiza o rollout do próximo.
Por que isso importa
"Update Tuesday" não deveria existir para um endpoint AI do qual outros aplicativos dependem. Este é também o mecanismo que comprova a posição de disponibilidade de uma fazenda de gateways de ponta a ponta: patching não é tempo de inatividade, e mantém-se sob carga em vez de apenas em um console silencioso <a href="#ref-1">[1]</a><a href="#ref-3">[3]</a>.