URL-Neugenerierung für Application Gateway für Container – Eingangs-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 nutzen die benutzerdefinierte Ressource „IngressExtension“ des Application Gateway für Container.

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 eine Anforderung, die für contoso.com/shop neu generiert wird zu contoso.com/ecommerce, wenn die Anforderung vom Application Gateway für Container an das Back-End-Ziel initiiert wird:

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 zur Veranschaulichung des pfad-, abfrage- und headerbasierten Routings 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

Verwaltete ALB-Bereitstellung
Bringen Sie Ihre eigene (BYO) Bereitstellung mit

Erstellen eines Eingangs, der alle Datenverkehr und Routen an Back-End-v2 abfangen

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
spec:
  ingressClassName: azure-alb-external
  rules:
    - host: contoso.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: backend-v2
                port:
                  number: 8080
EOF

Erstellen eines Eingangs, der dem /shop-Präfix entspricht, das an Back-End-v1 weitergeleitet wird

kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-02
  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: url-rewrite
spec:
  ingressClassName: azure-alb-external
  rules:
    - host: contoso.com
      http:
        paths:
          - path: /shop
            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.

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 Eingangs, der alle Datenverkehr und Routen an Back-End-v2 abfangen

kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-01
  namespace: test-infra
  annotations:
    alb.networking.azure.io/alb-id: $RESOURCE_ID
    alb.networking.azure.io/alb-frontend: $FRONTEND_NAME
spec:
  ingressClassName: azure-alb-external
  rules:
    - host: contoso.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: backend-v2
                port:
                  number: 8080
EOF

Erstellen eines Eingangs, der mit dem Präfix „/shop“ übereinstimmt und zu Back-End-v1 weitergeleitet wird

kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-02
  namespace: test-infra
  annotations:
    alb.networking.azure.io/alb-id: $RESOURCE_ID
    alb.networking.azure.io/alb-frontend: $FRONTEND_NAME
    alb.networking.azure.io/alb-ingress-extension: url-rewrite
spec:
  ingressClassName: azure-alb-external
  rules:
    - host: contoso.com
      http:
        paths:
          - path: /shop
            pathType: Prefix
            backend:
              service:
                name: backend-v1
                port:
                  number: 8080
EOF

Wenn jede Eingangsressource erstellt wird, stellen Sie sicher, dass der Status gültig ist, der Listener programmiert ist und dem Gateway eine Adresse zugewiesen wird.

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

Beispielausgabe einer der Eingangsressourcen.

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"},"name"
:"ingress-01","namespace":"test-infra"},"spec":{"ingressClassName":"azure-alb-external","rules":[{"host":"contoso.com","http":{"paths":[{"backend":{"service":{"name":"backend-v2","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:
      - backend:
          service:
            name: backend-v2
            port:
              number: 8080
        path: /
        pathType: Prefix
status:
  loadBalancer:
    ingress:
    - hostname: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.fzyy.alb.azure.com
      ports:
      - port: 80
        protocol: TCP

Wenn der Eingang erstellt wird, erstellen Sie eine IngressExtension-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: alb.networking.azure.io/v1
kind: IngressExtension
metadata:
  name: url-rewrite
  namespace: test-infra
spec:
  rules:
    - host: contoso.com
      rewrites:
      - type: URLRewrite
        urlRewrite:
          path:
            type: ReplacePrefixMatch
            replacePrefixMatch: /ecommerce
EOF

Stellen Sie beim Erstellen der Ressource „IngressExtension“ sicher, dass die Ressource „IngressExtension“ als akzeptiertangezeigt wird und die Ressource „Application Gateway für Container“ programmiert ist.

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

Überprüfen Sie, ob die Ressource „Application Gateway für Container" für die IngressExtension 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 Servernamensindikator contoso.com/shop mit dem Befehl curl angeben, wird eine Antwort vom Back-End-v1-Dienst zurückgegeben, 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 contoso.com mithilfe des Curl-Befehls angeben, wird eine Antwort wie dargestellt vom Back-End-v2-Dienst zurückgegeben.

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

Die folgende Antwort sollte angezeigt werden:

{
 "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, eine Back-End-Anwendung bereitgestellt und die IngressExtension verwendet, um die angeforderte URL des Clients neu zu generieren, bevor der Datenverkehr auf das Ziel für Application Gateway für Container festgelegt wird.

Freigeben über