#Настройка GatewayAPI Gateway

#Обзор

В этом документе объясняется, как настроить Gateway после того, как оператор Envoy Gateway и EnvoyGatewayCtl готовы. Gateway определяет, как трафик поступает в шлюз, в то время как сопутствующий EnvoyProxy контролирует, как развертывается базовая плоскость данных Envoy.

В рекомендуемом рабочем процессе этот документ следует после Envoy Gateway Operator и перед Configure GatewayAPI Route.

#Предварительные требования

Пожалуйста, убедитесь, что вы выполнили следующие шаги перед продолжением:

1. Ознакомились с Envoy Gateway Operator, чтобы понять основные концепции и взаимосвязи ресурсов
2. Установили оператор Envoy Gateway и создали EnvoyGatewayCtl

#Основы Gateway

#Что такое Gateway

Gateway — это точка входа для трафика, поступающего в ваш кластер. Он определяет, как внешние запросы принимаются и маршрутизируются к вашим бэкенд-сервисам. Gateway в основном определяет:

• Listeners: определяют порты, протоколы и имена хостов, на которых слушает шлюз
• GatewayClass: выбирает, какой контроллер шлюза управляет этим Gateway
• Ссылка на инфраструктуру: ссылается на EnvoyProxy, который контролирует, как развертывается базовая плоскость данных Envoy

#Экспозиция Gateway (тип сервиса)

Тип сервиса настраивает, как шлюз экспонируется через базовый сервис Envoy. Существует три режима: LoadBalancer, NodePort и ClusterIP.

В YAML эта настройка задаётся в сопутствующем ресурсе EnvoyProxy по пути .spec.provider.kubernetes.envoyService.type.

#LoadBalancer (Рекомендуется)

Преимущество — простота использования и возможности балансировки нагрузки с высокой доступностью. Для использования LoadBalancer в кластере должна быть поддержка LoadBalancer, которую можно включить через MetalLB.

При использовании MetalLB можно указать статический VIP через аннотации сервиса. В веб-консоли используйте поле Service Annotation:

metallb.universe.tf/address-pool: ADDRESS_POOL_NAME
# Или укажите конкретный IP напрямую
metallb.universe.tf/loadBalancerIPs: VIP_IP

Подробнее см. How To Specify a VIP When Using MetalLB.

#NodePort

Преимущество — не требует внешних зависимостей.

Однако у NodePort есть следующие недостатки:

• При использовании NodePort Kubernetes назначает номера портов NodePort, отличающиеся от портов самого сервиса. Для доступа нужно использовать порт NodePort, а не порт сервиса.
• Сервис доступен по IP-адресу любого узла в кластере, что может представлять потенциальные риски безопасности.

#Как получить правильный порт при использовании NodePort

На странице сведений Gateway, когда тип сервиса — NodePort, в списке слушателей отображается столбец NodePort с назначенными номерами портов. Также можно использовать следующую команду:

kubectl get svc -n ${ENVOYGATEWAYCTL_NS} -l gateway.envoyproxy.io/owning-gateway-name=${GATEWAY_NAME} -o=jsonpath="{.items[0].spec.ports[?(@.port==${PORT})].nodePort}"

Выводом будет порт NodePort.

#ClusterIP

Очень удобно, если внешняя экспозиция не требуется.

#Конфигурация Listener

Listener определяет порт и протокол, на которых шлюз слушает трафик. В протоколах HTTP или HTTPS разные имена хостов могут рассматриваться как разные слушатели.

Нельзя создать слушателя с конфликтующими портом, протоколом или именем хоста.

В Gateway необходимо создать как минимум одного слушателя.

#Порт и протокол

Каждый слушатель настраивается с номером порта и протоколом. Поддерживаемые протоколы: HTTP, HTTPS, TCP, UDP, TLS.

#AllowRouteNS

По умолчанию маршруты (Routes) могут быть прикреплены только к Gateway в том же namespace (Same). Чтобы разрешить маршрутизацию между пространствами имён, используйте поле Allowed Routes Namespace:

• Same: разрешить маршрутам из того же namespace прикрепляться к этому слушателю.
• All: разрешить маршрутам из любого namespace прикрепляться к этому слушателю.
• Selector: разрешить маршрутам из namespace, соответствующих селектору, прикрепляться к этому слушателю.

В ACP проект идентифицируется метками на namespace, например cpaas.io/project: <project-name>. Если вы хотите, чтобы слушатель использовался только маршрутами из определённого проекта, используйте Selector и укажите метку проекта для целевых namespace.

Настройка Allowed Routes Namespace слушателя вместе с его протоколом определяет, какие слушатели доступны в веб-консоли маршрутов при публикации маршрута на слушатель.

Подробнее см. attach to gateway created in other ns.

#Конфигурация TLS

Для протоколов HTTPS и TLS необходимо настроить параметры TLS.

Режимы TLS:

Требования к сертификатам:

• По умолчанию можно использовать только секреты, созданные в том же namespace
• Секрет должен иметь тип kubernetes.io/tls и содержать ключи tls.crt и tls.key
• Для секретов из других namespace см. use secret created in other ns

#EnvoyProxy (конфигурация развертывания)

Envoy Gateway использует ресурс EnvoyProxy для управления конфигурациями развертывания шлюза. Рекомендуется создавать отдельный ресурс EnvoyProxy для каждого Gateway и ссылаться на него через поле .spec.infrastructure.parametersRef Gateway.

При создании Gateway из веб-консоли с использованием GatewayClass, созданного EnvoyGatewayCtl, консоль автоматически создаёт сопутствующий ресурс EnvoyProxy с тем же именем и namespace.

