#Настройка Gateway

Входящий шлюз (Gateway) — это экземпляр, развернутый из Gateway Class. Он создает слушатели для перехвата внешнего трафика на указанных доменных именах и портах. Вместе с правилами маршрутизации он может направлять указанный внешний трафик на соответствующие backend-экземпляры.

Создайте входящий шлюз для более точного распределения сетевых ресурсов.

#Терминология

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

Администратор платформы должен убедиться, что кластер поддерживает внутреннюю маршрутизацию типа LoadBalancer. Для публичных облачных кластеров должен быть установлен LoadBalancer Service Controller. В непубличных облачных кластерах платформа предоставляет функцию пула внешних адресов, которая позволяет внутренней маршрутизации типа LoadBalancer автоматически получать IP из пула внешних адресов для внешнего доступа после завершения настройки.

#Пример Gateway и пользовательского ресурса Alb2 (CR)

# demo-gateway.yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  namespace: k-1
  name: test
  annotations:
    cpaas.io/display-name: ces
    listeners.cpaas.io/creationTimestamp: '["2025-05-26T02:05:56.135Z"]'
    listeners.cpaas.io/display-name: '[""]'
  labels:
    alb.cpaas.io/alb-ref: test-o93q7
spec:
  gatewayClassName: exclusive-gateway
  listeners:
    - allowedRoutes:
        namespaces:
          from: All
      name: gateway-metric
      protocol: TCP
      port: 11782
---
apiVersion: crd.alauda.io/v2beta1
kind: ALB2
metadata:
  namespace: k-1
  name: test-o93q7
spec:
  type: nginx
  config:
    enableAlb: false
    networkMode: container
    resources:
      limits:
        cpu: 200m
        memory: 256Mi
      requests:
        cpu: 200m
        memory: 256Mi
    vip:
      enableLbSvc: true
      lbSvcAnnotations: {}
    gateway:
      mode: standalone
      name: test # # [!code callout]

#Создание Gateway через веб-консоль

1. Перейдите в Container Platform.

2. В левой навигационной панели выберите Network > Inbound Gateway.

3. Нажмите Create Inbound Gateway.

4. Следуйте инструкциям для настройки конкретных параметров.

   Параметр	Описание
   Name	Имя входящего шлюза.
   Gateway Class	Gateway Class определяет поведение шлюза, аналогично концепции классов хранения (StorageClasses); это ресурс кластера. Dedicated: входящий шлюз будет соответствовать конкретному экземпляру ресурса, и пользователь сможет использовать все слушатели и вычислительные ресурсы этого шлюза.
   Specification	Можно выбрать рекомендованный сценарий использования в зависимости от потребностей или настроить лимиты ресурсов самостоятельно.
   Access Address	Адрес входящего шлюза, который по умолчанию получается автоматически.
   Internal Routing Annotation	Используется для объявления конфигурации или возможностей внутренней маршрутизации типа LoadBalancer. Для подробной информации об аннотациях смотрите LoadBalancer type internal routing annotation instructions.

5. Нажмите Create.

#Создание Gateway через CLI

kubectl apply -f demo-gateway.yaml

#Просмотр ресурсов, созданных платформой

После создания входящего шлюза платформа автоматически создает множество ресурсов. Не удаляйте перечисленные ниже ресурсы.

#Обновление Gateway

#Обновление Gateway через веб-консоль

1. Зайдите в Container Platform.

2. В левой навигационной панели выберите Network > Inbound Gateway.

3. Нажмите ⋮ > Update.

4. Обновите конфигурацию входящего шлюза по необходимости.

   Примечание: Пожалуйста, разумно задавайте спецификации в соответствии с бизнес-требованиями.

5. Нажмите Update.

#Добавление слушателя

Отслеживает трафик по указанным доменным именам и перенаправляет его на backend-экземпляры согласно привязанным правилам маршрутизации.

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

• Если необходимо отслеживать протокол HTTP, заранее свяжитесь с администратором для подготовки доменного имени.

• Если необходимо отслеживать протокол HTTPS, заранее свяжитесь с администратором для подготовки доменного имени и сертификата.

#Добавление слушателя через веб-консоль

1. В левой навигационной панели выберите Network > Inbound Gateway.

2. Нажмите на Имя входящего шлюза.

3. Нажмите Add Listener.

4. Следуйте инструкциям для настройки конкретных параметров.

   Параметр	Описание
   Протокол и порт слушателя	В настоящее время поддерживается мониторинг протоколов HTTP, HTTPS, TCP и UDP, можно ввести порт для мониторинга, например: 80. Примечание: При совпадении портов типы слушателей HTTP, HTTPS и TCP не могут сосуществовать; можно выбрать только один из протоколов. При использовании HTTP или HTTPS и совпадении портов доменные имена должны быть разными.
   Доменное имя	Выберите доступное доменное имя в текущем namespace для мониторинга сетевого трафика, обращающегося к этому домену. Подсказка: протоколы TCP и UDP не поддерживают выбор доменных имен.

5. Нажмите Create.

#Добавление слушателя через CLI

