Consider implementing a solution to automatically add the routes defined in strategy.canary.trafficRouting.istio.virtualService.routes to strategy.canary.trafficRouting.managedRoutes. This would allow headers specified in the setHeaderRoute step to be included in the HTTPMatchRequest rules of the routes. This ensures that requests with specific URI and header combinations are routed entirely to the Canary replica set during a rollout. For example, when both a URI and a header match are provided, traffic should be directed to the Canary deployment before proceeding with traffic switching.
Use Cases
This enhancement is useful in scenarios where precise traffic routing is required during canary deployments based on both URIs and headers. It allows users to test the Canary service in isolation when specific conditions (URI and header) are met, ensuring consistent behavior before the traffic switch happens.
Example rollout configuration:
strategy:
canary:
canaryService: rollouts-demo-canary
stableService: rollouts-demo-stable
trafficRouting:
managedRoutes:
- name: primary
istio:
virtualServices:
- name: rollouts-demo-vsvc1 # At least one virtualService is required
routes:
- primary # At least one route is required
- name: rollouts-demo-vsvc2
routes:
- secondary # At least one route is required
steps:
- setHeaderRoute:
name: primary
match:
- headerName: CH1
headerValue:
exact: Mozilla
- pause: {}
Summary
Consider implementing a solution to automatically add the routes defined in
strategy.canary.trafficRouting.istio.virtualService.routes
tostrategy.canary.trafficRouting.managedRoutes
. This would allow headers specified in the setHeaderRoute step to be included in theHTTPMatchRequest
rules of the routes. This ensures that requests with specific URI and header combinations are routed entirely to the Canary replica set during a rollout. For example, when both a URI and a header match are provided, traffic should be directed to the Canary deployment before proceeding with traffic switching.Use Cases
This enhancement is useful in scenarios where precise traffic routing is required during canary deployments based on both URIs and headers. It allows users to test the Canary service in isolation when specific conditions (URI and header) are met, ensuring consistent behavior before the traffic switch happens.
Example rollout configuration:
Current VirtualService state before deployment:
Desired VirtualService state during deployment (First step after canary replicas are scaled) :
Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritize the issues with the most 👍.