Envoy Gateway

Envoy Gateway — это открытый Kubernetes API gateway, построенный на Envoy. Он полностью соответствует стандартам Gateway API и обеспечивает стандартизированное, высокопроизводительное и масштабируемое управление входящим север‑южным трафиком и маршрутизацией. Он может заменить Ingress как единый входящий трафик для кластеров Kubernetes, поддерживая ключевые сценарии, такие как выпуск сервисов, управление трафиком и защита безопасности.

Сообщество с открытым исходным кодом: https://github.com/envoyproxy/gateway

Envoy Gateway использует архитектуру control plane–data plane:

• Control plane: анализирует ресурсы Gateway API, генерирует и передаёт конфигурации Envoy, но не перенаправляет сервисный трафик напрямую.
• Data plane: высокопроизводительный прокси Envoy обрабатывает реальный сервисный трафик, включая входящий трафик, завершение TLS, переадресацию маршрутов и балансировку нагрузки.

• Перед использованием Envoy Gateway убедитесь, что CoreDNS работает корректно.
• После установки Envoy Gateway автоматически создаётся GatewayClass с именем envoy-gateway. После удаления дополнения GatewayClass сохраняется. Не удаляйте его вручную. Чтобы удалить GatewayClass после удаления дополнения, вручную удалите его finalizers, если с ним не связан ни один Gateway. В противном случае ресурсы могут исчезнуть или функциональность может стать аномальной после повторной установки дополнения.
• Перед удалением пользовательского GatewayClass убедитесь, что связанный с ним Gateway удалён.
• Удаление дополнения не удаляет созданный Gateway и связанные с ним ресурсы (включая Deployments, Services, ConfigMaps и ServiceAccounts). Перед удалением дополнения вручную удалите ресурсы Gateway, управляемые дополнением. После удаления дополнения удаление Gateway вместе с его связанными ресурсами зависит от deployment mode of the Envoy Gateway data plane. При конфигурации по умолчанию дополнения удаление Gateway также удалит его связанные ресурсы.
• В стандартных кластерах CCE, когда Envoy Gateway привязан к выделенному load balancer, узел, на котором размещён pod контроллера дополнения (с тем же именем Gateway в том же пространстве имён), а также любые другие контейнеры на этом узле, не могут использовать private IP load balancer для доступа к ingress‑ам.
• После настройки дополнения связанная конфигурация load balancer сохраняется в ConfigMap дополнения. Pod‑ы дополнения используют встроенный механизм наблюдения для мониторинга изменений ConfigMap в реальном времени и автоматически синхронизируют последнюю конфигурацию. Поэтому обычно требуется несколько десятков секунд, чтобы обновлённая конфигурация балансировки нагрузки вступила в силу.
• В кластере IPv4/IPv6 dual-stack, если вы измените конфигурацию дополнения с IPv4 with a shared load balancer на IPv4/IPv6 dual stack with a dedicated load balancer во время обновления дополнения, существующие шлюзы не смогут обновиться. Перед выполнением этой операции убедитесь, что ни один шлюз не запущен в данный момент.

Envoy Gateway — дополнение, разработанное сообществом и интегрированное в CCE. Оно не покрывается SLA облачного сервиса. Оцените риски сервиса перед использованием. Для поддержки обратитесь к сообществу или отправьте запрос в службу поддержки.

1. Войдите в CCE console и нажмите название кластера, чтобы открыть консоль кластера.
2. В панели навигации выберите Add-ons. На отображаемой странице найдите Envoy Gateway и нажмите Install.
3. На странице установки дополнения выберите Specifications при необходимости и отрегулируйте количество pod‑ов дополнения и квоты ресурсов.

   Высокая доступность невозможна при использовании одного pod‑а. Если на узле, где работает pod дополнения, произойдёт ошибка, дополнение завершит работу с ошибкой.

