Intro

Eureka is primarily used in the AWS cloud for the purpose of discovery, load balancing and failover of middle-tier servers.

As it have not received updates recently and there are solutions with some advantages over it, it’s not rare to see companies that have migrated or are migrating to other solutions.

Scenario

I worked for a company that started using Netflix’s OSS in 2014. Since this time Eureka was the main service used to discover and register all microservices.

Eureka has a lot of limitations, and we can list some:

  • Eventual consistency
    • This is a huge problem when instances suddenly stop
  • Need for round-trips to heartbeat every application
  • Application needs to know his own IP. If this is a container IP, it needs to know his external/node IP.

It is common to try to migrate to Kubernetes' Services/Ingresses or to another solution like Consul.

Here we will see how it is possible to migrate to Kubernetes' Services/Ingresses with these goals in mind:

  1. Applications outside Kubernetes, using the legacy Eureka service, should still be able to discover and send requests to the new deployments, running in Kubernetes.
  2. Applications outside Kubernetes should prefer to send requests to services outside Kubernetes.

Comparison

Eureka Kubernetes Service
May take a long time to know a service is not running anymore Rapidly knows a service is not running
Services needs to keep heartbeating every X seconds There is no need to heartbeat, but using probes is recommended, though
Needs more configuration, client needs to do round-robin itself Application doesn’t need to bother

References:

Eurek8s

To solve this scenario, one option is to create a Kubernetes controller. Fortunately, we have Eurek8s.

Eurek8s adds a Custom Resource Definition called EurekaApplication to Kubernetes that we can use to configure how the application should be registered in Eureka.

Eurek8s Architecture

There is a Helm Chart that you can use to install it.

After installing (You should use GitOps for this - subject I will write about in the future) it, you’ll want to configure the Eureka client to do not register in Eureka, because Eurek8s will do that for you.

If you are using a Spring Boot application, the configuration should be like this:

1
2
3

eureka:
  client:
    register-with-eureka: false

TIP 1: You can use the zones' info to make your applications outside Kubernetes to prefer requesting the instances outside Kubernetes.

TIP 2: If you are using Spring, I recommend that you create a new configuration file for a new profile. For example: create a application-k8s.yml file with the specific configuration for applications running in Kubernetes.

Each application you want to Eurek8s register, you’ll need to create a EurekaApplication resource.

e.g.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

apiVersion: discovery.eurek8s.com/v1
kind: EurekaApplication
metadata:
  name: sample-app
spec:
  disabled: false
  ingressName: sample-app
  environment: qa # Eurek8s uses the environment name to identify which Eureka it should use to register this application
  appName: sample-app
  zone: k8s-us-east-1
  paths:
    healthcheck: /healthz
    home: /

Eurek8s will register the Ingress address as an application instance in Eureka and heartbeat it every 10 seconds.

At this point you should see your applications registered in your Eureka cluster.

Please, leave any comments if you have questions or suggestions!