Stack Overflow уходит с NGINX Ingress: что за этим стоит и стоит ли повторять

Когда команда с трафиком уровня Stack Overflow решает сменить ключевой элемент инфраструктуры, это всегда повод присмотреться: не столько к самому выбору, сколько к логике, которая к нему привела. Ingress-NGINX долгие годы был стандартом де-факто для Kubernetes-кластеров, но новость о его скором прекращении поддержки заставила многих задуматься о запасном варианте. Stack Overflow пошли до конца — и выбрали Envoy Proxy через Envoy Gateway. Их подробный пост — не столько история успеха, сколько честный разбор того, сколько инженерного времени стоит такая миграция и какие компромиссы неизбежны.

Не NGINX плох, а платформа поменялась

Важный момент: Ingress-NGINX не умирает из-за того, что он плох. Он умирает, потому что из проекта, который когда-то был частью Kubernetes, его фактически выдавили: сначала перевели в сторонний репозиторий, а потом объявили о прекращении развития. Для команды, которая строит долгоживущую платформу, это красный флаг — оставаться на проекте без будущего рискованно. На нашем опыте, если у компонента нет стабильного road map и активного мейнтейнера, рано или поздно его приходится менять, и чем раньше это осознать, тем дешевле обходится миграция.

Stack Overflow не стали ждать конца поддержки — они начали миграцию заранее. И это, пожалуй, главный урок: уход с Ingress-NGINX — не техническая, а организационная задача. Выбор Envoy вместо, скажем, Traefik или HAProxy они объясняют не столько производительностью (хотя Envoy действительно быстрее на больших объёмах правил), сколько экосистемой: Envoy Gateway даёт CRD-ориентированный API, который проще интегрировать с GitOps и политиками безопасности.

Цена миграции: не только время, но и культура

Самое ценное в их статье — честные цифры. Миграция заняла не недели, а месяцы. Им пришлось переписывать аннотации, адаптировать мониторинг, переучивать команду. Envoy Gateway — всё ещё молодой проект, и документация по нему не такая богатая, как по Ingress-NGINX. Stack Overflow прямо пишут, что часть их внутренних инструментов пришлось дорабатывать под новую модель конфигурации.

Мы в WIZICO часто видим обратную картину: команды меняют Ingress на что-то «более современное», недооценивая стоимость миграции. Если у вас 20 правил и один кластер — переезд займёт пару дней. Если у вас сотни сервисов с кастомными аннотациями, rate limiting, oAuth-прокси и A/B-тестированием на уровне Ingress — готовьтесь к тому, что Envoy потребует переписать половину логики с нуля.

Envoy — не серебряная пуля

Envoy действительно мощнее: он умеет L7-балансировку с продвинутой телеметрией, поддержкой WebSocket, gRPC и динамической конфигурацией через xDS. Но эта мощь даётся ценой сложности. Envoy Gateway упрощает жизнь, но не настолько, чтобы его мог поддерживать один человек без глубокого понимания сетевой модели Envoy. Если ваша команда не готова инвестировать в экспертизу по Envoy, возможно, разумнее посмотреть на альтернативы вроде Traefik (проще в настройке) или даже остаться на Ingress-NGINX до тех пор, пока он не перестанет работать, а потом переезжать в спокойном темпе.

Stack Overflow — не рядовая компания. У них инженерная культура, позволяющая выделить команду на полгода для замены Ingress. Если у вас такой возможности нет, лучше сначала оценить, насколько критично для бизнеса иметь «самый современный» Ingress-контроллер, а не просто работающий.

Главный вывод, который мы для себя сделали из этой истории: решение о смене Ingress должно приниматься не из-за хайпа вокруг Envoy, а из-за конкретных проблем, которые текущий контроллер перестаёт решать. И если таких проблем нет — возможно, лучшая стратегия не миграция, а мониторинг и план B на случай, если поддержка Ingress-NGINX окончательно прекратится.