kubectl patch gateway test \
  -n k-1 \
  --type=merge \
  -p '{
    "metadata": {
      "annotations": {
        "listeners.cpaas.io/creationTimestamp": "[\"2025-05-26T02:05:56.135Z\",\"2025-05-26T03:33:52.431Z\"]",
        "listeners.cpaas.io/display-name": "[\"\",\"\" ]"
      }
    },
    "spec": {
      "listeners": [
        {
          "allowedRoutes": {
            "namespaces": {
              "from": "All"
            }
          },
          "name": "gateway-metric",
          "protocol": "TCP",
          "port": 11782
        },
        {
          "allowedRoutes": {
            "namespaces": {
              "from": "All"
            }
          },
          "name": "demo-listener",
          "protocol": "HTTP",
          "port": 8088,
          "hostname": "developer.test.cn"
        }
      ]
    }
  }'

#Создание правил маршрутизации

Правила маршрутизации задают политики маршрутизации для входящего трафика, аналогично входящим правилам (Kubernetes Ingress). Они обеспечивают доступ к сетевому трафику, отслеживаемому шлюзом, для внутренней маршрутизации кластера (Kubernetes Service), облегчая стратегию маршрутизации и переадресации. Главное отличие в том, что они нацелены на разные объекты сервиса: входящие правила обслуживают Ingress Controller, а правила маршрутизации — Ingress Gateway.

После настройки прослушивания в ingress gateway шлюз будет в реальном времени отслеживать трафик с указанных доменов и портов. Правила маршрутизации могут направлять входящий трафик на backend-экземпляры по желанию.

#Пример пользовательского ресурса HTTPRoute (CR)

# example-httproute.yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  namespace: k-1
  name: example-http-route
  annotations:
    cpaas.io/display-name: ""
spec:
  hostnames:
    - developer.test.cn
  parentRefs:
    - kind: Gateway
      namespace: k-1
      name: test
      sectionName: demo-listener
  rules:
    - matches:
        - path:
            type: Exact
            value: "/demo"
      filters: []
      backendRefs:
        - kind: Service
          name: test-service
          namespace: k-1
          port: 80
          weight: 100

#Создание маршрута через веб-консоль

1. Зайдите в Container Platform.

2. В левой навигационной панели выберите Network > Route Rules.

3. Нажмите Create Route Rule.

4. Следуйте инструкциям для настройки параметров.

   Параметр	Описание
   Тип маршрута	В настоящее время поддерживаются типы маршрутов: HTTPRoute, TCPRoute, UDPRoute. Подсказка: HTTPRoute поддерживает публикацию на слушатели протоколов HTTP и HTTPS.
   Публикация на слушатель	В левой панели выберите созданный Ingress Gateway, в правой — созданный Listener. Платформа опубликует созданные правила маршрутизации на выбранный слушатель, позволяя шлюзу перенаправлять перехваченный трафик на указанные backend-экземпляры. Примечание: Нельзя публиковать правила маршрутизации на слушатель, который работает на порту 11782 или уже содержит TCP или UDP маршруты.
   Совпадение (Match)	Можно добавить одно или несколько правил совпадения для перехвата трафика, соответствующего требованиям. Например, перехват трафика с указанным Path, перехват трафика с указанным методом и т.д. Примечание: Нажмите Add; при добавлении нескольких правил маршрутизации связь между ними — 'AND', все правила должны совпадать для активации. Нажмите Add Match; при добавлении нескольких групп правил связь между группами — 'OR', достаточно совпадения любой группы для активации. TCPRoute и UDPRoute не поддерживают настройку правил совпадения. Если объект совпадения — path, а метод совпадения — Exact или PathPrefix, значение value должно начинаться с "/" и не должно содержать символы типа "//", "/./", "/../", "%2f", "%2F", "#", "/..", "/." и т.п.
   Действие (Action)	Можно добавить одно или несколько действий для обработки перехваченного трафика. Header: заголовок HTTP-сообщения содержит много метаданных, предоставляющих дополнительную информацию о запросе или ответе. Изменяя поля заголовка, сервер может влиять на обработку запроса и ответа. Redirect: совпадающий URL будет обработан указанным образом, затем запрос будет инициирован заново. Rewrite: совпадающий URL будет обработан указанным образом, затем запрос будет перенаправлен на другой путь ресурса или имя файла. Примечание: Нажмите Add; при добавлении нескольких правил действий платформа выполнит все действия последовательно в порядке отображения. TCPRoute и UDPRoute не поддерживают настройку правил действий. В одном правиле маршрутизации не может быть несколько действий типа Header с одинаковым значением value. В одном правиле маршрутизации может быть только одно действие типа Redirect или Rewrite, и только один режим из FullPath или PrefixPath. Если хотите использовать операцию PrefixPath, сначала добавьте правило совпадения с режимом PathPrefix.
   Backend Instance	После активации правила трафик будет перенаправлен на backend-экземпляры согласно выбранным внутренним маршрутам и портам в текущем namespace. Можно также настроить веса, при этом экземпляры с большим весом будут выбираться с большей вероятностью. Подсказка: Процент рядом с весом показывает вероятность перенаправления на этот экземпляр, рассчитываемую как отношение текущего значения веса к сумме всех весов.

5. Нажмите Create.

#Создание маршрута через CLI

kubectl apply -f example-httproute.yaml