Routing für Pfade, Header und Abfragezeichenfolgen mit Anwendungsgateway für Container – Gateway-API

Artikel
03/06/2024

Dieses Dokument hilft Ihnen beim Einrichten einer Beispielanwendung, die die Ressourcen aus der Gateway-API verwendet, um das Datenverkehrsrouting basierend auf URL-Pfad, Abfragezeichenfolge und Header zu veranschaulichen. Es sind Schritte für folgende Aktionen vorgesehen:

Erstellen einer Gateway-Ressource mit einem HTTPS-Listener.
Erstellen einer HTTPRoute-Ressource, die auf einen Back-End-Dienst verweist.
Verwenden Sie HTTPRouteMatch, um diese Routematches auszuführen, basierend auf Pfad, Header und Abfragezeichenfolge.

Hintergrund

Das Application Gateway für Container ermöglicht das Datenverkehrsrouting basierend auf URL-Pfad, Abfragezeichenfolge und Header. Sehen Sie sich folgendes Beispielszenario an:

Eine Abbildung des Routings für Pfade, Header und Abfragezeichenfolgen mit Application Gateway für Container.

Voraussetzungen

Wenn Sie die BYO-Bereitstellungsstrategie anwenden, stellen Sie sicher, dass Sie Ihr Application Gateway für Containerressourcen und ALB-Controller eingerichtet haben.
Beim Verfolgen der vom ALB verwalteten Bereitstellungsstrategie stellen Sie sicher, dass Sie Ihren ALB-Controller und das Application Gateway für Containerressourcen über die benutzerdefinierte ApplicationLoadBalancer-Ressourcebereitgestellt haben.
Stellen Sie eine HTTP-Beispielanwendung bereit; wenden Sie die folgende Datei "deployment.yaml" auf Ihrem Cluster an, um eine Beispielwebanwendung zur Veranschaulichung des pfad-, abfrage- und headerbasierten Routings zu erstellen.
```
kubectl apply -f https://trafficcontrollerdocs.blob.core.windows.net/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

ALB-verwaltete Bereitstellung
BYO-Bereitstellung (Bring Your Own)

Erstellen eines Gateways:

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1beta1
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.

Legen Sie die folgenden Umgebungsvariablen fest.

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'

Erstellen eines Gateways

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: gateway-01
  namespace: test-infra
  annotations:
    alb.networking.azure.io/alb-id: $RESOURCE_ID
spec:
  gatewayClassName: azure-alb-external
  listeners:
  - name: http-listener
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: Same
  addresses:
  - type: alb.networking.azure.io/alb-frontend
    value: $FRONTEND_NAME
EOF

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 Gateway-Erstellung.

status:
  addresses:
  - type: Hostname
    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, um zwei verschiedene Übereinstimmungen und einen Standarddienst zu definieren, an die der Datenverkehr weitergeleitet werden soll.

Die Art und Weise, wie die folgenden Regeln gelesen werden, sind wie folgt:

Beim Pfad /bar Weiterleitung des Datenverkehrs an den Back-End-v2-Dienst am Port 8080 ODER
Wenn die Anforderung einen HTTP-Header mit dem Namen magic und dem Wert foo, die URL eine Abfragezeichenfolge enthält, die den Namen mit einem Beispielwert gut definiert UND der Pfad /some/thing ist, wird die Anforderung an Back-End-v2 an Port 8080 gesendet.
Sonst werden alle anderen Anforderungen an den Back-End-v1-Dienst am Port 8080 weitergeleitet.

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: http-route
  namespace: test-infra
spec:
  parentRefs:
  - name: gateway-01
    namespace: test-infra
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /bar
    backendRefs:
    - name: backend-v2
      port: 8080
  - matches:
    - headers:
      - type: Exact
        name: magic
        value: foo
      queryParams:
      - type: Exact
        name: great
        value: example
      path:
        type: PathPrefix
        value: /some/thing
      method: GET
    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 Angenommen und die Ressource „Application Gateway für Container“ Programmiert wurde.

kubectl get httproute http-route -n test-infra -o yaml

Überprüfen Sie, ob der Status der Ressource „Application Gateway für Container“ 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 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 gateway gateway-01 -n test-infra -o jsonpath='{.status.addresses[0].value}')

Mithilfe des Curl-Befehls können wir drei verschiedene Szenarien überprüfen:

Routing auf Pfadbasis

In diesem Szenario wird die an http://frontend-fqdn/bar gesendete Clientanforderung an den Back-End-v2-Dienst weitergeleitet.

Führen Sie den folgenden Befehl aus:

curl http://$fqdn/bar

Beachten Sie, dass der Container, der die Anforderung bedient, back-end-v2 ist.

In diesem Szenario wird die Clientanforderung, die mit einem Headerschlüssel/Wertteil von "magic: foo" an http://frontend-fqdn/some/thing?great=example gesendet wird, an den Back-End-v2-Dienst weitergeleitet.

Führen Sie den folgenden Befehl aus:

curl http://$fqdn/some/thing?great=example -H "magic: foo"

Beachten Sie, dass der Container, der die Anforderung bedient, back-end-v2 ist.

Standardroute

Wenn keines der ersten beiden Szenarien erfüllt ist, leitet das Application Gateway für Container alle anderen Anforderungen an den Back-End-v1-Dienst weiter.

Führen Sie den folgenden Befehl aus:

curl http://$fqdn/

Beachten Sie, dass der Container, der die Anforderung bedient, back-end-v1 ist.

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

Share via

Routing für Pfade, Header und Abfragezeichenfolgen mit Anwendungsgateway für Container – Gateway-API

Hintergrund

Voraussetzungen

Bereitstellen der erforderlichen Gateway-API-Ressourcen

Testen des Zugriffs auf die Anwendung

Routing auf Pfadbasis

Abfragezeichenfolge + Header + Pfadrouting

Standardroute

Zusätzliche Ressourcen