Traffic split based on HTTP headers match conditions about smi-spec

[stefanprodan]

The header match conditions have been merged into the spec, next is the TrafficSplit API spec update 🎉

[stefanprodan]

As suggested by @nicholasjackson this is how an A/B test could look using HTTP routes:

---
kind: HTTPRouteGroup
metadata:
  name: website-routes
matches:
- name: external-users
  pathRegex: ".*"
  methods: ["*"]
  headers:
   - user-agent: ".*Chrome.*"
   - cookie: "^(.*?;)?(canary=enabled)(;.*)?$"
- name: internal-users
  pathRegex: ".*"
  methods: ["*"]
  headers:
   - x-canary: "enabled"
- name: all-users
  pathRegex: ".*"
  methods: ["*"]
---
kind: TrafficTarget
metadata:
  name: website-canary
destination:
  kind: TrafficSplit
  name: website-canary
specs:
- kind: HTTPRouteGroup
  name: website-routes
  matches:
  - external-users
  - internal-users
---
kind: TrafficTarget
metadata:
  name: website-primary
destination:
  kind: TrafficSplit
  name: website-primary
specs:
- kind: HTTPRouteGroup
  name: website-routes
  matches:
  - all-users
---
kind: TrafficSplit
metadata:
  name: website-primary
spec:
  service: website-primary
  backends:
  - service: website-primary
    weight: 100
  - service: website-canary
    weight: 0
---
kind: TrafficSplit
metadata:
  name: website-canary
spec:
  service: website-canary
  backends:
  - service: website-primary
    weight: 0
  - service: website-canary
    weight: 100

I'm in favour of the first proposal, this is not only highly verbose but makes automation of an A/B test harder. For example Flagger would have to create the HTTPRouteGroups and TrafficTargets, that means users will have to add all routes to the Canary spec or the routes will overwritten by Flagger. Another issue is that the routes approach needs two apex domains and having a priority field for the routes.

[michelleN]

@stefanprodan thanks so much for going through the exercise. The more I thought about it yesterday, the more I appreciated the first approach coming from a UX perspective and it's nice to have all the traffic split functionality defined in one place like you mentioned. Even if we do header matching somewhere else eventually, this pattern of the match section is simple enough to repeat.

[grampelberg]

Oh, I hadn't even considered using TrafficTarget for anything other than ACLs. Here's what I was thinking:

kind: HTTPRouteGroup
metadata:
  name: the-routes
matches:
- name: metrics
  pathRegex: "/metrics"
---
kind: TrafficSplit
metadata:
  name: website
spec:
  service: website
  matches:
  - kind: HTTPRouteGroup
    name: the-routes
  backends:
  - service: website-primary
    weight: 0
  - service: website-canary
    weight: 100

Things I like

• HTTPRouteGroup was originally intended to be auto-generated from a swagger spec. While it isn't required, it is nice to be able to have a single definition of what the traffic for a service should look like that can be referenced and validated as part of an admission controller.

• Using matches allows for different types of protocols, imagine using this for gRPC for example.

• Makes it explicit what the split matches. Instead of a bunch of different backends, there's a single thing that matches and does the distribution.

• Looking down the road, this approach allows for doing things like only redirecting idempotent requests (selecting all the GET routes in a HTTPRouteGroup) without duplicating definitions everywhere.

Open Questions

• How do users reason about two traffic splits that match the same apex service? Is this a valid use case? Should the admission controller manage this behavior?

• I've not tried to add headers into HTTPRouteGroup. It'd be possible to either add them there or create a separate resource (neither way feels great right now).

[stefanprodan]

I don’t see how your example covers the use case I’ve described. I see a single backend list and that can’t accommodate the A/B test.

[grampelberg]

In this instance, all traffic that matches /metrics will go to website-canary. All other traffic will go to website-primary. Ignoring the headers piece, which I definitely need to spend more time thinking about, it seems like it matches your use case? What am I missing?

[stefanprodan]

There is no primary 100% in the definition. How you decide where the traffic goes that doesn’t match the conditions?

[stefanprodan]

Ah I got it. The website ClusterIP should point to the primary not the TrafficSplit apex.

[grampelberg]

Whatever was happening beforehand. I'm trying to do the additive approach, eg. this TrafficSplit will only be evaluated if it matches the conditions - otherwise, everything behaves the way it did before the TrafficSplit was created.

You could also do:

kind: HTTPRouteGroup
metadata:
  name: the-routes
matches:
- name: metrics
  pathRegex: "/metrics"
---
kind: TrafficSplit
metadata:
  name: website
spec:
  service: website
  matches:
  - kind: HTTPRouteGroup
    name: the-routes
  backends:
  - service: website-primary
    weight: 0
  - service: website-canary
    weight: 100
---
kind: TrafficSplit
metadata:
  name: website
spec:
  service: website
  backends:
  - service: website-primary
    weight: 100
  - service: website-canary
    weight: 0

This raises a couple other questions though (which are also relevant for your original proposal) - how do we highlight hierarchy? Is it just done by specificity?

fwiw, given your confusion, this may not be the best suggestion =)

[stefanprodan]

I thought that the apex replaces the Kubernetes service, but even if the TrafficSplit is additive I think merging can’t be avoided if we want to allow per route splitting. For example, if I want to route /login 10% to canary and logout 20% to canary I’ll have to create two splits with the same apex. I think that the only way to avoid merging is to allow pairs of conditions/backends in a single TrafficSplit.

[grampelberg]

Yeah, my point is that we're gonna have to tackle merging no matter what.