Комментарии 4
Я бы ещё упомянул lameducking. Чтобы обновления (как подов, так и целиком нод) происходили бесшовно, приложения должны реагировать на SIGTERM, маркировать себя нездоровыми (возвращать ошибку в readiness check), а когда обслужат все запросы из очереди и подождут секунд 20 на случай, если новые подвалят, тогда уже завершаться.
У себя частично решил это admission контроллером, который добавляет подам с определенной аннотацией preStop хук с простой задержкой. Получается такая схема при остановке пода:
- кубы исключают endpoint с этим подом
- выполняется preStop задержка. За это время информация из api сервера распределяется по нодам и балансировщикам
- приложению отправляется SIGTERM, и далее его очередь продолжить graceful shutdown, т.е. закончить обработку текущих запросов
Таким образом не надо менять код приложения и добавлять в него лишние знания об окружении. Во время preStop задержки приложение продолжает работать штатно, обрабатывая трафик из мест, до которых ещё не дошла информация об изменениях в кластере. Я замерял эти задержки. В GKE время доходило до нескольких секунд. До использования этой схемы, пользователи неизбежно получали 502-е ошибки при деплоях. Сейчас же всё проходит бесшовно.
Admission контроллер позволяет управлять этой логикой централизованно, но вполне можно обойтись и без него.
Как насчёт самих мастер год и ингресса, их тоже желательно резервировать.
гимор задёшево
Руководство по обеспечению высокой доступности в Kubernetes