Condividi tramite

Riscrittura intestazioni per il Gateway applicativo per contenitori di Azure - API in ingresso

  • Articolo

Gateway applicativo per contenitori consente di riscrivere le intestazioni HTTP delle richieste client e delle risposte dalle destinazioni back-end.

Usage details (Dettagli di utilizzo)

Le riscritture delle intestazioni sfruttano la risorsa personalizzata IngressExtension del Gateway applicativo per contenitori.

Background

Le riscritture delle intestazioni consentono di modificare le intestazioni di richiesta e risposta da e verso le destinazioni back-end.

La figura seguente illustra un esempio di richiesta con un agente utente specifico riscritto in un valore semplificato denominato rewritten-user-agent quando la richiesta viene avviata alla destinazione back-end dal Gateway applicativo per contenitori:

Diagramma che mostra il gateway applicazione per Contenitori che riscrive un'intestazione di richiesta nel back-end.

Prerequisiti

  1. Se si segue la strategia di distribuzione personalizzata BYO (Bring Your Own), assicurarsi di aver configurato le risorse del Gateway applicativo per contenitori e il controller ALB

  2. Se si segue la strategia di distribuzione gestita di ALB, assicurarsi di aver effettuato il provisioning del controller ALB e delle risorse Gateway applicativo per contenitori tramite la risorsa personalizzata ApplicationLoadBalancer.

  3. Distribuire l'applicazione HTTP di esempio Applicare il file deployment.yaml seguente nel cluster per creare un'applicazione Web di esempio per illustrare la riscrittura delle intestazioni.

    kubectl apply -f https://raw.githubusercontent.com/MicrosoftDocs/azure-docs/refs/heads/main/articles/application-gateway/for-containers/examples/traffic-split-scenario/deployment.yaml

    Questo comando crea gli elementi seguenti nel cluster:

    • uno spazio dei nomi denominato test-infra
    • due servizi denominati backend-v1 e backend-v2 nello spazio dei nomi test-infra
    • due distribuzioni chiamate backend-v1 e backend-v2 nello test-infraspazio dei nomi

Distribuire le risorse dell'API in ingresso necessarie

Creare una risorsa in ingresso per l'ascolto delle richieste a 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 il Controller ALB crea le risorse Gateway applicativo per contenitori in ARM, userà la convenzione di denominazione seguente per una risorsa front-end: fe-<8 caratteri generati in modo casuale>

Se si vuole modificare il nome del front-end creato in Azure, valutare la possibilità di seguire la strategia di distribuzione personalizzata (Bring Your Own Deployment).

Dopo aver creato la risorsa in ingresso, verificare che lo stato mostri il nome host del servizio di bilanciamento del carico e che entrambe le porte siano in ascolto per le richieste.

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

Output di esempio della corretta creazione della risorsa in ingresso.

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

Dopo aver creato la risorsa in ingresso, è necessario definire la risorsa IngressExtension con le regole di riscrittura delle intestazioni.

In questo esempio viene impostato un agente utente statico con un valore di rewritten-user-agent.

Questo esempio illustra anche l'aggiunta di una nuova intestazione denominata AGC-Header-Add con un valore di AGC-value e la rimozione di un'intestazione della richiesta denominata client-custom-header.

Suggerimento

Per questo esempio, mentre è possibile usare HTTPHeaderMatch con il valore "Exact" per una corrispondenza di stringa, viene dimostrato l'uso di un'espressione regolare per illustrare ulteriori funzionalità.

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

Dopo aver creato la risorsa IngressExtension, verificare che la risorsa restituisca Nessun errore di convalida ed è valida.

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

Verificare che l'aggiornamento dello stato della risorsa Gateway applicativo per contenitori sia riuscito.

Testare l'accesso all'applicazione

A questo punto, è possibile inviare traffico all'applicazione di esempio tramite l’FQDN assegnato al front-end. Usare il comando seguente per ottenere il nome di dominio completo.

fqdn=$(kubectl get ingress ingress-01 -n test-infra -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')

Se si specifica l'indicatore del nome del server usando il comando curl, contoso.com per il nome di dominio completo del front-end, viene restituita una risposta dal servizio backend-v1.

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

Tramite la risposta si osserverà quanto segue:

{
 "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"
}

Se si specifica un'intestazione dell'agente utente con il valore my-user-agent, il servizio back-end restituirà la risposta rewritten-user-agent:

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

Tramite la risposta si osserverà quanto segue:

{
 "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"
}

Specificare un'intestazione client-custom-header con il valore moo deve essere rimossa dalla richiesta quando gateway applicazione per contenitori avvia la connessione al servizio back-end:

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

Tramite la risposta si osserverà quanto segue:

{
 "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"
}

È stato installato al controller ALB, è stata distribuita un'applicazione back-end e sono stati modificati i valori di intestazione tramite l'API In ingresso in gateway applicazione per contenitori.