Erneutes generieren der URL für Application Gateway für Container – Gateway-API

Artikel
11/05/2024

Application Gateway für Container ermöglicht es Ihnen, die URL einer Clientanforderung erneut zu generieren, einschließlich des Hostnamens und/oder des Pfads der Anforderungen. Wenn Application Gateway für Container die Anforderung an das Back-End-Ziel initiiert, enthält die Anforderung die neu generierte URL, um die Anforderung zu initiieren.

Nutzungsdetails

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

Hintergrund

Das URL-Rewrite ermöglicht es Ihnen, eine eingehende Anforderung in eine andere URL zu übersetzen, wenn sie in ein Back-End-Ziel initiiert wird.

Die folgende Abbildung zeigt ein Beispiel für eine Anforderung, die für contoso.com/shop bestimmt ist und in contoso.com/ecommerce umgeschrieben wird. Die Anforderung wird vom Anwendungsgateway für Container an das Back-End-Ziel initiiert:

Voraussetzungen

Wenn Sie der BYO-Bereitstellungsstrategie folgen, müssen Sie Ihre Application Gateway für Container-Ressourcen und den ALB-Controller einrichten.
Wenn Sie der Strategie der durch ALB verwalteten Bereitstellung folgen, müssen Sie den ALB-Controller und die Application Gateway für Container-Ressourcen über die benutzerdefinierte ApplicationLoadBalancer-Ressource bereitstellen.
Bereitstellen einer HTTP-Beispielanwendung:

Wenden Sie die folgende Datei „deployment.yaml“ auf Ihrem Cluster an, um eine Beispielwebanwendung zu erstellen, um die Datenverkehrsteilung / gewichtete Roundrobin-Unterstützung zu veranschaulichen.
```
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

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

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.

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/v1
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 Gatewayerstellung.

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-Ressource für contoso.com. In diesem Beispiel wird sichergestellt, dass der Datenverkehr, der an contoso.com/shop gesendet wird, als contoso.com/ecommerce an das Back-End-Ziel initiiert wird.

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: rewrite-example
  namespace: test-infra
spec:
  parentRefs:
  - name: gateway-01
  hostnames:
  - "contoso.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /shop
      filters:
        - type: URLRewrite
          urlRewrite:
            path:
              type: ReplacePrefixMatch
              replacePrefixMatch: /ecommerce
      backendRefs:
        - name: backend-v1
          port: 8080
    - backendRefs:
        - name: backend-v2
          port: 8080
EOF

Wenn die HTTPRoute-Ressource erstellt wird, stellen Sie sicher, dass sowohl HTTPRoute-Ressourcen akzeptiert als auch die Application Gateway für Container-Ressource programmiert sind.

kubectl get httproute rewrite-example -n test-infra -o yaml

Überprüfen Sie, ob die Application Gateway for Containers-Ressource für jede HTTPRoute 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}')

Wenn Sie den Servernamensindikator mit dem Befehl curl angeben, sollte contoso.com/shop eine Antwort vom Back-End-v1-Dienst zurückgeben, in welcher der angeforderte Pfad zum Back-End-Ziel als contoso.com/ecommerce angezeigt wird.

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

Über die Antwort sollten wir Folgendes sehen:

{
 "path": "/ecommerce",
 "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"
}

Wenn Sie den Servernamenindikator mithilfe des Curl-Befehls angeben, sollte contoso.com eine Antwort vom Back-End-v2-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": [
   "adae8cc1-8030-4d95-9e05-237dd4e3941b"
  ]
 },
 "namespace": "test-infra",
 "ingress": "",
 "service": "",
 "pod": "backend-v2-594bd59865-ppv9w"
}

Herzlichen Glückwunsch, Sie haben ALB Controller installiert und eine Back-End-Anwendung mit Filterung bereitgestellt, um die vom Client angeforderte URL umzuschreiben. Das Ziel in Application Gateway für Container ist bereit, Datenverkehr zu empfangen.

Freigeben über