Архитектура бэкенда
Graceful shutdown: тест на свободное воспроизведение
Воспроизведение бьёт перечитывание. На каждый промпт скажи или напиши полный ответ по памяти до того, как откроешь модельный — усилие припоминания и есть то, что закрепляет последовательность shutdown к моменту, когда она нужна на деплое в 2 часа ночи.
Восстанови хребет юнита — последовательность termination, гонку deregistration, teardown в reverse-dependency, бюджет дедлайна, безопасность requeue и координацию флота — не подглядывая в уроки.
- 01Пройди последовательность termination пода Kubernetes и объясни, почему SIGTERM и SIGKILL категориально различны.
- 02Что такое ловушка PID 1 и каковы два исправления?
- 03Опиши гонку deregistration и двухрычажное исправление; почему проваливать readiness, но держать liveness зелёной?
- 04Почему один server.close() зависает и что такое reverse dependency order?
- 05Почему grace period — это бюджет и какая disposition для длинных запросов против фоновых задач?
- 06Почему requeue требует идемпотентности и почему флот безупречных per-instance shutdown не гарантирует zero-downtime деплой?
Если ты смог восстановить каждый ответ по памяти, ты держишь хребет юнита: последовательность termination кончается неперехватываемым SIGKILL, поэтому завершай во время SIGTERM — и убедись, что он реально доходит до обработчика в PID 1; гонка deregistration означает провали readiness и выжди propagation до того, как перестанешь принимать; teardown идёт в reverse dependency order с datastores последними, ограниченный guardian timeout; grace period — это бюджет, поэтому отклоняй длинные запросы и ставь задачи в requeue — но requeue это at-least-once и требует идемпотентности; а zero-downtime деплой — это fleet-уровневая оркестрация (surge перед drain, deregister перед terminate, jitter closes), упорядочивающая индивидуально-корректные shutdown так, чтобы они не сталкивались.