Поделиться через

Маршрутизация пути, заголовка и строки запроса с помощью шлюза приложений для контейнеров — API Gateway.

Этот документ помогает настроить пример приложения, использующего ресурсы из API шлюза для демонстрации маршрутизации трафика на основе URL-пути, строки запроса и заголовка. Предоставлены следующие шаги:

  • Создайте ресурс шлюза с одним прослушивателем HTTPS.
  • Создайте ресурс HTTPRoute, ссылающийся на серверную службу.
  • Используйте HTTPRouteMatch для выполнения matches этого маршрута на основе пути, заголовка и строки запроса.

Предыстория

Шлюз приложений для контейнеров обеспечивает маршрутизацию трафика на основе пути URL-адреса, строки запроса и заголовка. См. следующий пример сценария:

Рисунок, показывающий маршрутизацию строк пути, заголовка и строки запроса с помощью шлюза приложений для контейнеров.

Предпосылки

  1. Если вы используете стратегию развертывания BYO, убедитесь, что вы настроили Шлюз приложений для ресурсов контейнеров и контроллера балансировки нагрузки.

  2. Если вы следуете стратегии управляемого развертывания ALB, убедитесь, что вы подготовили контроллер ALB и настроили Шлюз приложений для контейнеров с помощью настраиваемого ресурса ApplicationLoadBalancer.

  3. Развертывание примера HTTP-приложения Применить следующий файл deployment.yaml в кластере, чтобы создать пример веб-приложения для демонстрации маршрутизации на основе пути, запроса и заголовка.

    kubectl apply -f https://raw.githubusercontent.com/MicrosoftDocs/azure-docs/refs/heads/main/articles/application-gateway/for-containers/examples/traffic-split-scenario/deployment.yaml

    Эта команда создает следующее в вашем кластере:

    • пространство имен с именем test-infra
    • две службы под названием backend-v1 и backend-v2 в пространстве имен test-infra
    • два развертывания, названные backend-v1 и backend-v2 в пространстве имен test-infra

Развертывание необходимых ресурсов API шлюза

Создайте шлюз:

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: gateway-01
  namespace: test-infra
  annotations:
    alb.networking.azure.io/alb-namespace: alb-test-infra
    alb.networking.azure.io/alb-name: alb-test
spec:
  gatewayClassName: azure-alb-external
  listeners:
  - name: http-listener
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: Same
EOF

Замечание

Когда контроллер ALB создает шлюз приложений для ресурсов контейнеров в Azure Resource Manager, он использует следующее соглашение об именовании для внешнего ресурса: fe-<eight randomly generated characters>

Если вы хотите изменить имя ресурса фронтенда, созданного в Azure, рассмотрите возможность использования стратегии развертывания «принеси свой».

После создания ресурса шлюза убедитесь, что состояние является допустимым, прослушиватель запрограммирован, а адрес назначается шлюзу.

kubectl get gateway gateway-01 -n test-infra -o yaml

Пример выходных данных успешного создания шлюза.

status:
  addresses:
  - type: Hostname
    value: xxxx.yyyy.alb.azure.com
  conditions:
  - lastTransitionTime: "2023-06-19T21:04:55Z"
    message: Valid Gateway
    observedGeneration: 1
    reason: Accepted
    status: "True"
    type: Accepted
  - lastTransitionTime: "2023-06-19T21:04:55Z"
    message: Application Gateway For Containers resource has been successfully updated.
    observedGeneration: 1
    reason: Programmed
    status: "True"
    type: Programmed
  listeners:
  - attachedRoutes: 0
    conditions:
    - lastTransitionTime: "2023-06-19T21:04:55Z"
      message: ""
      observedGeneration: 1
      reason: ResolvedRefs
      status: "True"
      type: ResolvedRefs
    - lastTransitionTime: "2023-06-19T21:04:55Z"
      message: Listener is accepted
      observedGeneration: 1
      reason: Accepted
      status: "True"
      type: Accepted
    - lastTransitionTime: "2023-06-19T21:04:55Z"
      message: Application Gateway For Containers resource has been successfully updated.
      observedGeneration: 1
      reason: Programmed
      status: "True"
      type: Programmed
    name: https-listener
    supportedKinds:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute

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

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

  1. Если путь равен /bar, трафик направляется в серверную службу версии 2 через порт 8080 ИЛИ
  2. Если запрос содержит заголовок HTTP с именем magic и значением foo, URL-адрес содержит строку запроса, определяющую имя great со значением example, и путь /some/thing, запрос отправляется на backend-v2 на порт 8080.
  3. В противном случае все остальные запросы направляются в службу backend-v1 через порт 8080.
kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: http-route
  namespace: test-infra
spec:
  parentRefs:
  - name: gateway-01
    namespace: test-infra
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /bar
    backendRefs:
    - name: backend-v2
      port: 8080
  - matches:
    - headers:
      - type: Exact
        name: magic
        value: foo
      queryParams:
      - type: Exact
        name: great
        value: example
      path:
        type: PathPrefix
        value: /some/thing
      method: GET
    backendRefs:
    - name: backend-v2
      port: 8080
  - backendRefs:
    - name: backend-v1
      port: 8080
EOF

Подсказка

Шлюз приложений для контейнеров поддерживает сопоставление регулярных выражений для headers, queryParams и path правил с использованием синтаксиса RE2 (Regular Expression 2). Дополнительные сведения см. в спецификации API шлюза.

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

kubectl get httproute http-route -n test-infra -o yaml

Убедитесь, что состояние ресурса Шлюз приложений для контейнеров успешно обновлено.

status:
  parents:
  - conditions:
    - lastTransitionTime: "2023-06-19T22:18:23Z"
      message: ""
      observedGeneration: 1
      reason: ResolvedRefs
      status: "True"
      type: ResolvedRefs
    - lastTransitionTime: "2023-06-19T22:18:23Z"
      message: Route is Accepted
      observedGeneration: 1
      reason: Accepted
      status: "True"
      type: Accepted
    - lastTransitionTime: "2023-06-19T22:18:23Z"
      message: Application Gateway For Containers resource has been successfully updated.
      observedGeneration: 1
      reason: Programmed
      status: "True"
      type: Programmed
    controllerName: alb.networking.azure.io/alb-controller
    parentRef:
      group: gateway.networking.k8s.io
      kind: Gateway
      name: gateway-01
      namespace: test-infra

Проверка доступа к приложению.

Теперь мы готовы отправить определённый трафик к нашему примерному приложению через полное доменное имя, назначенное фронтенду. Чтобы получить полное доменное имя, используйте следующую команду.

fqdn=$(kubectl get gateway gateway-01 -n test-infra -o jsonpath='{.status.addresses[0].value}')

С помощью команды curl мы можем проверить три различных сценария:

Маршрутизация на основе путей

В этом сценарии запрос клиента отправляется http://frontend-fqdn/bar в сервис backend-v2.

Выполните следующую команду:

curl http://$fqdn/bar

Обратите внимание, что контейнер, обрабатывающий запрос, называется backend-v2.

Строка запроса + заголовок + маршрутизация пути

В этом сценарии запрос клиента, отправленный на http://frontend-fqdn/some/thing?great=example с частью заголовка ключ/значение, "magic: foo," направляется в службу backend-v2.

Выполните следующую команду:

curl http://$fqdn/some/thing?great=example -H "magic: foo"

Обратите внимание, что контейнер, обрабатывающий запрос, называется backend-v2.

маршрут по умолчанию.

Если ни один из первых двух сценариев не удовлетворен, шлюз приложений для контейнеров направляет все остальные запросы в службу серверной части версии 1.

Выполните следующую команду:

curl http://$fqdn/

Обратите внимание, что контейнер, обслуживающий запрос, называется бэкенд-v1.

Поздравляем, вы установили контроллер ALB (Application Load Balancer), развернули серверное приложение и перенаправили трафик к приложению через API шлюза на шлюз приложений для контейнеров.

  • Last updated on