Типичная схема с облачным балансировщиком выглядит так:
• Вы создаёте DNS-запись, которая указывает на IP облачного Load Balancer.
• Балансировщик направляет трафик в Kubernetes Service, обслуживающий шлюз.
• Service передаёт запросы Pod’ам прокси — например, NGINX или Envoy.
• Gateway Controller отслеживает ресурсы
HTTPRoute, GRPCRoute и другие поддерживаемые маршруты.• Когда вы применяете эти ресурсы, контроллер обновляет конфигурацию прокси.
• Правила в
HTTPRoute определяют, куда направлять запросы: например, /payment — в payment-service, а /auth — в auth-service.Путь запроса после разрешения DNS:
Cloud Load Balancer → Service шлюза → Gateway Proxy → Backend Service → Pod.
Если вы знакомы с Ingress, разобраться в этой схеме будет проще. При этом разделение контроллера и прокси встречается и в Ingress: контроллер управляет конфигурацией, а прокси обрабатывает трафик.
Особенность Gateway API — явное разделение настройки инфраструктуры и маршрутизации через ресурсы
GatewayClass, Gateway и HTTPRoute, которое позволяет распределять ответственность между платформенной командой и разработчиками.@SysAdmin_Portal