Is it possible to route HTTP traffic based on the pod sending the traffic? Currently I am using an HTTP Header to send traffic to canary or production services. When a pod needs to target a canary deployment the code is then responsible for setting a header, normally based on an environment variable our pipeline sets. It would be great if we could somehow instruct Istio and the pod’s sidecar to send all it’s traffic to the canary pods. So canary-pod-a gets route to canary-service-b, while prod-pod-a gets routed to prod-service-b. Is it possible to route based on the sender/requester?
I’ve skimmed the docs and nothing like this popped out at me, any help is appreciated. Thanks!
1 Like
Have a look at the HTTPMatchRequest.SourceLabels
1 Like
Ahh thankyou! It’s under L4MatchAttributes
in the docs for anyone who comes across this post.
This config works fine for me:
http:
### Canary routing
- match:
- headers: # Where header is canary
x-app-version:
exact: "canary"
- sourceLabels: # ** OR ** source pod has label(s)
environment: "canary"
route:
- destination:
host: myapp.mynamespace.svc.cluster.local
subset: "canary"
### Prod routing
- route:
- destination:
host: myapp.mynamespace.svc.cluster.local
subset: "prod"
Hello!
I have the following use case:
Two microservices, A and B, that are deployed using a blue green/canary deployment. Microservice A talks to microservice B via http. While both are in preview/canary mode, we would like Microservice A preview/canary to talk only with Microservice B preview/canary.
The solution we found for the routing between the preview service and active service is by using Istio’s HTTPMatchRequest.SourceLabels. This way we would do it transparently without any logic inside the application.
The way we do it is by adding some custom labels on the pods that are in preview/canary and remove them once promoted as stable.
My question is: Does Istio catch the removal of the canary label from the source pod?
From what I tested so far it doesn’t seem so. Basically I’m creating a pod with a canary label attached to it and then I remove the canary label by editing the pod manually.
What I would expect to happen is to see the traffic being routed to the stable version but what happens actually is that, after the label removal, the traffic is still routed to the canary version