ingress-nginx: как маленький API оброс собственным языком (Рубрика #PlatformEngineering)

Разбирался с закрытием ingress-nginx. Эту историю можно пересказать как драму open source: компонент примерно для половины cloud-native окружений, по внутренним данным Datadog, годами поддерживали один-два человека в свободное время. Но мне интереснее механизм, сделавший его несопровождаемым.

Ingress API намеренно оставили маленьким: host, path, backend, TLS. В production быстро понадобились таймауты, повторные попытки, canary, внешняя авторизация, заголовки и WAF. ingress-nginx добавлял всё это аннотациями - к июлю 2026 года документация насчитывала около 130 уникальных ключей. Snippet-аннотации позволяли вставлять произвольные фрагменты NGINX-конфига.

Так обходной путь превратился в неформальный DSL. API выглядел простым, но реальный контракт жил в строках metadata, зависел от контроллера, плохо валидировался и расширял поверхность атаки. В 2025 году Wiz раскрыл IngressNightmare - цепочку уязвимостей с неаутентифицированным RCE.

В марте 2026 года поддержка ingress-nginx закончилась: больше нет релизов, исправлений ошибок и security-патчей. Существующие установки продолжают работать - просто без будущих исправлений. Сам Ingress API не закрыт и не deprecated: он заморожен, а развитие ушло в Gateway API.

Gateway API не обязательно меньше или проще. В нём больше явных ресурсов, ролей, связей и политик. Но в этом и смысл: сложность получила типы, владельцев и проверяемые границы вместо сотни строковых исключений.

Если смотреть на эту историю с точки зрения проектирования API, то видно, что важно не просто сделать его минимальным, но и оставить заделы на контролируемое расширение и понятные пути миграций. Если же этого не сделать, то люди начнут строить вокруг второй, скрытый язык вокруг минимального API и наращивать сложность. А закончится все тем, что первую версию придется похоронить под тяжестью сложности и невозможности расширения и поддержки.

#PlatformEngineering #Kubernetes #Architecture #DevOps #Security