컨테이너용 Azure Application Gateway에 대한 URL 다시 작성 - 수신 API
컨테이너용 Application Gateway를 사용하면 요청의 호스트 이름 및/또는 경로를 포함하여 클라이언트 요청의 URL을 다시 쓸 수 있습니다. 컨테이너용 Application Gateway가 백 엔드 대상에 요청을 시작하면, 요청을 시작하기 위해 새롭게 다시 쓴 URL이 요청에 포함됩니다.
사용량 세부 정보
URL 다시 쓰기는 Containers용 Application Gateway의 IngressExtension 사용자 지정 리소스를 활용합니다.
배경
URL 다시 쓰기를 사용하면 백 엔드 대상으로 시작될 때 들어오는 요청을 다른 URL로 변환할 수 있습니다.
다음 그림에서는 컨테이너용 Application Gateway에 의해 백 엔드 대상으로 요청이 시작될 때 contoso.com/shop으로 향하는 요청이 contoso.com/ecommerce로 다시 작성되는 것을 보여줍니다.
필수 조건
- BYO 배포 전략을 따르는 경우 컨테이너용 Application Gateway 리소스 및 ALB 컨트롤러를 설정했는지 확인합니다.
- ALB 관리된 배포 전략을 따르는 경우 ALB 컨트롤러를 프로비전하고 ApplicationLoadBalancer 사용자 지정 리소스를 통해 컨테이너용 Application Gateway 리소스를 프로비전해야 합니다.
- 샘플 HTTP 애플리케이션을 배포합니다.
클러스터에 다음 배포.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라는 두 배포
필수 수신 API 리소스 배포
- 모든 트래픽을 포착하고 backend-v2로 라우팅하는 수신 만들기
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-01
namespace: test-infra
annotations:
alb.networking.azure.io/alb-name: alb-test
alb.networking.azure.io/alb-namespace: alb-test-infra
spec:
ingressClassName: azure-alb-external
rules:
- host: contoso.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: backend-v2
port:
number: 8080
EOF
- backend-v1로 라우팅되는 /shop 접두사와 일치하는 수신을 만듭니다.
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-02
namespace: test-infra
annotations:
alb.networking.azure.io/alb-name: alb-test
alb.networking.azure.io/alb-namespace: alb-test-infra
alb.networking.azure.io/alb-ingress-extension: url-rewrite
spec:
ingressClassName: azure-alb-external
rules:
- host: contoso.com
http:
paths:
- path: /shop
pathType: Prefix
backend:
service:
name: backend-v1
port:
number: 8080
EOF
참고 항목
ALB 컨트롤러는 ARM에서 컨테이너용 Application Gateway 리소스를 만들 때 프런트 엔드 리소스에 fe-<임의로 생성된 문자 8개>와 같은 명명 규칙을 사용합니다.
Azure에서 만들어진 프런트 엔드의 이름을 변경하려면 자체 배포 전략 가져오기를 따르는 것이 좋습니다.
각 수신 리소스가 만들어지면 상태가 유효한지가, 수신기가 프로그래밍되어 있는지, 주소가 게이트웨이에 할당되어 있는지 확인합니다.
kubectl get ingress ingress-01 -n test-infra -o yaml
kubectl get ingress ingress-02 -n test-infra -o yaml
수신 리소스 중 하나의 출력 예입니다.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.networking.azure.io/alb-frontend: FRONTEND_NAME
alb.networking.azure.io/alb-id: /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/yyyyyyyy/providers/Microsoft.ServiceNetworking/trafficControllers/zzzzzz
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{"alb.networking.azure.io/alb-frontend":"FRONTEND_NAME","alb.networking.azure.io/alb-id":"/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/yyyyyyyy/providers/Microsoft.ServiceNetworking/trafficControllers/zzzzzz"},"name"
:"ingress-01","namespace":"test-infra"},"spec":{"ingressClassName":"azure-alb-external","rules":[{"host":"contoso.com","http":{"paths":[{"backend":{"service":{"name":"backend-v2","port":{"number":8080}}},"path":"/","pathType":"Prefix"}]}}]}}
creationTimestamp: "2023-07-22T18:02:13Z"
generation: 2
name: ingress-01
namespace: test-infra
resourceVersion: "278238"
uid: 17c34774-1d92-413e-85ec-c5a8da45989d
spec:
ingressClassName: azure-alb-external
rules:
- host: contoso.com
http:
paths:
- backend:
service:
name: backend-v2
port:
number: 8080
path: /
pathType: Prefix
status:
loadBalancer:
ingress:
- hostname: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.fzyy.alb.azure.com
ports:
- port: 80
protocol: TCP
수신이 만들어지면 contoso.com에 대한 IngressExtension 리소스를 만듭니다. 이 예제는 contoso.com/shop으로 전송된 트래픽이 백 엔드 대상의 contoso.com/ecommerce로 시작되는지 확인합니다.
kubectl apply -f - <<EOF
apiVersion: alb.networking.azure.io/v1
kind: IngressExtension
metadata:
name: url-rewrite
namespace: test-infra
spec:
rules:
- host: contoso.com
rewrites:
- type: URLRewrite
urlRewrite:
path:
type: ReplacePrefixMatch
replacePrefixMatch: /ecommerce
EOF
IngressExtension 리소스가 만들어지면 IngressExtension 리소스가 수락됨 상태이고 컨테이너용 Application Gateway 리소스가 프로그래밍됨 상태인지 확인합니다.
kubectl get IngressExtension url-rewrite -n test-infra -o yaml
IngressExtension에 대해 컨테이너용 Application Gateway 리소스가 성공적으로 업데이트되었는지 확인합니다.
애플리케이션에 대한 액세스 테스트
이제 프런트 엔드에 할당된 FQDN을 통해 샘플 애플리케이션에 일부 트래픽을 전송할 준비가 되었습니다. 다음 명령을 사용하여 FQDN을 가져옵니다.
fqdn=$(kubectl get ingress ingress-01 -n test-infra -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
curl 명령을 사용하여 서버 이름 표시기 contoso.com/shop을 지정하면 backend-v1 서비스의 응답이 contoso.com/ecommerce를 표시하는 백 엔드 대상에 대한 요청된 경로와 함께 반환됩니다.
fqdnIp=$(dig +short $fqdn)
curl -k --resolve contoso.com:80:$fqdnIp http://contoso.com/shop
응답을 통해 다음을 확인해야 합니다.
{
"path": "/ecommerce",
"host": "contoso.com",
"method": "GET",
"proto": "HTTP/1.1",
"headers": {
"Accept": [
"*/*"
],
"User-Agent": [
"curl/7.81.0"
],
"X-Forwarded-For": [
"xxx.xxx.xxx.xxx"
],
"X-Forwarded-Proto": [
"http"
],
"X-Request-Id": [
"dcd4bcad-ea43-4fb6-948e-a906380dcd6d"
]
},
"namespace": "test-infra",
"ingress": "",
"service": "",
"pod": "backend-v1-5b8fd96959-f59mm"
}
curl 명령을 사용하여 서버 이름 표시기 contoso.com을 지정하면 표시된 대로 backend-v2 서비스에서 응답이 반환됩니다.
fqdnIp=$(dig +short $fqdn)
curl -k --resolve contoso.com:80:$fqdnIp http://contoso.com
다음 응답이 표시되어야 합니다.
{
"path": "/",
"host": "contoso.com",
"method": "GET",
"proto": "HTTP/1.1",
"headers": {
"Accept": [
"*/*"
],
"User-Agent": [
"curl/7.81.0"
],
"X-Forwarded-For": [
"xxx.xxx.xxx.xxx"
],
"X-Forwarded-Proto": [
"http"
],
"X-Request-Id": [
"adae8cc1-8030-4d95-9e05-237dd4e3941b"
]
},
"namespace": "test-infra",
"ingress": "",
"service": "",
"pod": "backend-v2-594bd59865-ppv9w"
}
축하합니다. 트래픽이 컨테이너용 Application Gateway의 대상으로 설정되기 전에 ALB 컨트롤러를 설치하고 백 엔드 애플리케이션을 배포했으며, IngressExtension을 사용하여 클라이언트 요청 URL을 다시 작성했습니다.