Load balancing in Spring boot micro services hosted on Kubernetes

1
votes

Context:

Building Micro services based architecture using SpringBoot and REST APIs/micro-services. The application will be Containerized using Docker and then will be deployed on Google Cloud Platform Kubernetes service. Thinking of using Nextflix ZUUL for API Gateway for Cross cutting concerns like Authentication / Authorization (OAuth2), Service discovery (Eureka) & Compose, etc..

Query:

As the application will be hosted on Kubernetes, the question is around which Load balancing should be used? As per my limited knowledge there are 2 options: 1) Ribbon 2) Kubernetes Service 3) Combination of both of the above

It would be great help if will get some pointers, best practices etc. to come up with optimum solution. Kindly let know if additional information is required from my side.

Thanks!

1
spring-bootload-balancingmicroservicesnetflix-zuulgoogle-kubernetes-engine
You may want to have a look at stackoverflow.com/questions/51482499/… I don't think it fully answers your question but it might help – Ryan Dawson
Thanks @RyanDawson, that was certainly helpful! I am checking the links in your response. – Para_Conscious

1 Answers

3
votes

Finding an optimum solution can often be a moving target as a project evolves but I can share some points to be aware of. As you suggest, if your services are all inside Kubernetes and have a ClusterIP then they will be automatically load-balanced. 'Headless' services or external services, from outside the cluster, would not. So if you have those then you could consider ribbon for doing the load-balancing inside the services. There is an implementation that uses kubernetes for discovery if you decide against eureka. Ribbon has the advantage of working with hystrix so you could then do rate-limiting in addition to load-balancing.

There are also more sophisticated options available within the kubernetes ecosystem. You can have services of type LoadBalancer or use Ingress but these tend to be used for external exposure whereas I think your question is more about service-to-service communication. Another way of addressing these concerns would be to use a service mesh and Istio is gaining a lot of attention in the Kubernetes space. You could use it to address service-to-service load-balancing and rate-limiting and also provide a gateway/s.

Using a kubernetes-native approach or mesh would have the advantage of doing this in a language-neutral way. If you needed ribbon/hystrix in your services and then wanted to add a python-based service you'd have to think about how to get consistent behaviour.

I'd suggest that you be sure to consider what you and your team finds easiest to work with. There are a lot of options and nuances and it is good to be aware of them but you may find that you don't need anything fancy.