Freigeben über


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

Mit Application Gateway für 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 für 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 für Container an das Back-End-Ziel initiiert wird:

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

Voraussetzungen

  1. Wenn Sie die BYO-Bereitstellungsstrategie anwenden, stellen Sie sicher, dass Sie Ihr Application Gateway für Containerressourcen und ALB-Controller eingerichtet haben.

  2. Wenn Sie die vom ALB verwaltete Bereitstellungsstrategie ausführen, stellen Sie sicher, dass Sie Ihren ALB-Controller bereitgestellt und das Application Gateway für Containerressourcen über die benutzerdefinierte ApplicationLoadBalancer-Ressource 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 die Application Gateway für Container-Ressourcen in ARM erstellt, verwendet er die folgende Benennungskonvention für eine Frontend-Ressource: „fe-<8 zufällig generierte Zeichen>“.

Wenn Sie den Namen des in Azure erstellten Frontends ändern möchten, sollten Sie die BYO-Bereitstellungsstrategie (Bring Your Own) befolgen.

Nachdem die eingehende Ressource 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.

Tipp

In diesem Beispiel können wir zwar den HTTPHeaderMatch „Genau“ für eine Zeichenkettenübereinstimmung verwenden, dennoch wird eine Demonstration in regulären Ausdrücken zur Illustration weiterer Fähigkeiten verwendet.

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

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 wir über den FQDN, der dem Frontend zugewiesen ist, einige Datenverkehrsdaten an unsere 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 Front-End-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 für 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 für Container bereitgestellt.