Riscrittura dell'URL per il Gateway applicativo per contenitori di Azure - API gateway (anteprima)

Articolo
05/08/2024

Il Gateway applicativo per contenitori consente di riscrivere l'URL di una richiesta client, incluso il nome host e/o il percorso delle richieste. Quando il Gateway applicativo per contenitori avvia la richiesta alla destinazione back-end, la richiesta contiene l'URL appena riscritto per avviare la richiesta.

Usage details (Dettagli di utilizzo)

Le riscritture degli URL sfruttano i filtri definiti dall'API gateway Kubernetes.

Background

La riscrittura URL consente di convertire una richiesta in ingresso in un URL diverso quando viene avviata in una destinazione back-end.

Nella figura seguente viene illustrato un esempio di richiesta destinata a contoso.com/shop riscritta in contoso.com/ecommerce. La richiesta viene avviata alla destinazione back-end dal Gateway applicativo per contenitori:

Prerequisiti

Importante

Il Gateway applicativo per contenitori è attualmente disponibile in ANTEPRIMA.
Vedere le condizioni per l'utilizzo supplementari per le anteprime di Microsoft Azure per termini legali aggiuntivi che si applicano a funzionalità di Azure in versione beta, in anteprima o in altro modo non ancora disponibili a livello generale.

Se si segue la strategia di distribuzione personalizzata (Bring Your Own Deployment), assicurarsi di aver configurato le risorse Gateway applicativo per contenitori e il controller ALB
Se si segue la strategia di distribuzione gestita di ALB, assicurarsi di aver effettuato il provisioning del controller ALB e che sia stato effettuato il provisioning delle risorse Gateway applicativo per contenitori tramite la risorsa personalizzata ApplicationLoadBalancer.
Distribuire l'applicazione HTTP di esempio Applicare il file deployment.yaml seguente nel cluster per creare un'applicazione Web di esempio per illustrare il percorso, la query e il routing basato sull'intestazione.

kubectl apply -f https://trafficcontrollerdocs.blob.core.windows.net/examples/traffic-split-scenario/deployment.yaml

Questo comando crea quanto segue nel cluster:

uno spazio dei nomi denominato test-infra
due servizi denominati backend-v1 e backend-v2 nello spazio dei nomi test-infra
due distribuzioni denominate backend-v1 e backend-v2 nello spazio dei nomi test-infra

Distribuire le risorse necessarie per l'API gateway

Distribuzione gestita di ALB
Distribuzione personalizzata (Bring Your Own Deployment)

Creare un gateway

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

Nota

Quando il controller ALB crea le risorse Gateway applicativo per contenitori in ARM, usa la convenzione di denominazione seguente per una risorsa front-end: fe-<8 caratteri generati in modo casuale>

Se si vuole modificare il nome del front-end creato in Azure, valutare la possibilità di seguire la strategia di distribuzione personalizzata (Bring Your Own Deployment).

Impostare le variabili di ambiente seguenti

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='test-frontend'

Creare un gateway

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

Dopo aver creato la risorsa gateway, verificare che lo stato sia valido, che il listener sia Programmato e che al gateway sia assegnato un indirizzo.

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

Output di esempio della corretta creazione del gateway.

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

Dopo aver creato il gateway, creare una risorsa HTTPRoute per contoso.com. Questo esempio garantisce che il traffico inviato a contoso.com/shop venga avviato come contoso.com/ecommerce alla destinazione back-end.

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

Dopo aver creato la risorsa HTTPRoute, verificare che la risorsa HTTPRoute mostri Accettato e che lo stato della risorsa Gateway applicativo per contenitori sia Programmato.

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

Verificare che lo stato della risorsa Gateway applicativo per contenitori sia stato aggiornato correttamente per ogni HTTPRoute.

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

Testare l'accesso all'applicazione

A questo punto, è possibile inviare traffico all'applicazione di esempio tramite il nome di dominio completo assegnato al front-end. Usare il comando seguente per ottenere il nome di dominio completo.

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

Se si specifica l'indicatore del nome del server usando il comando curl, contoso.com/shop deve restituire una risposta dal servizio back-end-v1 con il percorso richiesto alla destinazione back-end che mostra contoso.com/ecommerce.

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

Tramite la risposta si osserverà quanto segue:

{
 "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"
}

Se si specifica l'indicatore del nome del server usando il comando curl, contoso.com deve restituire una risposta dal servizio back-end-v2.

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