Consider allowing header based routing for routes that are added in strategy.canary.trafficRouting.istio.virtualService.routes

[balajimurugaiya]

Summary

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: {}

Current VirtualService state before deployment:

http:
- name: primary
  match: 
    - uri:
        exact: "/api/v2/somepath"
  route:
  - destination:
      host: rollouts-demo-stable
      port:
        number: 15372
    weight: 100
  - destination:
      host: rollouts-demo-canary
      port:
        number: 15372
    weight: 0

Desired VirtualService state during deployment (First step after canary replicas are scaled) :

http:
- name: primary_with_header
  match: 
    - headers: 
        CH1: 
          exact: Mozilla
      uri:
        exact: "/api/v2/somepath"
  route:
  - destination:
      host: rollouts-demo-canary
      port:
        number: 15372
    weight: 100
- name: primary
  match: 
    - uri:
        exact: "/api/v2/somepath"
  route:
  - destination:
      host: rollouts-demo-stable
      port:
        number: 15372
    weight: 100
  - destination:
      host: rollouts-demo-canary
      port:
        number: 15372
    weight: 0

---

Message from the maintainers:

Impacted by this bug? Give it a 👍. We prioritize the issues with the most 👍.

[ziansong]

I want this function needs add uri prefix and corsPolicy
http:

• name: primary_with_header
  corsPolicy:
  allowHeaders:
  - ''
  allowMethods:
  - GET
  - DELETE
  - HEAD
  - OPTIONS
  - POST
  - PUT
  - PATCH
  allowOrigins:
  - exact: ''
  match:
  • headers:
    CH1:
    exact: Mozilla
    uri:
    exact: "/api/v2/somepath"
    route:
  • destination:
    host: rollouts-demo-canary
    port:
    number: 15372
    weight: 100
• name: primary
  corsPolicy:
  allowHeaders:
  - ''
  allowMethods:
  - GET
  - DELETE
  - HEAD
  - OPTIONS
  - POST
  - PUT
  - PATCH
  allowOrigins:
  - exact: ''
  match:
  • uri:
    exact: "/api/v2/somepath"
    route:
  • destination:
    host: rollouts-demo-stable
    port:
    number: 15372
    weight: 100
  • destination:
    host: rollouts-demo-canary
    port:
    number: 15372
    weight: 0