Virtual Service/Router/Balancer type concept

[ibuildthecloud]

I don't see any type of ability to create a virtual service/router/balancer. Something that physically doesn't exist but has routing rules to get to something that does. Basically this ends up being something that looks a lot like Ingress. You might say then use ingress but the service mesh basically has to subsume ingress functionality. The reason being that ingress is north-south only but users need the same functionality east west and logically the same ACL, routing, metrics rules of north south should apply to east west.

So what I'd like to see is I create a service foo in k8s that has no selector. Then create a resources like

kind: Router
spec:
  service: foo
  routes:
  - match:
    # something referring to httpRouteGroup
    dest:
    # something to target a service (that can have traffic splitting applied)

[aanandr]

Do we really need the capability for East-West? What is the reason? Through service discovery we know what kind of services are provided and how to reach them. Whats left is defining policies that enforce who can talk to whom and that is covered under traffic access control

[nicholasjackson]

My take on this is you have an actual Service resource, something like...

Service
 |--Identity
 |--Listeners
 |----Listener
 |------Port
 |------Authenticated
 |------Routes
 |--------HTTPRouteGroup
 |--Upstreams
 |----Upstream

A TrafficTarget would reference the routes defined within a listener to control ingress, egress now I think about it should probably be a separate object TrafficDesination (terrible name).

We should probably kick this off after KubeCon, I am guessing most people are quite busy right now, would also be interesting to see what the community things once this gets opened up.

[ibuildthecloud]

@aanandr I think this will be an ask of the community as this is a major and popular part of istio, basically the VirtualService API. I'm reading over the spec with the idea if I can replace my istio integration with SMI. Right now I can't because I see no ability to do L7 routing of traffic, which is crucial.

[olix0r]

If it's helpful context, we intentionally left this out of the initial scope so we could deliver something concrete for kubecon. It will definitely be an open topic afterwards ;)

[aledbf]

Just a question, this is a replacement, complement or something that "competes" with Ingress? (the
spec).
Just in case, this was presented today https://static.sched.com/hosted_files/kccnceu19/97/%5Bwith%20speaker%20notes%5D%20Kubecon%20EU%202019_%20Ingress%20V2%20%26%20Multi-Cluster%20Services.pdf

[nicholasjackson]

@aledbf SMI is predominately concerned with East/West traffic (traffic inside the cluster) where Ingress concerns North/South (traffic into the cluster). There is a little overlap as at some point the traffic from the ingress needs to be securely routed to upstream services. Good call raising this, this interaction does need to be explained and specified.

[aledbf]

@nicholasjackson thank you for the clarification.

[mikemorris]

If SMI were to consider adopting the HTTPRoute CRs from the Gateway API Spec (as originally mentioned in #66 (comment) and discussed again today during the SMI community meeting), the planned work around "route delegation" discussed in kubernetes-sigs/gateway-api#634 sounds like it might be able to address this need?