Partager via

Chemin d’accès, en-tête et routage des chaînes de requête avec Passerelle d’application pour conteneurs – API Passerelle

Ce document vous aide à configurer un exemple d’application qui utilise les ressources de l’API de passerelle pour illustrer le routage du trafic en fonction du chemin d’URL, de la chaîne de requête et de l’en-tête. Les étapes sont fournies pour :

  • Créez une ressource de passerelle avec un écouteur HTTPS.
  • Créer une ressource HTTPRoute qui fait référence à un service principal.
  • Utilisez HTTPRouteMatch pour effectuer matches cette route en fonction du chemin, de l’en-tête et de la chaîne de requête.

Contexte

Application Gateway pour conteneurs active le routage du trafic en fonction du chemin d’URL, de la chaîne de requête et de l’en-tête. Consultez l’exemple de scénario suivant :

Figure montrant le routage du chemin, de l’en-tête et de la chaîne de requête avec la passerelle d’application pour conteneurs.

Conditions préalables

  1. Si vous suivez la stratégie de déploiement BYO, assurez-vous d’avoir configuré vos ressources Application Gateway for Containers et ALB Controller

  2. Si vous suivez la stratégie de déploiement managé ALB, vérifiez que vous avez provisionné votre contrôleur ALB ainsi que les ressources Passerelle d’application pour conteneurs via la ressource personnalisée ApplicationLoadBalancer.

  3. Déployer un exemple d’application HTTP Appliquez le fichier deployment.yaml suivant sur votre cluster pour créer un exemple d’application web pour illustrer le chemin d’accès, la requête et le routage basé sur l’en-tête.

    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

Créez une passerelle :

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

Remarque

Lorsque le contrôleur ALB crée les ressources Passerelle d’application pour conteneurs dans Azure Resource Manager, il utilise la convention d’affectation de noms suivante pour une ressource front-end : fe-<eight randomly generated characters>

Si vous souhaitez modifier le nom de la ressource front-end créée dans Azure, envisagez de suivre la stratégie Apportez votre propre déploiement.

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 d’une création réussie de 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 un itinéraire HTTPRoute pour définir deux correspondances différentes et un service par défaut vers lequel acheminer le trafic.

La façon dont les règles suivantes lisent sont les suivantes :

  1. Si le chemin d’accès est /bar, le trafic est acheminé vers le service backend-v2 sur le port 8080 OR
  2. Si la requête contient un en-tête HTTP portant le nom magic et la valeur foo, l’URL contient une chaîne de requête définissant le nom avec une valeur d’exemple, ET le chemin d’accès est /some/thing, la requête est envoyée à backend-v2 sur le port 8080.
  3. Sinon, toutes les autres requêtes sont acheminées vers le service backend-v1 sur le port 8080.
kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: http-route
  namespace: test-infra
spec:
  parentRefs:
  - name: gateway-01
    namespace: test-infra
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /bar
    backendRefs:
    - name: backend-v2
      port: 8080
  - matches:
    - headers:
      - type: Exact
        name: magic
        value: foo
      queryParams:
      - type: Exact
        name: great
        value: example
      path:
        type: PathPrefix
        value: /some/thing
      method: GET
    backendRefs:
    - name: backend-v2
      port: 8080
  - backendRefs:
    - name: backend-v1
      port: 8080
EOF

Conseil / Astuce

Passerelle d’application pour conteneurs prend en charge la mise en correspondance d’expressions régulières pour headers, queryParams, et path utilisant la syntaxe RE2. Vous trouverez plus d’informations dans la spécification de l’API de passerelle.

Une fois la ressource HTTPRoute créée, vérifiez que l’itinéraire a été accepté et que la ressource Application Gateway pour conteneurs a été programmée.

kubectl get httproute http-route -n test-infra -o yaml

Vérifiez que l’état de la ressource Passerelle d’application pour conteneurs a été correctement mis à jour.

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 vers notre exemple d’application, via le FQDN attribué 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}')

À l’aide de la commande curl, nous pouvons valider trois scénarios différents :

Routage basé sur le chemin

Dans ce scénario, la demande cliente envoyée à http://frontend-fqdn/bar est acheminée vers le service backend-v2.

Exécutez la commande suivante:

curl http://$fqdn/bar

Notez que le conteneur qui sert la requête est backend-v2.

Chaîne de requête + en-tête + routage du chemin d’accès

Dans ce scénario, la demande cliente envoyée à http://frontend-fqdn/some/thing?great=example avec une partie clé/valeur d’en-tête de « magic : foo » est acheminée vers le service backend-v2.

Exécutez la commande suivante:

curl http://$fqdn/some/thing?great=example -H "magic: foo"

Notez que le conteneur qui sert la requête est backend-v2.

Itinéraire par défaut

Si aucun des deux premiers scénarios n’est satisfait, Application Gateway pour conteneurs achemine toutes les autres requêtes vers le service backend-v1.

Exécutez la commande suivante:

curl http://$fqdn/

Notez que le conteneur qui sert la requête est backend-v1.

Félicitations, vous avez installé le contrôleur ALB, déployé une application back-end et routé le trafic vers l’application via l’API Gateway sur Application Gateway pour conteneurs.

  • Last updated on