Reconfiguração de URL para o Gateway de Aplicativo do Azure para Contêineres - API de Ingresso
O Application Gateway for Containers permite reescrever a URL de uma solicitação de cliente, incluindo o nome do host e/ou o caminho das solicitações. Quando o Application Gateway for Containers inicia a solicitação para o destino de back-end, a solicitação contém a URL recém-reescrita para iniciar a solicitação.
Detalhes de utilização
As regravações de URL aproveitam o recurso personalizado IngressExtension do Application Gateway for Containers.
Fundo
A reconfiguração de URL permite que você traduza uma solicitação de entrada para uma URL diferente quando iniciada para um destino de back-end.
A figura a seguir ilustra uma solicitação destinada a contoso.com/shop sendo reescrita no contoso.com/ecommerce quando a solicitação é iniciada no destino de back-end pelo Application Gateway for Containers:
Pré-requisitos
- Se estiver seguindo a estratégia de implantação do BYO, certifique-se de configurar os recursos do Application Gateway for Containers e do ALB Controller.
- Se estiver seguindo a estratégia de implantação gerenciada ALB, certifique-se de provisionar seu controlador ALB e provisionar os recursos do Application Gateway for Containers por meio do recurso personalizado ApplicationLoadBalancer.
- Implantar aplicativo HTTP de exemplo:
Aplique o seguinte arquivo deployment.yaml em seu cluster para criar um aplicativo Web de exemplo para demonstrar o roteamento baseado em caminho, consulta e cabeçalho.
kubectl apply -f https://trafficcontrollerdocs.blob.core.windows.net/examples/traffic-split-scenario/deployment.yaml
Este comando cria o seguinte no cluster:
- Um namespace chamado
test-infra
- Dois serviços chamados
backend-v1
ebackend-v2
notest-infra
namespace - Duas implantações chamadas
backend-v1
ebackend-v2
notest-infra
namespace
Implantar os recursos necessários da API de ingresso
- Crie um Ingress que captura todo o tráfego e rotas para 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
- Crie um Ingress que corresponda ao prefixo /shop que roteia para backend-v1
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
Nota
Quando o controlador ALB cria os recursos do Application Gateway for Containers em ARM, ele usará a seguinte convenção de nomenclatura para um recurso frontend: fe-8< caracteres gerados aleatoriamente>
Se você quiser alterar o nome do frontend criado no Azure, considere seguir a estratégia traga sua própria implantação.
Quando cada recurso de Ingresso for criado, verifique se o status é válido, se o ouvinte está programado e se um endereço é atribuído ao gateway.
kubectl get ingress ingress-01 -n test-infra -o yaml
kubectl get ingress ingress-02 -n test-infra -o yaml
Exemplo de saída de um dos recursos de entrada.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.networking.azure.io/alb-frontend: FRONTEND_NAME
alb.networking.azure.io/alb-id: /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/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/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/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
Quando o Ingress for criado, crie um recurso IngressExtension para contoso.com
. Este exemplo garante que o tráfego enviado para contoso.com/shop
seja iniciado como contoso.com/ecommerce
destino de back-end.
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
Quando o recurso IngressExtension for criado, verifique se o recurso IngressExtension mostra Accepted e se o recurso Application Gateway for Containers está programado.
kubectl get IngressExtension url-rewrite -n test-infra -o yaml
Verifique se o recurso Application Gateway for Containers foi atualizado com êxito para o IngressExtension.
Testar o acesso à aplicação
Agora estamos prontos para enviar algum tráfego para o nosso aplicativo de exemplo, através do FQDN atribuído ao frontend. Use o comando a seguir para obter o FQDN.
fqdn=$(kubectl get ingress ingress-01 -n test-infra -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
Se você especificar o indicador contoso.com/shop
de nome do servidor usando o comando curl, uma resposta do serviço backend-v1 será retornada com o caminho solicitado para o destino de back-end mostrando contoso.com/ecommerce
.
fqdnIp=$(dig +short $fqdn)
curl -k --resolve contoso.com:80:$fqdnIp http://contoso.com/shop
Através da resposta devemos ver:
{
"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"
}
Se você especificar o indicador contoso.com
de nome do servidor usando o comando curl, uma resposta será retornada do serviço backend-v2, conforme mostrado.
fqdnIp=$(dig +short $fqdn)
curl -k --resolve contoso.com:80:$fqdnIp http://contoso.com
A seguinte resposta deve ser exibida:
{
"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"
}
Parabéns, você instalou o ALB Controller, implantou um aplicativo de back-end e usou o IngressExtension para reescrever a URL solicitada pelo cliente, antes que o tráfego seja definido para o destino no Application Gateway for Containers.