Réécriture d’URL pour Passerelle d'application pour conteneurs : API de passerelle

Article
11/11/2024

Passerelle d'application pour conteneurs vous permet de réécrire l’URL d’une requête de client, y compris le nom d’hôte et/ou le chemin d’accès des requêtes. Lorsque Passerelle d'application pour conteneurs lance la requête vers la cible back-end, la requête contient l’URL nouvellement réécrite pour lancer la requête.

Usage details

Les réécritures d’URL tirent parti des filtres définis par l’API de passerelle Kubernetes.

Background

La réécriture d’URL vous permet de traduire une requête entrante en une autre URL lorsqu’elle est lancée vers une cible back-end.

La figure suivante illustre un exemple de requête destinée à contoso.com/shop, réécrite pour devenir contoso.com/ecommerce. La requête est lancée sur la cible principale par Passerelle d'application pour conteneurs :

Prérequis

Si vous suivez la stratégie de déploiement BYO, veillez à configurer vos ressources de Passerelle d’application pour conteneurs et le contrôleur ALB.
Si vous suivez la stratégie de déploiement managé ALB, veillez à approvisionner votre contrôleur ALB et les ressources de Passerelle d’application pour conteneurs via la ressource personnalisée ApplicationLoadBalancer.
Déployez un exemple d’application HTTP :

Appliquez le fichier deployment.yaml suivant sur votre cluster pour créer un exemple d’application web afin de démontrer la prise en charge du fractionnement / tourniquet (round robin) pondéré du trafic.
```
kubectl apply -f https://raw.githubusercontent.com/MicrosoftDocs/azure-docs/refs/heads/main/articles/application-gateway/for-containers/examples/traffic-split-scenario/deployment.yaml
```
Cette commande crée les éléments suivants sur votre cluster :
- Un espace de noms nommé test-infra
- Deux services nommés backend-v1 et backend-v2 dans l’espace de noms test-infra
- Deux déploiements nommés backend-v1 et backend-v2 dans l’espace de noms test-infra

Déployer les ressources d’API de passerelle requises

Déploiement managé ALB
Apportez votre propre déploiement BYO

Créer une passerelle

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

Remarque

Lorsque le contrôleur ALB crée les ressources Passerelle d’application pour conteneurs dans ARM, il utilise la convention de dénomination suivante pour une ressource front-end : fe-<8 caractères générés aléatoirement>

Si vous souhaitez modifier le nom du front-end créé dans Azure, il peut être préférable de suivre la stratégie de déploiement BYO.

Définir les variables d’environnement suivantes

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'

Créer une passerelle

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

Une fois la ressource de passerelle créée, vérifiez que l’état est valide, que l’écouteur est programmé et qu’une adresse est affectée à la passerelle.

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

Exemple de sortie de la création réussie de la passerelle.

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

Une fois la passerelle créée, créez une ressource HTTPRoute pour contoso.com. Cet exemple garantit que le trafic envoyé à contoso.com/shop est lancé en tant que contoso.com/ecommerce à la cible back-end.

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

Une fois la ressource HTTPRoute créée, vérifiez que les la ressource HTTPRoute affiche Acceptée et que la ressource Passerelle d'application pour conteneurs est Programmée.

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

Vérifiez que l’état de la ressource Passerelle d'application pour conteneurs est correctement mis à jour pour chaque 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

Tester l’accès à l’application

Nous sommes maintenant prêts à envoyer du trafic à notre exemple d’application, via le nom de domaine complet affecté au front-end. Utilisez la commande suivante pour obtenir le nom de domaine complet.

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

Lorsque vous spécifiez l’indicateur de nom du serveur à l’aide de la commande curl, contoso.com/shop doit renvoyer une réponse du service backend-v1 avec le chemin d’accès demandé à la cible back-end affichant contoso.com/ecommerce.

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

Par le biais de la réponse, nous devrions voir :

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

Lorsque vous spécifiez l’indicateur de nom du serveur à l’aide de la commande curl, contoso.com doit retourner une réponse du service backend-v2.

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

Par le biais de la réponse, nous devrions voir :

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

Félicitations, vous avez installé ALB Controller et déployé une application backend qui inclut le filtrage pour réécrire l'URL demandée par le client. La cible sur Application Gateway for Containers est prête à recevoir du trafic.

Partager via