Gateway API
Тема дорожной карты · Kubernetes
Kubernetes Gateway API — API управления трафиком нового поколения, пришедший на смену ресурсу Ingress. Он предоставляет ролеориентированную, расширяемую модель для настройки HTTP-, HTTPS-, TCP- и gRPC-маршрутизации в K8s-кластерах. API вводит четыре основных типа ресурсов: GatewayClass (определяет реализацию контроллера, например Istio, Envoy Gateway или Traefik), Gateway (выделяет балансировщик нагрузки и настраивает слушателей на определённых портах и протоколах), HTTPRoute (подключается к Gateway и определяет правила маршрутизации на основе хоста и пути к Service Kubernetes) и ReferenceGrant (разрешает межпространственные ссылки между маршрутами и бэкендами). Gateway API разделяет инфраструктурные задачи и маршрутизацию приложений: команды платформы управляют объектами GatewayClass и Gateway, а команды разработки самостоятельно управляют ресурсами HTTPRoute, GRPCRoute и TCPRoute в своих пространствах имён. Kubernetes Gateway API поддерживает расширенные возможности управления трафиком: взвешенное разделение трафика для canary-Deployment, маршрутизацию на основе заголовков, перезапись URL и терминацию TLS с интеграцией Cert-Manager через spec.tls.certificateRefs.
Как это работает
Gateway API в Kubernetes работает через CNI (Container Network Interface) на каждой ноде плюс API-ресурсы (Service, Ingress, NetworkPolicy и т.д.), которые декларирует пользователь. CNI выдаёт pod IPs из cluster-wide CIDR, kube-proxy программирует правила iptables/IPVS для Service ClusterIP, ingress-controller (NGINX, Traefik и др.) обрабатывает внешний HTTP-трафик с TLS termination.
Когда применять
Конфигурируйте Gateway API рано в setup кластера — сетевые решения имеют широкие последствия и сложно меняются позже. Выбирайте CNI (Calico, Cilium, Flannel) по нуждам policy и масштаба; выбирайте ingress controller под мешок нагрузок; проектируйте Service и DNS-разметку до деплоя реальных нагрузок. Network observability (kube-state-metrics + Prometheus + Cilium Hubble) экономит часы во время incident response.
Типичные ошибки
Сетевые ловушки: дефолт на NodePort (открывает порты на каждом worker — обычно не то, что вам нужно), когда имели в виду ClusterIP + Ingress; забыли NetworkPolicies (всё общается со всем по умолчанию в K8s — опасно в shared-кластерах); ingress controllers без TLS-стратегии; неправильная конфигурация CoreDNS, вызывающая cluster-wide DNS-failures. Тестируйте network policies на staging до production.