Проект Gateway API для Kubernetes выпустил версию 1.6.0: ресурсы TCPRoute и UDPRoute перешли в стандартный канал, то есть получили статус стабильного API. Для команд, которые гоняют через Kubernetes не только HTTP, но и трафик баз данных, брокеров сообщений, VoIP или телеметрию, это убирает часть самодельных CRD и снижает зависимость от конкретного контроллера.
Иными словами, L4-маршрутизация в экосистеме Gateway API стала ближе к тому уровню зрелости, которого от нее давно ждали в продакшене.
TCP и UDP вошли в стандартный канал
Исходный текст неточно описывал релиз: Gateway API и раньше не ограничивался только HTTP и TLS. В проекте уже были, например, HTTPRoute, GRPCRoute и TLSRoute, а TCPRoute и UDPRoute существовали в экспериментальном канале с ранних версий. В 1.6 речь идет не о появлении поддержки TCP и UDP с нуля, а о повышении их статуса до стандартного канала.
Для самого проекта это важная граница. В терминологии Gateway API стандартный канал означает стабильный интерфейс, на который можно опираться в рабочих кластерах без оглядки на скорую ломку схем и семантики. Одновременно версии v1alpha2 для TCPRoute и UDPRoute объявлены устаревающими: командам стоит смотреть в сторону v1.
Что меняется для команд Kubernetes
Практический эффект простой: если раньше для TCP- и UDP-сервисов нередко приходилось жить на сервисах типа LoadBalancer, использовать возможности конкретного ingress/gateway-контроллера или тащить собственные CRD, то теперь у рынка появляется более единый слой конфигурации. Это особенно полезно для PostgreSQL, MySQL, Redis, MQTT, игровых серверов и SIP-нагрузки, где HTTP-модель просто не подходит.
Есть и важное ограничение: TCPRoute и UDPRoute не превращают Gateway API в универсальный маршрутизатор для любой логики на уровне приложений. Для TCP и UDP правила по определению проще, чем у HTTPRoute: обычно речь идет о маршрутизации по порту и привязке к конкретному backend-сервису. Но именно в этом и ценность релиза: меньше магии, меньше несовместимостей, проще миграция между реализациями.
Значение для рынка
Для российских и СНГ-команд это хороший сигнал: Kubernetes-инфраструктура становится предсказуемее там, где через кластер идут не только веб-приложения, но и внутренняя платформа, очереди, телеметрия и сетевые сервисы. Для корпораций это снижение привязки к вендору Gateway-контроллера, для интеграторов и МСБ — более понятный способ собирать типовые решения без лишних прослоек.
Следующий практический шаг для команд — проверить, поддерживает ли их Gateway-контроллер стандартный канал Gateway API 1.6 и готов ли он к переходу на v1 для TCPRoute и UDPRoute.
Источник: релиз Gateway API v1.6.0, документация Gateway API.