K
Q

Istio: Can I add randomly generated unique value as a header to every request before it reaches my application

1/23/2020

I have a RESTful service within a spring boot application. This spring boot app is deployed inside a kubernetes cluser and we have Istio as a service mesh attached to the sidecar of each container pod in the cluster. Every request to my service first hits the service mesh i.e Istio and then gets routed accordingly.

I need to put a validation for a request header and if that header is not present then randomly generate a unique value and set it as a header to the request. I know that there is Headers.HeaderOperations which i can use in the destination rule but how can i generate a unique value every time the header is missing? I dont want to write the logic inside my application as this is a general rule to apply for all the applications inside the cluster

-- codeninja
api-gateway
http-headers
istio
kubernetes
microservices

Similar Questions

ROS 2 on K8s: Multicast fails within same pod, succeeds in different pods
How to pick proper number of threads, workers, processes for Dask when running in an ephemeral environment as single machine and cluster
How can I start a job automatically after a successful deployment in kubernetes?
Rook OSD after node failure
Is there a Kubernetes rolling upgrade / downgrade finish hook
AGIC deletes a working backend when a different pod fails to start

2 Answers

1/24/2020

From reading the documentation of istio and envoy it seems like this is not supported by istio/envoy out of the box. As a workaround you have 2 options

Option 1: To set the x-envoy-force-trace header in virtual service

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
  - reviews.prod.svc.cluster.local
  http:
  - headers:
      request:
        set:
          x-envoy-force-trace: true

It will generate a header x-request-id if it is missing. But it seems like abuse of tracing mechanism.

Option 2: To use consistentHash balancing based on header, e.g:

 apiVersion: networking.istio.io/v1alpha3
 kind: DestinationRule
 metadata:
   name: bookinfo-ratings
 spec:
   host: ratings.prod.svc.cluster.local
   trafficPolicy:
     loadBalancer:
       consistentHash:
         httpHeaderName:
           name: x-custom-request-id

It will generate the header x-custom-request-id for any request that doesn't have this header. In this case the requests with same x-custom-request-id value will go always to the same pod that can cause uneven balancing.

-- Yuri G.
Source: StackOverflow
1/27/2020

There is important information that needs to be said in this subject. And it looks to me like You are trying to make a workaround tracing for an applications that does not forward/propagate headers in Your cluster. So I am going to mention few problems that can be encountered with this solution (just in case).

As mentioned in answer from Yuri G. You can configure unique x-request-id headers but they will not be very useful in terms of tracing if the requests are passing trough applications that do not propagate those x-request-id headers.

This is because tracing entire request paths needs to have unique x-request-id though out its entire trace. If the x-request-id value is different in various parts of the path the request takes, how are We going to put together the entire trace path?

In a scenario where two requests are received in application pod at the same time even if they had unique x-request-id headers, only application is able to tell which inbound request matches with which outbound connection. One of the requests could take longer to process and without forwarded trace header we can't tell which one is which.

Anyway for applications that do support forwarding/propagating x-request-id headers I suggest following guide from istio documentation.

Hope it helps.

-- Piotr Malec
Source: StackOverflow