4. Настройте параметры дополнения.
   • Add-on Namespace: Выберите пространство имён, в котором будет работать Envoy Gateway.
   • Protocol Version: Выберите версию протокола. Этот параметр доступен только для кластеров IPv4/IPv6 dual-stack.
   • Set ELB: По умолчанию это дополнение не создаёт load balancer автоматически. При создании Gateway любой созданный load balancer использует следующие настройки. Автоматически созданные load balancer оплачиваются по модели pay-per-use.

     В следующей таблице перечислены настройки load balancer.

     Table 1 Настройки load balancer

     Тип load balancer	Конфигурация
     Выделенный	Параметры: Network (TCP/UDP/TLS) и Network (TCP/UDP/TLS) & Application (HTTP/HTTPS) Elastic: применяется к переменному трафику. Оплата производится на основе фактического использования Load Balancer Capacity Unit (LCU). Кластеры v1.21.10-r10, v1.23.8-r10, v1.25.3-r10 и более поздних версий поддерживают elastic specifications. AZ: Вы можете создавать балансировщики нагрузки в нескольких AZ, чтобы повысить доступность сервиса. Если требуется восстановление после аварии, выберите несколько AZ. Instance Name: Введите имя балансировщика нагрузки. Enterprise Project: Этот параметр доступен только корпоративным пользователям с включённым enterprise project. Enterprise projects упрощают управление ресурсами и пользователями облака на уровне проекта. Resource Tag: Вы можете добавлять теги ресурсов для их классификации. Вы можете создавать predefined tags в консоли TMS. Эти теги доступны всем ресурсам, поддерживающим теги. Вы можете использовать эти теги для повышения эффективности создания тегов и миграции ресурсов. Настройки сети Frontend Subnet: Этот параметр используется для выделения IP-адресов балансировщикам нагрузки для внешнего доступа к сервису. Backend Subnet: Этот параметр используется для выделения IP-адресов балансировщикам нагрузки для доступа к бэкенду. EIP: Если выбрать Auto assign, вы можете настроить пропускную способность для публичной сети.
     Общий	Instance Name: Введите имя балансировщика нагрузки. Enterprise Project: Этот параметр доступен только корпоративным пользователям с включённым enterprise project. Enterprise projects упрощают управление ресурсами и пользователями облака на уровне проекта. Resource Tag: Вы можете добавлять теги ресурсов для классификации ресурсов. Вы можете создать predefined tags в консоли TMS. Эти теги доступны для всех ресурсов, поддерживающих теги. Вы можете использовать эти теги для повышения эффективности создания тегов и миграции ресурсов. Network Settings EIP: Если вы выбираете Auto assign, вы можете настроить пропускную способность для публичной сети.

   • AI Inference Gateway: Если эта функция включена, будет развернут Envoy AI Gateway для поддержки интеллектуальной маршрутизации, преобразования протоколов и унифицированного доступа к нескольким бекэндам больших языковых моделей (LLM).
   • Global Rate Limiting: Для этой функции требуется сервис Redis в качестве глобального хранилища счётчиков. Сервис Redis должен быть высокодоступным, а сетевое соединение между дополнением и Redis должно быть стабильным. Вы можете использовать самостоятельно управляемый сервис Redis или облачный управляемый Redis‑база данных.

     Если эта функция включена, ограничение скорости на уровне кластера и совместное кэширование обеспечивают точный контроль трафика и снижают нагрузку на бекенд. Обратите внимание, что это вводит сетевую задержку, а недоступность Redis может привести к ошибкам шлюза или сбоям ограничения скорости.

