<p>I am putting together a proof of concept to help identify gotchas using Spring Boot/Netflix OSS and Kubernetes together. This is also to prove out related technologies such as Prometheus and Graphana.</p>
<p>I have a Eureka service setup which is starting with no trouble within my Kubernetes cluster. This is named discovery and has been given the name &quot;discovery-1551420162-iyz2c&quot; when added to K8 using</p>
<pre><code></code></pre>
<p>For my config server, I am trying to use Eureka based on a logical URL so in my bootstrap.yml I have</p>
<pre><code>server:
  port: 8889

eureka:
  instance:
    hostname: configserver
  client:
    registerWithEureka: true
    fetchRegistry: true
    serviceUrl:
      defaultZone: http://discovery:8761/eureka/

spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/xyz/microservice-config
</code></pre>
<p>and I am starting this using</p>
<pre><code>kubectl run configserver --image=xyz/config-microservice --replicas=1 --port=8889
</code></pre>
<p>This service ends up running named as configserver-3481062421-tmv4d. I then see exceptions in the config server logs as it tries to locate the eureka instance and cannot.</p>
<p>I have the same setup for this using docker-compose locally with links and it starts the various containers with no trouble.</p>
<pre><code>discovery:
  image: xyz/discovery-microservice
  ports:
   - &quot;8761:8761&quot;
configserver:
  image: xyz/config-microservice
  ports:
   - &quot;8888:8888&quot;
  links:
   - discovery
</code></pre>
<p>How can I setup something like eureka.client.serviceUri so my microservices can locate their peers without knowing fixed IP addresses within the K8 cluster?</p>

Andrew Rutter
<blockquote>
  <p>How can I setup something like eureka.client.serviceUri?</p>
</blockquote>

<p>You have to have a Kubernetes <a href="http://kubernetes.io/docs/user-guide/services/" rel="noreferrer">service</a> on top of the eureka pods/deployments which then will provide you a referable IP address and port number. And then use that referable address to look up the Eureka service, instead of "8761".</p>

<h1>To address further question about HA configuration of Eureka</h1>

<p>You shouldn't have more than one pod/replica of Eureka per k8s service (remember, pods are ephemeral, you need a referable IP address/domain name for eureka service registry). To achieve high availability (HA), spin up more k8s services with one pod in each.</p>

<ul>
<li>Eureka service 1 --> a single pod</li>
<li>Eureka Service 2 --> another single pod</li>
<li>..</li>
<li>..</li>
<li>Eureka Service n --> another single pod</li>
</ul>

<p>So, now you have referable IP/Domain name (IP of the k8s service) for each of your Eureka.. now it can register each other.</p>

<p>Feeling like it's an overkill?
<em>If all your services are in same kubernetes namespace</em> you can achieve everything (well, almost everything, except client side load balancing) that eureka offers though k8s service + KubeDNS add-On. Read this <a href="http://blog.christianposta.com/microservices/netflix-oss-or-kubernetes-how-about-both/" rel="noreferrer">article</a> by Christian Posta</p>

<h1>Edit</h1>

<p>Instead of Services with one pod each, you can make use of <a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/" rel="noreferrer">StatefulSets</a> as <a href="https://stackoverflow.com/a/47490410/6785908">Stefan Ocke</a> pointed out.</p>

<blockquote>
  <p>Like a Deployment, a StatefulSet manages Pods that are based on an
  identical container spec. Unlike a Deployment, a StatefulSet maintains
  a sticky identity for each of their Pods. These pods are created from
  the same spec, but are not interchangeable: each has a persistent
  identifier that it maintains across any rescheduling.</p>
</blockquote>
