Миграция с ingress-nginx на ingress-haproxy: попытка добиться zero downtime

В одном из наших кластеров возникла необходимость сменить классический ingress-nginx на ingress-haproxy, так как первый прекращает поддержку. Хотелось выполнить миграцию максимально прозрачно и добиться zero downtime, поэтому мы попробовали реализовать контролируемый параллельный перенос.

Основная задумка заключалась в том, чтобы развернуть ingress-haproxy параллельно существующему ingress-nginx и на время переключения направить новый контроллер на поды старого 🔄. Это позволяло убедиться, что новый балансер работает корректно, прежде чем переводить на него боевой трафик.

Сценарий выглядел так:

1. Разворачиваем ingress-haproxy рядом с ingress-nginx;

2. Меняем селекторы нового ingress-контроллера так, чтобы он смотрел на поды nginx-контроллера;

3. Переключаем DNS (или внешнее доменное имя) на новый балансер;

4. Экспортируем все текущие Ingress-ресурсы в единый манифест;

5. В этот же манифест добавляем service haproxy, но уже со своими родными селекторами;

6. Применяем манифест — Kubernetes разом обновляет все Ingress-ресурсы, переводя их на pod'ы haproxy, и сразу перестраивает сервис, указывая его на новый контроллер;

🗑 После применения изменений старый ingress-nginx можно спокойно удалять.

🧩 Что получилось

Хотя задача заключалась в достижении полного отсутствия простоя, результаты тестирования показали, что небольшой downtime всё же присутствует — примерно 5–10 секунд ⏳. Предположительно, этот разрыв возникает в момент пересборки конфигурации ingress-контроллера и переключения сервисов.

🧠 Выводы

Подход в целом рабочий и позволяет мигрировать между ingress-контроллерами без больших простоев, но полностью избавиться от downtime не получилось. Тем не менее, для большинства сценариев такой короткий перерыв может оказаться приемлемым.