Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Disadvantages of using eureka for Service Discovery with kubernetes

Context

I am deploying a set of services that are containerised using Docker into AWS. No matter which deployment solution is chosen (e.g. raw EC2/ECS/Elastic Beanstalk/Fargate) we will face the issue of "service discovery".

To name just a few of the options for service discovery that I've considered:

  • AWS Route 53 Service Registry
  • Kubernetes
  • Hashicorp Consul
  • Spring Cloud Netflix Eureka

Specifics Of My Stack

I am developing Java Spring Boot applications using Spring Cloud with the target deployment environment being AWS.

Given that my stack is Spring based, spring cloud eureka made sense to me while developing locally. It was easy to set up a single node, integrates well with the stack and ecosystem of choice and required very little set up.

Locally, we are using docker compose (not swarm) to deploy services - one of the containers deployed is a single node Eureka service discovery server.

However, when we progress outside of local development and into staging or production environment we are considering options like Kubernetes.

My Own Assessment Of Pros/Cons

AWS Route 53 Service Registry

Requires us to couple code specifically to AWS services. Not a problem per se, we are quite tied in anyway on other parts of the stack (SNS/SQS).

Makes running the stack locally slightly more difficult as it relies on Route 53, I suppose we could open up a certain hosted zone for local development.

AWS native, no managing service registries or extra "moving parts".

Spring Cloud Eureka

Downside is that thus requires us to deploy and manage a high availability service registry cluster and requires more resources. Another "moving part" to manage.

Advantages are that it fits into our stack well (spring ecosystem, spring boot, spring cloud, feign and zuul work well with this). Also can be run locally trivially.

I presume we need to configure the networks and registry zone to ensure that that clients publish their host address rather and docker container internal IP address. e.g. if service A is on host A and wants to talk to service B on host B, service B needs to advertise its EC2 address rather than some internal docker IP.

Questions

If we use Kubernetes for orchestration, are there any disadvantages to using something like Spring Cloud Eureka over the built in service discovery options described here https://kubernetes.io/docs/concepts/services-networking/service/#discovering-services

Given Kube provides this, it seems suboptimal to then use eureka deployed using kube to perform discovery. I presume kube can make some optimisations that impact avaialbility and stability that might nit be possible using eureka. e.g kube would know when deploying a new service - eureka will have to rely on heartbeats/health checks and depending on how that is configured (e.g. frequency) this could result in stale records whereas i presume kube might not suffer from this for planned service shutdown/restarts. I guess it still does for unplanned failures such as a host failure or network partition.

Does anyone have any advice on this, do people use services like Kubernetes but use other mechanisms for service discovery rather than those provided by kube. Is there a good reason to do one or the other?

Possible Challenges I Anticipate

We could replace eureka, but relying on Kube to perform discovery will mean that we need to run kube locally to deploy whereas currently we have a simple tiny docker-compose file. Also, I'll have to look at how easy it'll be to ensure that ribbon, zuul and feign play nicely with this.

Currently we have ribbon configured with a eureka client so that service A can server to service B just as "service-b" for example and have ribbon resolve a healthy host via a eureka client. I guess we can configure ribbon to not use eureka and use an external Kube service name which will be resolved by Kube DNS at runtime...

Final Note

Thanks in advance for any contribution or advice. I know this might elicit a primarily opinion focused response. But I am hoping someone can provide objective guidance on when one solution might be preferable to another.

like image 743
David Avatar asked Apr 13 '18 12:04

David


People also ask

What will happen if one of the Eureka service discovery server in a cluster goes down?

When Eureka server instances will boot up they will look for each other. All microservices will register with them automatically, so if one goes down the other server instance will be always there. On both Eureka instances you will be able to see all the registered microservices.

Can we use Eureka with Kubernetes?

An advantage of using Kubernetes discovery service is that it doesn't require a client library such as Netflix Ribbon, which we have been using together with Netflix Eureka. This makes the Kubernetes discovery service easy to use, independent of which language or framework a microservice is based on.

Do we need service discovery in Kubernetes?

The different components need to communicate within a microservices architecture for applications to function, but individual IP addresses and endpoints change dynamically. As a result, there is a need for service discovery so services can automatically discover each other.

What is service discovery Eureka?

More Detail. Eureka Server is an application that holds the information about all client-service applications. Every Micro service will register into the Eureka server and Eureka server knows all the client applications running on each port and IP address. Eureka Server is also known as Discovery Server.


1 Answers

Service discovery is something you get out-of-the-box with Kubernetes. So having another external service in your platform will be another application to maintain, deploy and can be a point of failure. So I would stick with the the service discovery provided by Kubernetes.

like image 70
alltej Avatar answered Sep 18 '22 17:09

alltej