Lors du routage du trafic via un maillage de services, il est souvent nécessaire d'injecter des identifiants de traçabilité, d'appliquer des politiques de sécurité ou de transmettre des métadonnées entre les services. Service Mesh (ASM) prend en charge la manipulation des en-têtes HTTP au niveau de la route grâce au champ headers de la ressource personnalisée (CRD) VirtualService. Vous pouvez ajouter, remplacer ou supprimer des en-têtes dans les requêtes et les réponses sans modifier le code de l'application.
Prérequis
Avant de commencer, assurez-vous d'avoir :
Déployé l'application HTTPBin dans votre instance ASM. Pour obtenir des instructions, consultez la rubrique Déployer l'application HTTPBin
Référence des opérations sur les en-têtes
VirtualService propose trois opérations pour manipuler les en-têtes :
|
Opération |
Champ YAML |
Comportement |
Type de valeur |
|
|
|
Ajoute l'en-tête spécifié avec la valeur indiquée. Crée l'en-tête s'il n'existe pas. |
|
|
|
|
Remplace la valeur de l'en-tête. Crée l'en-tête s'il n'existe pas. |
|
|
|
|
Supprime entièrement l'en-tête. |
|
Valeurs d'en-tête statiques et dynamiques
Les valeurs des en-têtes peuvent être des chaînes statiques ou des opérateurs de commande Envoy dynamiques entourés de symboles %. Par exemple, %UPSTREAM_CLUSTER% indique le nom d'un fournisseur de service. Tous les opérateurs de commande HTTP utilisés pour les journaux d'accès peuvent être spécifiés dans les en-têtes de requête ou de réponse personnalisés.
|
Variable |
Description |
|
|
Horodatage du début de la requête |
|
|
Nom du cluster de service en amont |
Pour consulter la liste complète des variables disponibles, reportez-vous à la section Command operators de la documentation Envoy.
Configurer la manipulation des en-têtes
La configuration VirtualService suivante illustre les trois opérations appliquées aux en-têtes de requête et de réponse :
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: httpbin-vs
spec:
gateways:
- httpbin
hosts:
- '*'
http:
- route:
- destination:
host: httpbin
port:
number: 8000
weight: 100
headers:
request:
add:
x-custom-request-header: "custom-value" # Append a static value
x-dynamic-request-header: "%START_TIME%" # Append a dynamic value
set:
x-another-request-header: "another-value" # Overwrite or create
remove:
- x-unwanted-header # Delete entirely
response:
add:
x-custom-response-header: "custom-response-value"
set:
x-another-response-header: "another-response-value"
remove:
- x-unwanted-response-header
Cette configuration applique les modifications suivantes :
En-têtes de requête
Ajoute
x-custom-request-headeravec la valeur statiquecustom-value.Ajoute
x-dynamic-request-headeravec l'horodatage de début de la requête, résolu au moment de l'exécution à partir de%START_TIME%.Remplace
x-another-request-headerpar la valeuranother-value. Crée l'en-tête s'il n'existe pas.Supprime
x-unwanted-header.
En-têtes de réponse
Ajoute
x-custom-response-headeravec la valeurcustom-response-value.Remplace
x-another-response-headerpar la valeuranother-response-value. Crée l'en-tête s'il n'existe pas.Supprime
x-unwanted-response-header.
La CRD VirtualService permet de définir et de modifier les en-têtes HTTP. Toutefois, les journaux d'accès Envoy n'enregistrent pas ces modifications si Envoy conserve les configurations par défaut des journaux d'accès. Pour enregistrer des en-têtes personnalisés dans les journaux d'accès Envoy, vous devez modifier le format des journaux d'Envoy.
Vérifier les en-têtes personnalisés dans les journaux d'accès
ASM vous permet de personnaliser les formats de journalisation. Les expressions personnalisées des journaux d'accès peuvent extraire des valeurs provenant des en-têtes de requête, des en-têtes de réponse et des valeurs intégrées d'Envoy. Pour plus d'informations, consultez la rubrique Personnaliser le format des journaux d'accès.
Ajoutez les champs suivants au format de votre journal d'accès :
|
Nom du champ |
Type |
Expression de format de journal |
|
|
Attribut de requête |
|
|
|
Attribut de requête |
|
|
|
Attribut de réponse |
|
Les en-têtes de réponse modifiés par VirtualService peuvent ne pas apparaître dans les journaux d'accès si Envoy applique la modification après l'étape de journalisation dans sa chaîne de filtres. Il s'agit d'un comportement attendu et non d'une erreur de configuration. Consultez l'exemple du pod HTTPBin ci-dessous.
Après avoir mis à jour le format du journal, vérifiez les journaux d'accès du pod de passerelle et du pod HTTPBin.
Journal d'accès du pod de passerelle
Le pod de passerelle capture les modifications des en-têtes de requête et de réponse :
{
"bytes_received": "9",
"bytes_sent": "33",
"response_code": "200",
"my-x-custom-request-header": "custom-value",
"my-x-dynamic-request-header": "2024-01-16T14:49:21.187Z",
"my-x-custom-response-header": "custom-response-value"
}
Journal d'accès du pod HTTPBin
Le sidecar HTTPBin ne capture pas les en-têtes de réponse ajoutés par VirtualService, car la modification intervient après le point de journalisation du sidecar. Le champ my-x-custom-response-header affiche - :
{
"bytes_received": "9",
"bytes_sent": "33",
"response_code": "200",
"my-x-custom-request-header": "custom-value",
"my-x-dynamic-request-header": "2024-01-16T14:49:21.187Z",
"my-x-custom-response-header": "-"
}