Reconfiguração de cabeçalho para o Gateway de Aplicativo do Azure para Contêineres - API de Ingresso

Artigo
11/05/2024

O Application Gateway for Containers permite reescrever cabeçalhos HTTP de solicitações de clientes e respostas de destinos de back-end.

Detalhes de utilização

As regravações de cabeçalho aproveitam o recurso personalizado IngressExtension do Application Gateway for Container.

Fundo

As regravações de cabeçalho permitem que você modifique os cabeçalhos de solicitação e resposta de e para seus destinos de back-end.

A figura a seguir ilustra um exemplo de uma solicitação com um agente de usuário específico sendo reescrito em um valor simplificado chamado rewritten-user-agent 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 ter configurado os recursos do Application Gateway for Containers e do ALB Controller
Se estiver seguindo a estratégia de implantação gerenciada por ALB, certifique-se de ter provisionado seu controlador ALB e provisionado 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 a regravação do 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
```
Este comando cria o seguinte no cluster:
- um namespace chamado test-infra
- Dois serviços chamados backend-v1 e backend-v2 no test-infra namespace
- duas implantações chamadas backend-v1 e backend-v2 no test-infra namespace

Implantar os recursos necessários da API de ingresso

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

Crie um recurso de Ingresso para ouvir solicitações para contoso.com:

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
    alb.networking.azure.io/alb-ingress-extension: header-rewrite
spec:
  ingressClassName: azure-alb-external
  rules:
    - host: contoso.com
      http:
        paths:
          - path: /
            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.

Defina 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'

Crie um recurso de Ingresso para ouvir solicitações para contoso.com

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
    alb.networking.azure.io/alb-ingress-extension: header-rewrite
spec:
  ingressClassName: azure-alb-external
  rules:
    - host: contoso.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: backend-v1
                port:
                  number: 8080
EOF

Depois que o recurso de entrada for criado, verifique se o status mostra o nome do host do seu balanceador de carga e se ambas as portas estão escutando solicitações.

kubectl get ingress ingress-01 -n test-infra -o yaml

Exemplo de saída da criação bem-sucedida do Ingress.

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", "alb.networking.azure.io/alb-ingress-extension":"header-rewrite"},"name"
:"ingress-01","namespace":"test-infra"},"spec":{"ingressClassName":"azure-alb-external","rules":[{"host":"contoso.com","http":{"paths":[{"backend":{"service":{"name":"backend-v1","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:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: backend-v1
                port:
                  number: 8080
status:
  loadBalancer:
    ingress:
    - hostname: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.fzyy.alb.azure.com
      ports:
      - port: 80
        protocol: TCP

Uma vez que o Ingress é criado, em seguida, precisamos definir um IngressExtension com as regras de reescrita de cabeçalho.

Neste exemplo, definimos um user-agent estático com um valor de rewritten-user-agent.

Este exemplo também demonstra a adição de um novo cabeçalho chamado AGC-Header-Add com um valor de e remove um cabeçalho de AGC-value solicitação chamado client-custom-header.

Gorjeta

Para este exemplo, embora possamos usar o HTTPHeaderMatch de "Exact" para uma correspondência de cadeia de caracteres, uma demonstração é usada na expressão regular para ilustração de outros recursos.

kubectl apply -f - <<EOF
apiVersion: alb.networking.azure.io/v1
kind: IngressExtension
metadata:
  name: header-rewrite
  namespace: test-infra
spec:
  rules:
    - host: contoso.com
      rewrites:
        - type: RequestHeaderModifier
          requestHeaderModifier:
            set:
              - name: "user-agent"
                value: "rewritten-user-agent"
            add:
              - name: "AGC-Header-Add"
                value: "AGC-value"
            remove:
              - "client-custom-header"
EOF

Depois que o recurso IngressExtension for criado, verifique se o recurso não retorna erros de validação e é válido.

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

Verifique se o status do recurso Application Gateway for Containers foi atualizado com êxito.

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 de nome do servidor usando o comando curl, contoso.com para o FQDN de frontend, uma resposta do serviço backend-v1 será retornada.

fqdnIp=$(dig +short $fqdn)
curl -k --resolve contoso.com:80:$fqdnIp http://contoso.com

Através da resposta devemos ver:

{
 "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": [
   "dcd4bcad-ea43-4fb6-948e-a906380dcd6d"
  ]
 },
 "namespace": "test-infra",
 "ingress": "",
 "service": "",
 "pod": "backend-v1-5b8fd96959-f59mm"
}

A especificação de um cabeçalho de agente do usuário com o valor my-user-agent deve retornar uma resposta do serviço de back-end de rewritten-user-agent:

fqdnIp=$(dig +short $fqdn)
curl -k --resolve contoso.com:80:$fqdnIp http://contoso.com -H "user-agent: my-user-agent"

Através da resposta devemos ver:

{
 "path": "/",
 "host": "fabrikam.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-v1-5b8fd96959-f59mm"
}

A especificação de um client-custom-header cabeçalho com o valor moo deve ser removida da solicitação quando o Application Gateway for Containers iniciar a conexão com o serviço de back-end:

fqdnIp=$(dig +short $fqdn)
curl -k --resolve contoso.com:80:$fqdnIp http://contoso.com -H "client-custom-header: moo"

Através da resposta devemos ver:

{
 "path": "/",
 "host": "fabrikam.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": [
   "kd83nc84-4325-5d22-3d23-237dd4e3941b"
  ]
 },
 "namespace": "test-infra",
 "ingress": "",
 "service": "",
 "pod": "backend-v1-5b8fd96959-f59mm"
}

Parabéns, você instalou o ALB Controller, implantou um aplicativo de back-end e modificou os valores de cabeçalho via Ingress API no Application Gateway for Containers.

Partilhar via

Reconfiguração de cabeçalho para o Gateway de Aplicativo do Azure para Contêineres - API de Ingresso

Detalhes de utilização

Fundo

Pré-requisitos

Implantar os recursos necessários da API de ingresso

Testar o acesso à aplicação

Comentários

Recursos adicionais