Why are are backends in Split spec k8s services

[shashankram]

Per my understanding, K8s services are abstractions for clients to communicate with a service without having to worry about the backend endpoints for the service. A client would use the service FQDN and resolve to a cluster IP, which K8s would use to load-balance traffic to backends running the service over their endpoints. This allows clients to continue using the service FQDN even if their backends change.

With SMI Split, the user needs to define additional K8s services for the backends. Had the backends been exposed in the form of selectors similar to Istio, users could continue to use a Service as an abstraction for the client apps. If users need to use Split, they need to define additional services which no longer provide the abstraction a K8s Service resource provides.

What was the reason to do this? Are users okay to define additional services just for Split? Another benefit with using the Service abstraction and not enforcing the backends in the Split to be services is that as the backends are versioned out, clients can continue to use the abstract Service FQDN without having to maintain version specific Service resources.

[grampelberg]

If users need to use Split, they need to define additional services which no longer provide the abstraction a K8s Service resource provides.

I don't understand this. They're just k8s services, so wouldn't they provide the same abstraction?

[shashankram]

I'm having a tough time understanding the benefits, namely your point:

Clients accessing the website service are only using website.default.svc.cluster.local at all times, and never directly reference the backends.

This is how it works today with the existing implementation.

Yes this part is well and good. I am complaining about users having to define a service per backend which breaks the whole point of defining a service as an abstraction for its backends.

This provides the same degree of abstraction K8s services provide for load balancing traffic to the backends of website service using their cluster IP,

This is not actually true, as ClusterIP will forward to all backends - both v1 and v2, which could be disastrous for some users.

You misunderstood my comment. I am not suggesting the service mesh do this, but suggesting that the service mesh refer to the TrafficSplit spec to load balance traffic. The difference in my example spec above is that the backend are not services, just versions.

There might be something we could do around service topologies to make this work, but I'm concerned that we're overloading concepts at that point.

I am trying to convey that making the backends refer to service resources via their names breaks the service abstraction kubernetes provides for its backends. I am suggesting we use version or some other selector for backends instead of service.

[shashankram]

@grampelberg I still see a value in using selectors for backends. Is this something that can be supported in addition to having the backends be services?

[grampelberg]

Totally up for the discussion! I'll be honest, I don't see the value and the complexity it adds to implementations is pretty steep. Especially when you consider that it'll then miss out on service topologies and readiness checks.

We could make the field an object reference instead of an actual service name. That'd allow you to implement your own selector CRD and make it optional to support for implementations.

[shashankram]

Creating a service per backend is confusing for users. Providing additional flexibility would be great. Interested in learning more about your proposal above. How would a sample spec look like with object references?

[grampelberg]

apiVersion: split.smi-spec.io/v1alpha3
kind: TrafficSplit
metadata:
  name: website-canary
  namespace: default
spec:
  service: website
  backends:
  - resource:
       kind: Selector
       name: website-v1
     weight: 90
  - resource:
       kind: Selector
       name: website-v2
     weight: 10
---
kind: Selector
metadata:
  name: website-v1
  namespace: default
spec:
  selector:
    version: website-v1
    name: website
---
kind: Selector
metadata:
  name: website-v2
  namespace: default
spec:
  selector:
    version: website-v2
    name: website

This would obviously only be supported by your implementation of SMI, as anything can be an object reference (and it ends up being a subset of the functionality that you'd get by using services), but it'd get you what you want.