Partager via

Réécriture d’en-tête pour Passerelle d’application pour conteneurs – API d’entrée

  • Article

Passerelle d’application pour conteneurs vous permet de réécrire les en-têtes HTTP des requêtes et réponses du client à partir de cibles back-end.

Usage details

Les réécritures d’en-tête tirent parti de la ressource personnalisée IngressExtension de Passerelle d’application pour conteneurs.

Background

Les réécritures d’en-tête vous permettent de modifier les en-têtes de requête et de réponse vers et à partir de vos cibles back-end.

La figure suivante illustre un exemple de réécriture d’une requête avec un agent utilisateur spécifique en une valeur simplifiée nommée rewritten-user-agent lorsque la requête est lancée sur la cible back-end par Passerelle d’application pour conteneurs :

Diagramme montrant la réécriture par la passerelle d'application pour conteneurs d'un en-tête de requête vers le backend.

Prérequis

  1. Si vous suivez la stratégie de déploiement BYO, vérifiez que vous avez configuré vos ressources Passerelle d’application pour conteneurs et le contrôleur ALB

  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 afin d’illustrer la réécriture d’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 appelés backend-v1 et backend-v2 dans l’espace de noms test-infra

Déployer les ressources d’API d’entrée requises

Créez une ressource d’entrée pour écouter les requêtes à contoso.com :

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
    alb.networking.azure.io/alb-ingress-extension: header-rewrite
spec:
  ingressClassName: azure-alb-external
  rules:
    - host: contoso.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: backend-v1
                port:
                  number: 8080
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.

Une fois la ressource d’entrée créée, vérifiez que l’état indique le nom d’hôte de votre équilibreur de charge et que les deux ports écoutent les requêtes.

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

Exemple de sortie de création d’entrée réussie.

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

Une fois l’entrée créée, nous devons ensuite définir une ingressExtension avec les règles de réécriture d’en-tête.

Dans cet exemple, nous définissons un agent utilisateur statique avec la valeur rewritten-user-agent.

Cet exemple illustre également l’ajout d’un nouvel en-tête nommé AGC-Header-Add avec une valeur AGC-value, et supprime un en-tête de requête nommé client-custom-header.

Conseil

Pour cet exemple, bien que nous puissions utiliser le HTTPHeaderMatch « Exact » pour une correspondance de chaîne, une démonstration est utilisée dans l’expression régulière à des fins d’illustration de capacités supplémentaires.

kubectl apply -f - <<EOF
apiVersion: alb.networking.azure.io/v1
kind: IngressExtension
metadata:
  name: header-rewrite
  namespace: test-infra
spec:
  rules:
    - host: contoso.com
      rewrites:
        - type: RequestHeaderModifier
          requestHeaderModifier:
            set:
              - name: "user-agent"
                value: "rewritten-user-agent"
            add:
              - name: "AGC-Header-Add"
                value: "AGC-value"
            remove:
              - "client-custom-header"
EOF

Une fois que la ressource IngressExtension est créée, vérifiez qu’elle retourne Aucune erreur de validation et qu’elle est valide.

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

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

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 ingress ingress-01 -n test-infra -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')

Si vous spécifiez l’indicateur de nom de serveur à l’aide de la commande curl, contoso.com pour le nom de domaine complet du front-end, une réponse du service back-end-v1 est retournée.

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": [
   "dcd4bcad-ea43-4fb6-948e-a906380dcd6d"
  ]
 },
 "namespace": "test-infra",
 "ingress": "",
 "service": "",
 "pod": "backend-v1-5b8fd96959-f59mm"
}

La spécification d’un en-tête d’agent utilisateur avec la valeur my-user-agent doit retourner une réponse rewritten-user-agent du service back-end :

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

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

{
 "path": "/",
 "host": "fabrikam.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-v1-5b8fd96959-f59mm"
}

La spécification d’un en-tête client-custom-header avec la valeur moo doit être supprimée de la requête quand Passerelle d'application pour conteneurs lance la connexion au service back-end :

fqdnIp=$(dig +short $fqdn)
curl -k --resolve contoso.com:80:$fqdnIp http://contoso.com -H "client-custom-header: moo"

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

{
 "path": "/",
 "host": "fabrikam.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": [
   "kd83nc84-4325-5d22-3d23-237dd4e3941b"
  ]
 },
 "namespace": "test-infra",
 "ingress": "",
 "service": "",
 "pod": "backend-v1-5b8fd96959-f59mm"
}

Félicitations, vous avez installé le contrôleur ALB, déployé une application back-end et modifié des valeurs d’en-tête via l’API d’entrée sur la Passerelle d’application pour conteneurs.