There are usually so many configurations to write with Kubernetes let alone adding a service mesh on top. Deployment, Services, Replica Sets, Ingress, Controllers, Sidecar Injectors, the list goes on. Not to mention the overhead of running the service mesh sidecar PER POD. It’s easy to get carried away writing more and more configuration to the mesh & Kubernetes; potentially making things even slower without realizing it.
Now, I’m not saying a service mesh isn’t good, in fact, they do a lot more good than harm by adding features like Locality-prioritized Load Balancing, Circuit Breaking & Traffic Isolation, etc. But sometimes it’s all a little overkill and can add very noticeable latency to every request.
GRPC contains a neat little feature in it already to be able to manage load balancing inside the client with a few built-in rules like round-robin or weighted round-robin. GRPC is also packaged with a set of resolvers that can map to multiple endpoints, namely the DNS resolver.
When using GRPC in Kubernetes, one can simply make a headless service, point the GRPC client at the DNS entry to provide a list of all pods with the resolver, use the round-robin balancer, and away you go! Right?
If you’ve ever had the pleasure of trying to scale quickly using this method, you will notice that sometimes there can be a massive delay between when your pods are ready vs when your client is aware of the new pods.
Kubernetes already knows (usually, depending on your pod configuration) if your pod is up and running or not and applies this to the service endpoints within a second or so. So wouldn’t it be nice if we could use the same data in our client?
By creating a custom resolver specific to Kubernetes service endpoints, this can be achieved — with relative ease.
By using the resolver to listen to the changes from the services’ endpoint, our client is aware and connected to the new pods in very little time. This works with scaling up and scaling down as our watcher can either be a trigger to update the clients' state with either a complete or delta of the pod endpoints.
By adding a few lines of code to your clients' imports, the resolver & load balancing is all available:
The service mesh-less ways are starting to crop up a little more with implementations like xDS and Google GCP’s Traffic Director which all work in a slightly similar manner, based on the Envoy API, as the demand for lower latency rises.
The major downside of this is that your client's compiled binary size will be a lot larger than normal to include the resolvers' ability to connect to Kubernetes.
GRPC resolver for Kubernetes service endpoints Based off the DNS resolver, rather than making DNS queries, the k8s…
Learn more about…
Traffic Director: https://cloud.google.com/traffic-director