Regravação da URL do Gateway de Aplicativo do Azure para Contêineres – API de Entrada

Artigo
11/05/2024

O Gateway de Aplicativo para contêineres permite que você reescreva a URL de uma solicitação de cliente, incluindo o nome do host e/ou o caminho das solicitações. Quando o Gateway de Aplicativo para contêineres inicia a solicitação para o destino de back-end, a solicitação contém a URL reescrita recentemente para iniciar a solicitação.

Detalhes de uso

As regravações de URL aproveitam o recurso personalizado do IngressExtension do Gateway de Aplicativo para Contêineres.

Tela de fundo

A reescrita 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 para contoso.com/ecommerce quando a solicitação é iniciada no destino de back-end pelo Gateway de Aplicativo para Contêineres:

Pré-requisitos

Se estiver seguindo a estratégia de implantação BYO, verifique se você configurou os recursos do Gateway de Aplicativos para contêineres e o Controlador ALB.
Se estiver seguindo a estratégia de implantação gerenciada do ALB, verifique se você provisionou o Controlador ALB e os recursos do Gateway de Aplicativos para contêineres por meio do recurso personalizado ApplicationLoadBalancer.
Implantar um 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://raw.githubusercontent.com/MicrosoftDocs/azure-docs/refs/heads/main/articles/application-gateway/for-containers/examples/traffic-split-scenario/deployment.yaml

Esse comando cria o seguinte no cluster:

Um namespace chamado test-infra
Dois serviços chamados backend-v1 e backend-v2 no namespace test-infra
Duas implantações chamadas backend-v1 e backend-v2 no namespace test-infra

Implantar os recursos de API de Entrada necessários

Implantação gerenciada do ALB
Traga sua própria implantação (BYO)

Criar uma entrada que captura todo o tráfego e rotas para back-end-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

Criar uma entrada que corresponda ao prefixo /shop que roteia para back-end-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

Observação

Quando o Controlador ALB cria os recursos do Gateway de Aplicativos para contêineres no ARM, ele usará a seguinte convenção de nomenclatura para um recurso de front-end: fe-<oito caracteres gerados aleatoriamente>

Se você quiser alterar o nome do front-end criado no Azure, siga a estratégia de trazer sua própria implantação.

Definir as seguintes variáveis de ambiente

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'

Criar uma entrada que captura todo o tráfego e rotas para back-end-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-id: $RESOURCE_ID
    alb.networking.azure.io/alb-frontend: $FRONTEND_NAME
spec:
  ingressClassName: azure-alb-external
  rules:
    - host: contoso.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: backend-v2
                port:
                  number: 8080
EOF

Criar uma entrada que corresponda ao prefixo /shop e rotas para back-end-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-id: $RESOURCE_ID
    alb.networking.azure.io/alb-frontend: $FRONTEND_NAME
    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

Quando cada recurso de entrada é criado, verifique se o status é válido, o ouvinte é Programado e 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

Saída de exemplo 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/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

Quando a entrada for criada, 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 no 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 Aceito e se o recurso Gateway de Aplicativo para Contêineres é Programado.

kubectl get IngressExtension url-rewrite -n test-infra -o yaml

Verifique se o recurso Gateway de Aplicativo para Contêineres foi atualizado com sucesso em cada HTTPRoute.

Testar o acesso ao aplicativo

Agora estamos prontos para enviar algum tráfego para nosso aplicativo de exemplo, por meio do FQDN atribuído ao front-end. 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 de nome do servidor contoso.com/shop usando o comando curl, uma resposta do serviço back-end-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

Pela resposta, veremos que:

{
 "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 de nome do servidor contoso.com usando o comando curl, uma resposta será retornada do serviço back-end-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 Controlador ALB, implantou um aplicativo de back-end e usou o IngressExtension para reescrever a URL solicitada pelo cliente, antes do tráfego ser definido como o destino no Gateway de Aplicativo para Contêineres.

Compartilhar via