I’ve been looking at Linkerd 2, and it appears to be a really nice piece of software that would solve several issues in one go for our use-case. There is one core problem preventing our adoption, so I wanted to sound out whether there was appetite for the feature required to solve it.
We have a Kubernetes Deployment and associated Service that manages search indexes. It consists of several pods. At any one time, a given pod “owns” an index and needs to be used for any reads and writes to that index; this is currently essential for acceptable performance. Essentially, we need pod affinity based on index name.
The most generic solution I’ve come up with is providing a HTTP Header in the GRPC requests between the main web service and the search microservice. Then the proxy does load balancing based on consistent hashing of that header, rather than EWMA. This would mean that, for a given value of the HTTP header, each web service pod would consistently use the same backing pod when making requests via the linkerd proxy (assuming a stable set of backing pods, and that we accept some churning during search pod upgrades, scaling etc.). Put the index name into the header, bingo we gain the index affinity we need.
This is different to switching between Kubernetes services based on L7 data per https://github.com/linkerd/linkerd2/issues/3165, it is specifically about load balancing between the pods of a given service. I can see that Service Profiles start to provide the hooks to differentiate load balancing strategy by Service name.
Is there any appetite for this kind of extra feature in Linkerd’s proxy, or should we look to things like HAProxy to provide this? At this point I’m not sure how generally required this kind of thing is in a service mesh, I’m new to the area.