kuma-cp: pick a single the most specific TrafficRoute for every outbound interface of a Dataplane

[yskopets]

Summary

• pick a single the most specific TrafficRoute for every outbound interface of a Dataplane
  • match by an exact value is more specific than match by *
    • e.g., service: backend wins over service: *
  • match by N+1 tags is more specific than match by N tags
    • e.g., service: backend, version: v1 wins over service: backend
  • if 2 selectors have the same number of tags, the one that has more exact values is more specific
    • e.g., service: backend, version: v1 wins over service: backend, version: *
  • to compare a combination of source and destination selectors we sum up their numbers of exact and wildcard matching tags
    • e.g.,
      • given TrafficRoute 1:

        sources:
        - match:
             service: web
             version: '*'
        destinations:
        - match:
             service: backend         

      • and TrafficRoute 2:

        sources:
        - match:
             service: web
             version: '*'
        destinations:
        - match:
             service: '*'         

      • TrafficRoute 1 is more specific since it has 3 tags but only 1 wildcard vs 3 tags and 2 wildcards in case of TrafficRoute 2
  • when resolving a tie we consider lexicographical order of Namespace and Name of involved TrafficRoutes
    • e.g., in case of tie,
      • TrafficRoute from the namespace demo wins over a rule from the namespace test
      • when in the same namespace, TrafficRoute named Alice wins over TrafficRoute named Bob

[jakubdyszkiewicz]

I like the tests, it helped me understand the code.

[jakubdyszkiewicz]

What happens if there is no service tag here? I guess this should be caught be validation, but can we then log it if it's wrong or even fail with panic?

[yskopets]

I'm against a panic: a single invalid Dataplane resource should not crash the entire Control Plane.
Logging creates too much noise. A metric might be a proper solution here.
Although, Dataplane resource is invalid in the first place. So, users must have already been alarmed even without this implementation-specific metric.

[yskopets]

I'm adding a TODO here to consider exposing a metric

[jakubdyszkiewicz]

I guess it would be safer to do it. Can you maybe add an issue so we don't forget about it?

[yskopets]

https://github.com/Kong/kuma/issues/427

[jakubdyszkiewicz]

maybe mesh_proto.MatchAll()?

[yskopets]

added MatchAnyService()