컨테이너용 Application Gateway를 사용한 경로, 헤더 및 쿼리 문자열 라우팅 - 게이트웨이 API

아티클
11/05/2024

이 문서는 게이트웨이 API의 리소스를 사용하여 URL 경로, 쿼리 문자열 및 헤더를 기반으로 하는 트래픽 라우팅을 보여 주는 예 애플리케이션을 설정하는 데 도움이 됩니다. 다음 단계가 제공됩니다.

하나의 HTTPS 수신기를 사용하여 게이트웨이 리소스를 만듭니다.
백 엔드 서비스를 참조하는 HTTPRoute 리소스를 만듭니다.
경로, 헤더 및 쿼리 문자열을 기반으로 경로를 지정하는 matches를 수행하려면 HTTPRouteMatch를 사용합니다.

배경

컨테이너용 Application Gateway는 URL 경로, 쿼리 문자열 및 헤더를 기반으로 트래픽 라우팅을 가능하게 합니다. 다음과 같은 예제 시나리오를 참조하세요.

컨테이너용 Application Gateway를 사용한 경로, 헤더 및 쿼리 문자열 라우팅을 보여 주는 그림.

필수 조건

BYO 배포 전략을 따르는 경우 컨테이너용 Application Gateway 리소스 및 ALB 컨트롤러를 설정했는지 확인합니다.
ALB 관리형 배포 전략을 따르는 경우 ALB 컨트롤러를 프로비전하고 ApplicationLoadBalancer 사용자 지정 리소스를 통해 컨테이너용 Application Gateway 리소스를 프로비전했는지 확인합니다.
샘플 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라는 네임스페이스
- test-infra 네임스페이스에 있는 backend-v1 및 backend-v2라는 두 서비스
- test-infra 네임스페이스에 있는 backend-v1 및 backend-v2라는 두 배포

게이트웨이 만들기:

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에서 컨테이너용 Application Gateway 리소스를 만들 때 프런트 엔드 리소스에 fe-<임의로 생성된 문자 8개>와 같은 명명 규칙을 사용합니다.

Azure에서 만들어진 프런트 엔드의 이름을 변경하려면 자체 배포 전략 가져오기를 따르는 것이 좋습니다.

다음 환경 변수를 설정합니다.

RESOURCE_GROUP='<resource group name of the Application Gateway For Containers resource>'
RESOURCE_NAME='alb-test'

RESOURCE_ID=$(az network alb show --resource-group $RESOURCE_GROUP --name $RESOURCE_NAME --query id -o tsv)
FRONTEND_NAME='frontend'

게이트웨이 만들기

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-id: $RESOURCE_ID
spec:
  gatewayClassName: azure-alb-external
  listeners:
  - name: http-listener
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: Same
  addresses:
  - type: alb.networking.azure.io/alb-frontend
    value: $FRONTEND_NAME
EOF

게이트웨이 리소스가 만들어지면 상태가 유효한지, 수신기가 프로그래밍됨인지, 주소가 게이트웨이에 할당되었는지 확인합니다.

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이면 트래픽이 포트 8080의 backend-v2 서비스로 라우팅됩니다. 또는
요청에 이름이 magic이고 값이 foo인 HTTP 헤더가 포함된 경우 URL에는 example 값으로 great라는 이름을 정의하는 쿼리 문자열이 포함되어 있고 경로는 /some/thing이며 요청은 포트 8080의 backend-v2로 전송됩니다.
그렇지 않으면 다른 모든 요청은 포트 8080의 backend-v1 서비스로 라우팅됩니다.

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 리소스가 만들어지면 경로가 수락되었고 컨테이너용 Application Gateway 리소스가 프로그래밍되었는지 확인합니다.

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

컨테이너용 Application Gateway 리소스의 상태가 성공적으로 업데이트되었는지 확인합니다.

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을 통해 샘플 애플리케이션에 일부 트래픽을 전송할 준비가 되었습니다. FQDN을 가져오려면 다음 명령을 사용합니다.

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입니다.

이 시나리오에서는 "magic: foo"의 헤더 키/값 부분을 포함하여 http://frontend-fqdn/some/thing?great=example에 전송된 클라이언트 요청이 backend-v2 서비스로 라우팅됩니다.

다음 명령을 실행합니다.

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

요청을 처리하는 컨테이너는 backend-v2입니다.

기본 경로

처음 두 시나리오 중 어느 것도 충족되지 않으면 컨테이너용 Azure Application Gateway는 다른 모든 요청을 backend-v1 서비스로 라우팅합니다.

다음 명령을 실행합니다.

curl http://$fqdn/

요청을 처리하는 컨테이너는 backend-v1입니다.

축하합니다. ALB 컨트롤러를 설치하고, 백 엔드 애플리케이션을 배포하고, 컨테이너용 Azure Application Gateway의 게이트웨이 API를 통해 애플리케이션으로 트래픽을 라우팅했습니다.

다음을 통해 공유

컨테이너용 Application Gateway를 사용한 경로, 헤더 및 쿼리 문자열 라우팅 - 게이트웨이 API

배경

필수 조건

필수 게이트웨이 API 리소스 배포

애플리케이션에 대한 액세스 테스트

경로 기반 라우팅

쿼리 문자열 + 헤더 + 경로 라우팅

기본 경로

피드백

추가 리소스