При создании Gateway через применение YAML вы несёте ответственность за согласованность .spec.infrastructure.parametersRef Gateway и соответствующего ресурса EnvoyProxy.

Такой подход один к одному обеспечивает лучшую изоляцию и более тонкий контроль над конфигурациями развертывания, такими как:

• Количество реплик
• Лимиты и запросы ресурсов
• Селекторы узлов
• Тип сервиса и аннотации
• Репозиторий образов

#Репозиторий образов

Репозиторий образов преднастроен со значением по умолчанию для вашего кластера. Не изменяйте его без необходимости.

Для других способов конфигурации развертывания см. deployment-mode.

#Создание Gateway

#Через веб-консоль

1. Перейдите в Alauda Container Platform -> Networking -> Gateway -> Gateways
2. Нажмите кнопку Create Gateway
3. На странице Create Gateway выберите GatewayClass, созданный вашим EnvoyGatewayCtl. В рекомендуемом примере по умолчанию из Envoy Gateway Operator это envoy-gateway-operator-cpaas-default.

Страница отображает следующие параметры конфигурации:

#Конфигурация Listener

При создании или редактировании слушателя можно настроить следующие параметры:

#Конфигурация протокола HTTPS

При выборе протокола HTTPS:

#Конфигурация протокола TLS

При выборе протокола TLS:

Поля конфигурации

Подробнее о режимах TLS см. в разделе TLS Configuration.

#Через YAML

Замените envoy-gateway-operator-cpaas-default на GatewayClass, созданный вашим собственным EnvoyGatewayCtl, если вы не используете рекомендуемый пример по умолчанию.

Следующий минимальный пример создаёт HTTP Gateway и выделенный EnvoyProxy.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: demo
  namespace: demo
spec:
  infrastructure:
    parametersRef:
      group: gateway.envoyproxy.io
      kind: EnvoyProxy
      name: demo
  gatewayClassName: envoy-gateway-operator-cpaas-default
  listeners:
    - name: http
      port: 80
      protocol: HTTP
      allowedRoutes:
        namespaces:
          from: Same
---
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyProxy
metadata:
  name: demo
  namespace: demo
spec:
  provider:
    kubernetes:
      envoyService:
        type: ClusterIP
      envoyDeployment:
        replicas: 1
        container:
          imageRepository: registry.alauda.cn:60080/acp/envoyproxy/envoy
          resources:
            limits:
              cpu: '1'
              memory: 1Gi
            requests:
              cpu: '1'
              memory: 1Gi
    type: Kubernetes

#Полный пример с несколькими типами слушателей

Если вам нужны дополнительные типы слушателей, используйте следующий полный пример:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: demo
  namespace: demo
spec:
  infrastructure:
    parametersRef:
      group: gateway.envoyproxy.io
      kind: EnvoyProxy
      name: demo
  gatewayClassName: envoy-gateway-operator-cpaas-default
  listeners:
    - name: http
      port: 80
      hostname: a.com
      protocol: HTTP
      allowedRoutes:
        namespaces:
          from: Same
    - name: https
      port: 443
      hostname: a.com
      protocol: HTTPS
      allowedRoutes:
        namespaces:
          from: Same
      tls:
        mode: Terminate
        certificateRefs:
          - name: demo-tls
    - name: tls-passthrough
      port: 8443
      hostname: tls.example.com
      protocol: TLS
      allowedRoutes:
        namespaces:
          from: Same
      tls:
        mode: Passthrough
    - name: tls-terminate
      port: 9443
      hostname: secure.example.com
      protocol: TLS
      allowedRoutes:
        namespaces:
          from: Same
      tls:
        mode: Terminate
        certificateRefs:
          - name: demo-tls
    - name: tcp
      port: 8080
      protocol: TCP
      allowedRoutes:
        namespaces:
          from: Same
    - name: udp
      port: 8081
      protocol: UDP
      allowedRoutes:
        namespaces:
          from: Same
---
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyProxy
metadata:
  name: demo
  namespace: demo
spec:
  provider:
    kubernetes:
      envoyService:
        type: ClusterIP
      envoyDeployment:
        replicas: 1
        container:
          imageRepository: registry.alauda.cn:60080/acp/envoyproxy/envoy
          resources:
            limits:
              cpu: '1'
              memory: 1Gi
            requests:
              cpu: '1'
              memory: 1Gi
    type: Kubernetes

#Просмотр сведений Gateway

На странице сведений Gateway в списке слушателей отображается следующая информация:

#Справка по Listener и Route

Используйте следующие правила при прикреплении ресурсов Route к Gateway.

#Имя хоста

Имя хоста в слушателе является уникальным идентификатором для слушателей с одинаковым протоколом. Нельзя добавить или обновить слушателя с конфликтующим именем хоста в одном шлюзе.

#Правило пересечения имён хостов

При поступлении запроса он сопоставляется с пересечением имени хоста слушателя и имён хостов маршрута. Для маршрутизации используется только пересечение имён хостов.

#Поддерживаемые типы маршрутов

Каждый слушатель поддерживает разные типы маршрутов в зависимости от протокола:

При настройке маршрутов убедитесь, что они соответствуют протоколу слушателя, к которому прикрепляются. Например, нельзя прикрепить HTTPRoute к слушателю с протоколом TCP.

#Следующий шаг

После готовности Gateway продолжайте с Configure GatewayAPI Route. Если вам требуется продвинутый контроль трафика после прикрепления маршрутов, продолжайте с Configure GatewayAPI Policy.