Freigeben über

Headerumschreibung für Application Gateway für Container – Gateway-API

  • Artikel

Mit Application Gateway für Container können Sie HTTP-Header von Clientanforderungen und -antworten von Back-End-Zielen umschreiben.

Nutzungsdetails

Headerumschreibungen benutzen Filter, die von der Kubernetes-Gateway-API definiert sind.

Hintergrund

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

Die folgende Abbildung zeigt eine Anforderung mit einem bestimmten Benutzer-Agent, der in einen vereinfachten Wert namens SearchEngine-BingBot 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 befolgen, stellen Sie sicher, dass Sie Ihre Application Gateway für Container-Ressourcen und Ihren ALB Controller einrichten

  2. Wenn Sie die vom ALB verwaltete Bereitstellungsstrategie befolgen, stellen Sie sicher, dass dem ALB-Controller das Application Gateway für Containerressourcen über die benutzerdefinierte ApplicationLoadBalancer-Ressource bereitgestellt wird.

  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 Headerumschreibung 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 Gateway-API-Ressourcen

Erstellen eines Gateways:

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gateway-01
  namespace: test-infra
  annotations:
    alb.networking.azure.io/alb-namespace: alb-test-infra
    alb.networking.azure.io/alb-name: alb-test
spec:
  gatewayClassName: azure-alb-external
  listeners:
  - name: http-listener
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: Same
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 Gatewayressource erstellt wurde, stellen Sie sicher, dass der Status gültig ist, dass der Listener programmiert ist und dem Gateway eine Adresse zugewiesen wird.

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

Beispielausgabe einer erfolgreichen Gatewayerstellung.

status:
  addresses:
  - type: IPAddress
    value: xxxx.yyyy.alb.azure.com
  conditions:
  - lastTransitionTime: "2023-06-19T21:04:55Z"
    message: Valid Gateway
    observedGeneration: 1
    reason: Accepted
    status: "True"
    type: Accepted
  - lastTransitionTime: "2023-06-19T21:04:55Z"
    message: Application Gateway For Containers resource has been successfully updated.
    observedGeneration: 1
    reason: Programmed
    status: "True"
    type: Programmed
  listeners:
  - attachedRoutes: 0
    conditions:
    - lastTransitionTime: "2023-06-19T21:04:55Z"
      message: ""
      observedGeneration: 1
      reason: ResolvedRefs
      status: "True"
      type: ResolvedRefs
    - lastTransitionTime: "2023-06-19T21:04:55Z"
      message: Listener is accepted
      observedGeneration: 1
      reason: Accepted
      status: "True"
      type: Accepted
    - lastTransitionTime: "2023-06-19T21:04:55Z"
      message: Application Gateway For Containers resource has been successfully updated.
      observedGeneration: 1
      reason: Programmed
      status: "True"
      type: Programmed
    name: https-listener
    supportedKinds:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute

Nachdem das Gateway erstellt wurde, erstellen Sie eine HTTPRoute, die auf den Hostnamen contoso.com lauscht und den Wert des Benutzer-Agents für SearchEngine-BingBot überschreibt.

In diesem Beispiel suchen wir nach dem vom Bing-Suchmodul verwendeten Benutzer-Agent und vereinfachen den Header zu SearchEngine-BingBot für eine einfachere Back-End-Analyse.

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

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: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: header-rewrite-route
  namespace: test-infra
spec:
  parentRefs:
    - name: gateway-01
      namespace: test-infra
  hostnames:
    - "contoso.com"
  rules:
    - matches:
        - headers:
          - name: user-agent
            value: Mozilla/5\.0 AppleWebKit/537\.36 \(KHTML, like Gecko; compatible; bingbot/2\.0; \+http://www\.bing\.com/bingbot\.htm\) Chrome/
            type: RegularExpression
      filters:
        - type: RequestHeaderModifier
          requestHeaderModifier:
            set:
              - name: user-agent
                value: SearchEngine-BingBot
            add:
              - name: AGC-Header-Add
                value: AGC-value
            remove: ["client-custom-header"]
      backendRefs:
        - name: backend-v2
          port: 8080
    - backendRefs:
        - name: backend-v1
          port: 8080
EOF

Nachdem die HTTPRoute-Ressource erstellt wurde, stellen Sie sicher, dass die Route Akzeptiert ist und die Ressource „Application Gateway für Container“ programmiert ist.

kubectl get httproute header-rewrite-route -n test-infra -o yaml

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

status:
  parents:
  - conditions:
    - lastTransitionTime: "2023-06-19T22:18:23Z"
      message: ""
      observedGeneration: 1
      reason: ResolvedRefs
      status: "True"
      type: ResolvedRefs
    - lastTransitionTime: "2023-06-19T22:18:23Z"
      message: Route is Accepted
      observedGeneration: 1
      reason: Accepted
      status: "True"
      type: Accepted
    - lastTransitionTime: "2023-06-19T22:18:23Z"
      message: Application Gateway For Containers resource has been successfully updated.
      observedGeneration: 1
      reason: Programmed
      status: "True"
      type: Programmed
    controllerName: alb.networking.azure.io/alb-controller
    parentRef:
      group: gateway.networking.k8s.io
      kind: Gateway
      name: gateway-01
      namespace: test-infra

Testen des Zugriffs auf die Anwendung

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

fqdn=$(kubectl get gateway gateway-01 -n test-infra -o jsonpath='{.status.addresses[0].value}')

Wenn Sie den Server-Namensindikator mit dem curl-Befehl contoso.com für den FQDN des Frontends angeben, sollte die Ausgabe eine Antwort vom Backend-v1-Dienst zurückgeben.

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 eines Benutzer-Agent-Headers mit dem Wert `` sollte eine Antwort vom Back-End-Dienst von SearchEngine-BingBot zurückgeben:

fqdnIp=$(dig +short $fqdn)
curl -k --resolve contoso.com:80:$fqdnIp http://contoso.com -H "user-agent: Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/"

Ü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-v2-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-v2-5b8fd96959-f59mm"
}

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