Condividi tramite

Riscrittura URL per il Gateway applicativo di Azure per contenitori - API in ingresso

  • Articolo

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 URL sfruttano la risorsa personalizzata IngressExtension del Gateway applicativo per contenitori.

Background

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

La figura seguente illustra una richiesta destinata a contoso.com/shop da riscrivere in contoso.com/ecommerce quando la richiesta viene avviata alla destinazione back-end dal Gateway applicativo per contenitori:

Diagramma che mostra il gateway applicativo per contenitori che riscrive un URL nel back-end.

Prerequisiti

  1. Se si segue la strategia di distribuzione personalizzata BYO (Bring Your Own), assicurarsi di configurare le risorse del Gateway applicativo per contenitori e il controller ALB.
  2. Se si segue la strategia di distribuzione gestita di ALB, assicurarsi di effettuare il provisioning del controller ALB e delle risorse del Gateway applicativo per contenitori tramite la risorsa personalizzata ApplicationLoadBalancer.
  3. Distribuire un'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://raw.githubusercontent.com/MicrosoftDocs/azure-docs/refs/heads/main/articles/application-gateway/for-containers/examples/traffic-split-scenario/deployment.yaml

Questo comando crea gli elementi seguenti 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 dell'API in ingresso necessarie

  1. Creare una risorsa In ingresso per intercettare tutto il traffico e instradarlo verso back-end-v2
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
  1. Creare una risorsa In ingresso che corrisponda al prefisso /shop per instradare a backend-v1
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

Nota

Quando il Controller ALB crea le risorse Gateway applicativo per contenitori in ARM, userà 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).

Quando tutte le risorse in ingresso sono state create, verificare che lo stato sia valido, che il listener sia programmato e che venga assegnato un indirizzo al gateway.

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

Output di esempio di una delle risorse in ingresso.

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

Quando viene creata la risorsa in ingresso, creare una risorsa IngressExtension 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: 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

Quando viene creata la risorsa IngressExtension, verificare che la risorsa IngressExtension sia accettata e che il Gateway applicativo per le risorse contenitori sia programmata.

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

Verificare che il Gateway applicativo per le risorse contenitori sia stato aggiornato correttamente per IngressExtension.

Testare l'accesso all'applicazione

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

fqdn=$(kubectl get ingress ingress-01 -n test-infra -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')

Se si specifica l'indicatore contoso.com/shop del nome del server usando il comando curl, viene restituita 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 dovrebbe vedere:

{
 "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 contoso.com del nome del server usando il comando curl, viene restituita una risposta dal servizio back-end-v2, come illustrato.

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

Verrà visualizzata la risposta seguente:

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

Congratulazioni, è stato installato ALB Controller, è stata distribuita un'applicazione back-end ed è stato usato IngressExtension per riscrivere l'URL richiesto dal client, prima che il traffico sia impostato sulla destinazione nel Gateway applicativo per contenitori.