Маршрутизация строк пути, заголовка и запроса с помощью Шлюз приложений для контейнеров — API шлюза
Этот документ помогает настроить пример приложения, использующего ресурсы из API шлюза для демонстрации маршрутизации трафика на основе URL-пути, строки запроса и заголовка. Ниже приведены действия.
- Создайте ресурс шлюза с одним прослушивателем HTTPS.
- Создайте ресурс HTTPRoute, ссылающийся на серверную службу.
- Используйте HTTPRouteMatch для выполнения
matches
этого маршрута на основе пути, заголовка и строки запроса.
Общие сведения
Шлюз приложений для контейнеров обеспечивает маршрутизацию трафика на основе URL-пути, строки запроса и заголовка. См. следующий пример сценария:
Необходимые компоненты
Если вы используете стратегию развертывания BYO, убедитесь, что вы настроили Шлюз приложений для ресурсов контейнеров и контроллера балансировки нагрузки.
Если вы выполнили стратегию управляемого развертывания ALB, убедитесь, что вы подготовили контроллер ALB и подготовили Шлюз приложений для ресурсов контейнеров с помощью настраиваемого ресурса ApplicationLoadBalancer.
Развертывание примера HTTP-приложения Применить следующий файл deployment.yaml в кластере, чтобы создать пример веб-приложения для демонстрации маршрутизации на основе пути, запроса и заголовка.
kubectl apply -f https://trafficcontrollerdocs.blob.core.windows.net/examples/traffic-split-scenario/deployment.yaml
Эта команда создает следующую команду в кластере:
- пространство имен с именем
test-infra
- две службы, вызываемые
backend-v1
test-infra
иbackend-v2
в пространстве имен - два развертывания, вызываемые
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 создает Шлюз приложений для ресурсов контейнеров в ARM, он будет использовать следующее соглашение об именовании для внешнего ресурса: fe-8< случайным образом созданные символы>
Если вы хотите изменить имя внешнего интерфейса, созданного в 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, чтобы определить два разных совпадения и службу по умолчанию для маршрутизации трафика.
Способ чтения следующих правил выглядит следующим образом:
- Если путь равен /bar, трафик направляется в серверную службу версии 2 через порт 8080 ИЛИ
- Если запрос содержит заголовок HTTP с магией имен и значением foo, URL-адрес содержит строку запроса, определяющую имя с большим значением примера, и путь является /some/thing, запрос отправляется в серверную часть-v2 через порт 8080.
- В противном случае все остальные запросы направляются в службу 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
После создания ресурса 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 в серверную службу версии 2.
Выполните следующую команду:
curl http://$fqdn/bar
Обратите внимание, что контейнер, обслуживающий запрос, является серверной частью 2.
Строка запроса + заголовок + маршрутизация пути
В этом сценарии запрос клиента, отправленный http://frontend-fqdn/some/thing?great=example с ключом заголовка или значением, частью "magic: foo" направляется в службу backend-v2.
Выполните следующую команду:
curl http://$fqdn/some/thing?great=example -H "magic: foo"
Обратите внимание, что контейнер, обслуживающий запрос, является серверной частью 2.
маршрут по умолчанию.
Если ни один из первых двух сценариев не удовлетворен, Шлюз приложений для контейнеров направляет все остальные запросы в службу серверной части версии 1.
Выполните следующую команду:
curl http://$fqdn/
Обратите внимание, что контейнер, обслуживающий запрос, является серверной частью версии 1.
Поздравляем, вы установили контроллер ALB, развернули серверное приложение и перенаправили трафик в приложение через API шлюза в Шлюз приложений для контейнеров.