StatefulSet

StatefulSet is a building block for stateful workload on Kubernetes with certain guarantees.

Stable and unique network identity

StatefulSet Pods have a unique identity that is comprised of an ordinal, a stable network identity, and stable storage.

As an example, if your StatefulSet has the name sharded-svc

apiVersion: apps/v1kind: StatefulSetmetadata:  name: sharded-svc

And you have e.g. 3 replicas, those will be named by <name>-<ordinal> where ordinal starts from 0 up to replicas-1.

The name of your pods will be:

sharded-svc-0sharded-svc-1sharded-svc-2

and those pods can be reached with a dns-name:

sharded-svc-0.sharded-svc.your-namespace.svc.cluster.localsharded-svc-1.sharded-svc.your-namespace.svc.cluster.localsharded-svc-2.sharded-svc.your-namespace.svc.cluster.local

given that your Headless Service is named sharded-svc and you deploy it in namespace your-namespace.

Sharding or Partitioning

given multiple replicas of the target service of a frontend -> backend call, I can reliably route traffic for a certain account to a certain endpoint instance.

What you describe here is that your stateful service is what is called sharded or partitioned. This does not come out of the box from Kubernetes, but you have all the needed building blocks for this kind of service. It may happen that it exists an 3rd party service providing this feature that you can deploy, or it can be developed.

Sharding Proxy

You can create a service sharding-proxy consisting of one of more pods (possibly from Deployment since it can be stateless). This app need to watch the pods/service/endpoints in your sharded-svc to know where it can route traffic. This can be developed using client-go or other alternatives.

This service implements the logic you want in your sharding, e.g. account-nr modulus 3 is routed to the corresponding pod ordinal

Update: There are 3rd party proxies with sharding functionallity, e.g. Weaver Proxy

Sharding request based on headers/path/body fields

Recommended reading: Weaver: Sharding with simplicity

Consuming sharded service

To consume your sharded service, the clients send request to your sharding-proxy that then apply your routing or sharding logic (e.g. request with account-nr modulus 3 is routed to the corresponding pod ordinal) and forward the request to the replica of sharded-svc that match your logic.

Alternative Solutions

Directory Service: It is probably easier to implement sharded-proxy as a directory service but it depends on your requirements. The clients can ask your directory service to what statefulSet replica should I send account-nr X and your serice reply with e.g. sharded-svc-2

Routing logic in client: The probably most easy solution is to have your routing logic in the client, and let this logic calculate to what statefulSet replica to send the request.

Services generally run the proxy in kernel space for performance reasons so writing custom code is difficult. Cillium does allow writing eBPF programs for some network features but I don't think service routing is one of them. So that pretty much means working with a userspace proxy instead. If your service is HTTP-based, you could look at some of the existing Ingress controllers to see if any are close enough or allow you to write your own custom session routing logic. Otherwise you would have to write a daemon yourself to handle it.