This repository has been archived by the owner on Oct 20, 2023. It is now read-only.
Why are are backends in Split spec k8s services #164
Unanswered
shashankram
asked this question in
General
Replies: 1 comment 17 replies
-
I don't understand this. They're just k8s services, so wouldn't they provide the same abstraction? |
Beta Was this translation helpful? Give feedback.
17 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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.
Beta Was this translation helpful? Give feedback.
All reactions