Show HN: Endpoints - client-side load balancer library for Kubernetes

github.com

4 points·kelseyhightower··2 comments

What do you see as being the advantage of moving the lb functionality for kubernetes from either the KubeDNS or other internal lb systems (ie sidecars or internal reverse proxy), to being baked into the application code?

I think sidecars accomplish similar goals by moving the LB logic closer to the application. So now the question is: Why would you want to move this kind of thing closer to the application?

Control.

Client-side load balancing enables you to adopt application specific LB logic. For example, when using a RPC framework like gRPC your application MAY prefer reconnecting to the same backend when a temporary failure occurs while streaming between two endpoints.

Client-side load balancing MAY give you more flexibility in terms of adopting a different LB strategy per application. I know some centralized LBs support this, but that often requires configuration changes and MAY impact other applications sharing the centralized LB. A new LB configuration may require more memory or trigger some obscure bug. This all or nothing approach usually means most applications standardize on a one-size fits all solution.

For some people client-side load balancing is much easier to understand. While many platforms hide internal proxies, DNS lookups, etc, those things MUST be understood to fully support any application that pushes data through them. Everything is fine until something goes wrong or when performance does not met your business requirements.

Client-side load balancing does not solve every problem, but it's a tradeoff that MAY yield improved performance and reduce total complexity.

Reply on news.ycombinator.com