5. Настройте политики развертывания для add-on pods.
   Note

   При настройке развертывания multi-AZ или привязки к узлам убедитесь, что существуют узлы, соответствующие политике планирования, и что в кластере достаточно ресурсов. В противном случае add-on pods не смогут работать.

   Table 2 Конфигурации планирования дополнения

   Parameter	Description
   Multi-AZ Deployment	Preferred: Pod‑ы развертывания дополнения будут предпочтительно планироваться на узлы в разных AZ. Если все узлы кластера развернуты в одном AZ, pod‑ы будут планироваться на разные узлы в этом AZ. Equivalent mode: Pod‑ы развертывания дополнения равномерно планируются на узлы кластера в каждом AZ. При добавлении нового AZ рекомендуется увеличить количество add-on pods для развертывания HA с перекрёстным AZ. При эквивалентном развертывании multi-AZ разница в количестве add-on pods между различными AZ будет не более 1. Если ресурсы в одном из AZ недостаточны, pod‑ы не могут быть запланированы в этот AZ. Forcible: Pod‑ы развертывания дополнения принудительно планируются на узлы в разных AZ. В каждом AZ может быть не более одного pod‑а. Если узлы кластера не находятся в разных AZ, некоторые add-on pods могут работать некорректно. Если узел неисправен, add-on pods на нём могут не быть перенесены.
   Node Affinity	Not configured: Node affinity отключена для pod‑ов дополнения. Specify node: Укажите узлы, на которых развернуты pod‑ы дополнения. Если узлы не указаны, pod‑ы дополнения будут распределяться случайным образом в соответствии с политикой планирования кластера по умолчанию. Specify node pool: Укажите пул узлов, в котором развернуты pod‑ы дополнения. Если пул узлов не указан, pod‑ы дополнения будут распределяться случайным образом в соответствии с политикой планирования кластера по умолчанию. Customize affinity: Введите метки узлов, на которых должны быть развернуты pod‑ы дополнения, для более гибкой политики планирования. Если метки узлов не указаны, pod‑ы дополнения будут распределяться случайным образом в соответствии с политикой планирования кластера по умолчанию. Если настроено несколько пользовательских политик аффинности, убедитесь, что в кластере есть узлы, соответствующие всем политикам аффинности. В противном случае pod‑ы дополнения не смогут работать.
   Toleration	Использование как taint‑ов, так и toleration‑ов позволяет (но не требует) pod‑ам Deployment дополнения планироваться на узлах с соответствующими taint‑ами и обеспечивает контроль над политиками выселения pod‑ов, когда узлы‑хосты помечены taint‑ами. Дополнение применяет toleration‑ы по умолчанию для taint‑ов node.kubernetes.io/not-ready и node.kubernetes.io/unreachable. Временное окно toleration составляет 60 секунд. Для получения подробной информации см. Configuring Tolerance Policies.

6. Нажмите Install.

Вы можете настроить развертывание плоскости данных Envoy Gateway и выбрать пространство имён для развертывания ресурсов Envoy Proxy (Deployments, Services и ServiceAccounts).

Для этого выполните следующие действия:

1. Войдите в CCE console и нажмите название кластера, чтобы открыть консоль кластера.
2. В панели навигации выберите Add-ons. Найдите Envoy Gateway справа и нажмите Edit.
3. Нажмите Edit YAML над названием дополнения и измените custom.config.envoyGateway.provider.kubernetes.deploy.type.

   

   • GatewayNamespace (default): После создания шлюза (Gateway) дополнение создаёт Service типа LoadBalancer и Deployment Envoy в пространстве имён, где находится шлюз. При удалении дополнения удаление шлюза также удаляет соответствующие Service и Deployment.
   • ControllerNamespace: After a Gateway is created, the add-on creates a LoadBalancer Service and an Envoy Deployment (named in the format envoy-<Gateway-namespace>-<Gateway-name>-<hash>) in the add-on's installation namespace. If the add-on is uninstalled or its pods become unhealthy, deleting the Gateway does not delete the associated Service and Deployment. You must delete them manually.

4. Нажмите Submit.

• После установки add-on вы можете создать ресурсы Gateway API для внешнего доступа к приложению. Для более продвинутых настроек см. Using Envoy Gateway for Service Access.
• Если вы использовали NGINX Ingress, вы можете перенести ресурсы в Envoy Gateway. Подробности см. Migrating NGINX Ingress to Envoy Gateway.