Kopfzeilenumschreibung für Azure Application Gateway for Container – Eingehende API

Mit Application Gateway for Container können Sie HTTP-Kopfzeilen von Clientanforderungen und -antworten von Back-End-Zielen erneut generieren.

Nutzungsdetails

Kopfzeilenumschreibungen nutzen die Vorteile der benutzerdefinierten Ressource „IngressExtension“ des Application Gateway for Container.

Hintergrund

Kopfzeilenumschreibungen ermöglichen es Ihnen, die Anforderungs- und Antwortkopfzeilen in und von Ihren Back-End-Zielen zu ändern.

Die folgende Abbildung zeigt ein Beispiel für eine Anforderung mit einem bestimmten Benutzer-Agent, der in einen vereinfachten Wert namens rewritten-user-agent umgeschrieben wird, wenn die Anforderung vom Application Gateway for Container an das Back-End-Ziel initiiert wird:

Ein Diagramm, das zeigt, wie das Application Gateway for Container einen Anforderungsheader an das Back-End umschreibt.

Voraussetzungen

  1. Wenn Sie die BYO-Bereitstellungsstrategie ausführen, stellen Sie sicher, dass Sie Ihr Anwendungsgateway für Containerressourcen und ALB Controller (Add-On oder Helm) eingerichtet haben.

  2. Wenn Sie die vom ALB verwaltete Bereitstellungsstrategie ausführen, stellen Sie sicher, dass Sie Ihren ALB-Controller (Add-On oder Helm) bereitgestellt und das Anwendungsgateway für Containerressourcen über die benutzerdefinierte Ressource ApplicationLoadBalancer bereitgestellt haben.

  3. Stellen Sie eine Beispiel-HTTP-Anwendung bereit, wenden Sie die folgende Datei „deployment.yaml“ auf Ihrem Cluster an, um eine Beispielwebanwendung zum Veranschaulichen der Kopfzeilenumschreibung zu erstellen.

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

    Mit diesem Befehl wird Folgendes in Ihrem Cluster erstellt:

    • ein Namespace namens test-infra
    • Zwei Dienste namens backend-v1 und backend-v2 im test-infra-Namespace
    • Zwei Bereitstellungen namens backend-v1 und backend-v2 im test-infra-Namespace

Bereitstellen der erforderlichen Ingress-API-Ressourcen

Erstellen Sie eine eingehende Ressource, um auf Anforderungen an contoso.com zu lauschen:

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

Hinweis

Wenn der ALB-Controller das Anwendungsgateway für Containerressourcen in Azure Resource Manager erstellt, verwendet er die folgende Benennungskonvention für eine Frontend-Ressource: fe-<eight randomly generated characters>

Wenn Sie den Namen der in Azure erstellten Frontend-Ressource ändern möchten, sollten Sie die Bring-Your-Own-Bereitstellungsstrategie beachten.

Nachdem die Eingangsressource erstellt wurde, stellen Sie sicher, dass der Status den Hostnamen Ihres Lastenausgleichs anzeigt und dass beide Ports auf Anforderungen lauschen.

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

Beispielausgabe einer erfolgreichen Eingangserstellung.

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

Nachdem der Eingang erstellt wurde, müssen wir als Nächstes eine IngressExtension mit den Regeln zum erneuten Generieren von Kopfzeilen definieren.

In diesem Beispiel wird ein statischer Benutzer-Agent mit dem Wert rewritten-user-agent festgelegt.

In diesem Beispiel wird auch das Hinzufügen einer neuen Kopfzeile namens AGC-Header-Add mit einem Wert von AGC-value veranschaulicht und entfernt einen Anforderungsheader namens client-custom-header.

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

Hinweis

Das Ändern der Host Kopfzeile wird mit einer requestHeaderModifier Regel nicht unterstützt. Verwenden Sie einen Host, um den für das Back-End-Ziel angegebenen Wert außer Kraft zu setzen.

Nachdem die IngressExtension-Ressource erstellt wurde, stellen Sie sicher, dass die Ressource Keine Überprüfungsfehler zurückgibt und gültig ist.

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

Überprüfen Sie, ob der Status der Ressource „Application Gateway for Containers“ erfolgreich aktualisiert wurde.

Testen des Zugriffs auf die Anwendung

Jetzt können Sie über den FQDN, der dem Frontend zugewiesen ist, Datenverkehr an die Beispielanwendung senden. Verwenden Sie den folgenden Befehl, um den FQDN abzurufen.

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

Wenn Sie den Servernamen-Indikator mithilfe des curl-Befehls angeben, contoso.com wird für den Frontend-FQDN eine Antwort des Back-End-v1-Diensts zurückgegeben.

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

Über die Antwort sollten wir Folgendes sehen:

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

Die Angabe einer Benutzer-Agent-Kopfzeile mit dem Wert my-user-agent sollte eine Antwort rewritten-user-agent vom Back-End-Dienst zurückgeben:

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

Über die Antwort sollten wir Folgendes sehen:

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

Die Angabe eines client-custom-header-Headers mit dem Wert moo sollte von der Anforderung entfernt werden, wenn das Application Gateway for Container die Verbindung mit dem Back-End-Dienst initiiert:

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

Über die Antwort sollten wir Folgendes sehen:

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

Herzlichen Glückwunsch, Sie haben ALB Controller installiert, eine Back-End-Anwendung bereitgestellt und die Headerwerte über die Ingress API auf Application Gateway for Container bereitgestellt.

  • Last updated on