Релиз без обрыва потоковых соединений

Долгое соединение делает релиз видимым

Обычный HTTP-запрос заканчивается быстро; stream может жить часами. Если pod/процесс просто завершить, пользователи одновременно переподключатся. Поэтому deploy должен управлять жизненным циклом соединений.

Снять готовность → завершить соединения → жёсткий срок

Экземпляр сначала перестаёт принимать новые подключения, но продолжает обслуживать существующие. После drain window сервер отправляет клиенту сигнал на переподключение или закрывает соединение с понятной причиной. Затем процесс завершается по hard deadline.

Бесконечное завершение соединений — тоже ошибка

Ждать, пока последний клиент сам уйдёт, значит никогда не завершить rollout. Нужен max connection age или bounded drain. Клиент обязан уметь reconnect и получить свежий snapshot, поэтому закрытие соединения — штатная часть протокола.

Совместимость во время смешанного кластера

Новая и старая версия stream gateway некоторое время работают вместе. Изменение event schema должно быть backward compatible или versioned. Нельзя рассчитывать, что frontend и backend обновятся в одну миллисекунду.

Лавина повторных соединений после поэтапного релиза

Даже корректный drain создаёт много реконнектов, если клиенты используют фиксированную задержку. Jitter распределяет попытки. Gateway также ограничивает частоту resubscribe и отдает snapshot через масштабируемый read path, а не из памяти старого узла.

Релиз как управляемое завершение соединений

Для SSE и WebSocket корректный deploy начинается до остановки процесса. Экземпляр перестаёт принимать новые подключения, остаётся доступным для уже открытых сессий и получает ограниченное время на drain. После дедлайна соединения закрываются предсказуемо, чтобы rollout не зависел от «вечных» клиентов.

Клиентская сторона также участвует в релизе: reconnect с jitter и совместимый протокол уменьшают всплеск нагрузки, когда несколько экземпляров уходят одновременно. Особенно полезно отслеживать версию протокола в telemetry, чтобы видеть, как долго после deploy остаются старые клиенты.

• Readiness должен отключаться раньше остановки процесса.
• Задать максимальный возраст соединения или hard drain deadline.
• Проверять смешанный кластер старой и новой версии на совместимость payload.

Смешанный кластер нужно проверять намеренно

Во время rolling release часть клиентов всё ещё сидит на старых соединениях, а новые попадают на свежую версию. Это нормальное состояние, поэтому совместимость должна тестироваться как отдельный сценарий: old client → new gateway, new client → old gateway и переключение между ними после reconnect.

Для LiveCenter релиз должен быть почти незаметен: короткая потеря stream допустима, потеря выбранного контекста и массовый пустой экран — нет. Клиент получает jitter, перечитывает snapshot и продолжает с новой точки, не предполагая, что sequence старого соединения можно использовать дальше.

В dashboard полезно разделять active connections по версии процесса и протокола. Тогда rollout действительно завершён не в момент, когда новые pods стали ready, а когда хвост старых соединений ушёл или был корректно drained.

Критерий успешного релиза

Смотрим active connections по version, drain duration, reconnect spread и resync сбойs. CPU нового процесса может быть зелёным, пока половина клиентов ещё сидит на старой версии — это надо видеть явно.