Активные проверки. Балансировщик или оркестратор раз в несколько секунд обращается к служебному эндпоинту. После N неудач подряд экземпляр исключается, после M успехов — возвращается (гистерезис, чтобы не мигал).
Пассивные проверки (outlier detection). Смотрим на реальные ответы: 5xx, таймауты, рост задержки. Экземпляр, у которого ошибок заметно больше, чем у остальных, временно исключается (ejection) с растущим временем изоляции. Ловит то, что /health не видит: сервис отвечает на проверку, но реальные запросы падают. Envoy, Istio, Linkerd делают это из коробки. Ограничение — не выкидывать больше заданной доли экземпляров, иначе при общей проблеме выкинем всех.
Kubernetes различает три пробы:
- startup — пока не прошла, остальные не проверяются: даёт время медленному старту;
- readiness — готов ли принимать трафик сейчас. Не прошла — под убирают из Service, но не перезапускают. Может учитывать прогрев кэшей, доступность критичных зависимостей, перегрузку;
- liveness — жив ли процесс. Не прошла — контейнер перезапускают. Должна быть простой и проверять только сам процесс (не завис ли цикл обработки). Если liveness проверяет базу, то при сбое базы Kubernetes перезапустит все поды разом — и они вдобавок ударят по базе при старте.
Подключение и отключение экземпляров:
- медленный старт — новый экземпляр с холодным кэшем и JIT получает долю трафика постепенно;
- graceful shutdown — сначала readiness = false и пауза, пока балансировщики узнают, потом завершение текущих запросов.
Sticky sessions — привязка клиента к экземпляру (по cookie или хешу IP), чтобы держать сессию в памяти. Минусы: неравномерная нагрузка, потеря сессий при падении или выкатке, трудности автомасштабирования. Лучше вынести сессию в Redis или подписанный токен и сделать сервис stateless. Оправдано для WebSocket и локальных кэшей, где привязка даёт выигрыш, — тогда через consistent hashing.