В начале апреля 2026 года на KubeCon EU прозвучало сразу два важных объявления, касающихся всех, кто работает с облачной инфраструктурой. Первое – официальный уход Nginx Ingress. Второе – вступление проекта Higress в CNCF Sandbox в качестве одного из его преемников. Разберёмся, что происходит и почему это важно даже для тех, кто с Kubernetes знаком лишь понаслышке.
Nginx Ingress уходит – и это не шутка
Nginx Ingress долгое время был чем-то вроде стандартного решения для управления входящим трафиком в Kubernetes-кластерах. По оценкам, около 50% облачных инфраструктур в мире до сих пор используют его в том или ином виде.
Но комитет по безопасности и группа разработчиков сети Kubernetes официально объявили о завершении поддержки Nginx Ingress. Проще говоря: новых версий не будет, баги не исправят, дыры в безопасности – тоже. Для продакшн-среды это серьёзно: одна из особенностей Nginx Ingress – возможность вставлять произвольные фрагменты конфигурации через аннотации. Гибко, да, но в отсутствие патчей это превращается в потенциальную уязвимость.
Сообщество давно знало, что этот момент наступит. Но когда он всё же наступает – нужно понимать, куда двигаться дальше.
Почему Nginx Ingress стал неудобен ещё до своего ухода
Команда Alibaba Cloud, по собственному опыту, столкнулась с Nginx Ingress задолго до того, как проблема стала индустриальной. Вот с чем пришлось бороться:
- Перебои при обновлениях. Каждое изменение конфигурации в Nginx требует перезапуска рабочих процессов. Для обычных коротких HTTP-запросов это почти незаметно, но для долгоживущих соединений – например, WebSocket или gRPC – это означает принудительное обрывание и переустановку соединений. В реальных системах это ощутимо.
- Неравномерная нагрузка при gRPC. Nginx изначально проектировался под короткие запросы. Когда через одно долгоживущее соединение идёт поток мультиплексированных запросов, балансировка нагрузки работает неравномерно – одни серверы перегружены, другие простаивают.
- Замедление при масштабировании. Когда конфигураций становится много – тысячи, десятки тысяч – время перезагрузки конфигурации начинает расти непропорционально. На больших кластерах это становится реальной проблемой.
Именно эти три проблемы подтолкнули команду к созданию собственного решения.
Откуда взялся Higress
Higress – это шлюз (gateway), построенный поверх Envoy и Istio. Если коротко: Envoy – это высокопроизводительный прокси-сервер, а Istio – система управления сетью сервисов. Higress использует их как основу, добавляя собственные расширения.
Проект не новый. Внутри Alibaba Cloud он появился в 2020 году, прошёл испытание на «Двойной распродаже 11 ноября» – одном из крупнейших торговых событий в мире с колоссальным объёмом трафика. В 2021 году на его основе запустили облачный сервис для клиентов, объединив функции traffic-шлюза и микросервисного шлюза в одном решении. По словам разработчиков, это дало 50% экономии по сравнению с предыдущим подходом. С 2022 года проект открыт для всех.
25 марта 2026 года Higress официально вошёл в CNCF Sandbox – это означает, что проект признан сообществом облачных технологий как достойный развития и поддержки.
Что делает Higress лучше при обновлениях конфигурации
Одно из ключевых отличий от Nginx – способ применения изменений. В Envoy обновление маршрутов и адресов серверов происходит прямо в памяти, без перезапуска процессов. Никакого «пересоздания воркеров», никаких обрывов соединений. Конфигурация просто тихо меняется на лету.
Это легко проверить на практике. Компания Sealos – облачный провайдер с аудиторией более 200 000 пользователей – до перехода на Higress сталкивалась с пиковым временем перезагрузки конфигурации до 30 минут. После миграции этот показатель упал до менее чем 5 секунд. Потребление памяти при этом снизилось примерно в 10 раз.
Переход с Nginx Ingress: без переписывания конфигураций
Одна из главных практических задач при смене шлюза – не сломать то, что уже работает. Higress решает её за счёт поддержки аннотаций Nginx Ingress «из коробки»: большинство уже написанных конфигураций продолжат работать без изменений, потому что Higress внутри переводит их в формат Envoy и Istio.
Параллельно он поддерживает и новый стандарт – Gateway API. Проще говоря: можно сначала переехать с Nginx на Higress, ничего не трогая, а потом постепенно переводить конфигурации на новый формат. Если оба варианта заданы одновременно, Gateway API имеет приоритет.
Для тех случаев, когда прямой перевод аннотаций невозможен (например, для rate limiting), Higress использует собственные плагины.
Плагины, которые не ломают шлюз
Higress поддерживает расширения через WASM-плагины. WASM (WebAssembly) – это технология, которая позволяет запускать изолированный код внутри прокси-сервера. Если плагин написан с ошибкой, он просто не сработает – но не уронит весь шлюз. Это важная гарантия стабильности.
Плагины можно писать на Go, Rust, C++ или JavaScript. Они упаковываются в образы, совместимые с Docker-реестрами, и обновляются без перезапуска шлюза. Из коробки доступно более 100 плагинов – для аутентификации, безопасности, кэширования и многого другого.
Для задач, которые WASM не покрывает (например, сложные долгоживущие соединения), есть нативная поддержка фильтров на Go, работающих непосредственно внутри Envoy.
ИИ-трафик – это другой трафик
Вот здесь начинается то, что делает Higress актуальным именно сейчас, в эпоху повсеместного распространения ИИ.
Обычный API-шлюз работает с короткими запросами и ответами. ИИ-трафик устроен иначе:
- Соединения живут долго – от минут до часов, особенно при работе с ИИ-агентами.
- Ответы приходят потоком (Server-Sent Events, стриминг), а не единым блоком.
- Шлюз должен понимать содержимое запроса – например, к какой языковой модели его направить.
Higress умеет работать в двух режимах применительно к ИИ: как LLM-шлюз (для работы с языковыми моделями) и как MCP-шлюз (для управления инструментами ИИ-агентов).
Higress как шлюз для языковых моделей
Когда Higress выступает в роли LLM-шлюза, он берёт на себя несколько практически важных задач.
Автоматический фолбэк между моделями. Если основная языковая модель не отвечает вовремя или перегружена, Higress автоматически переключается на резервную. Пользователь при этом ничего не замечает – он просто получает ответ.
Учёт токенов при ограничении запросов. В компаниях разные команды или отделы часто пользуются одними и теми же языковыми моделями. Higress позволяет задать квоты по количеству токенов для каждой команды. Если один отдел исчерпал лимит – ограничение применяется только к нему, остальные продолжают работать.
Семантическое кэширование. Если несколько разных пользователей задают похожие вопросы, Higress может вернуть кэшированный ответ, не отправляя запрос к модели повторно. Это снижает затраты и ускоряет ответы. Кэш работает не по точному совпадению текста, а по смысловой близости запросов.
Наблюдаемость. Higress собирает метрики, специфичные для ИИ: время до первого токена, скорость генерации, количество токенов в кэше. Всё это настраивается динамически, без перезапуска, и важно как для отладки, так и для контроля расходов.
ИИ-агенты – это системы, которые решают задачи, используя внешние инструменты: поиск, базы данных, API. Взаимодействие с этими инструментами стандартизировано через протокол MCP.
Проблема в том, что большинство существующих API не предназначены для ИИ-агентов: они возвращают сложные JSON-структуры, в которых модели легко запутаться. Higress решает это двумя способами.
Во-первых, он умеет автоматически превращать существующие OpenAPI-спецификации (стандартный способ описания API) в MCP-инструменты, понятные агентам, – без написания кода.
Во-вторых, он может трансформировать ответы: вытащить из сложного JSON только нужные поля и преобразовать их в Markdown – формат, с которым языковые модели работают гораздо лучше. Разработчики называют это трансформацией полезной нагрузки. Это сокращает объём данных, которые модель обрабатывает, и снижает вероятность «галлюцинаций» – ситуаций, когда модель выдаёт неверный ответ из-за перегруженности контекста.
Кто уже использует
Higress применяется не только внутри Alibaba. Среди публично известных пользователей – Ctrip (известный также как Trip.com), который построил на Higress внутренний шлюз для всего ИИ-трафика компании. Ant Group (Alipay) использует ядро Higress в своём SOFA AI Gateway для управления масштабными корпоративными топологиями. Среди других компаний упоминаются Didi, Qunar, PayPal, Kuaishou, DJI.
Что дальше
В планах команды – углубление поддержки Gateway API и его расширения для ИИ-нагрузок, а также поддержка WebRTC для задач, где нужны двусторонние аудио- и видеовзаимодействия в реальном времени – например, для голосовых ИИ-приложений наподобие OpenAI Realtime API.
Репозиторий проекта в ближайшее время будет перенесён под управление CNCF. Проект открыт для внешних разработчиков и принимает вклад от сообщества.
Если говорить коротко о сути происходящего: Nginx Ingress уходит, и это не просто смена инструмента. Это момент, когда инфраструктурный шлюз должен стать умнее – понимать не только HTTP-запросы, но и природу ИИ-трафика. Higress – одна из попыток ответить на этот вызов.
