Can we use Eureka with Kubernetes? Does it cause any issue?

Yes, it is absolutely possible. In fact, many companies did exactly this while migrating from traditional microservices to Kubernetes.

However, it’s generally not recommended because you’re running two service discovery systems at the same time.

Let’s see what happens.

---

Scenario

Suppose your application already has:

• ✅ Eureka Server
• ✅ Eureka Client in every service
• ✅ Spring Cloud LoadBalancer/OpenFeign

Now you deploy everything to Kubernetes.

Your architecture becomes:

                    Internet
                        |
                    AWS ALB
                        |
                  Kubernetes Ingress
                        |
                 API Gateway Pods
                        |
                -----------------
                |               |
          Order Service    Payment Service
                |               |
        Eureka Client     Eureka Client
                \             /
                 \           /
                 Eureka Server

At the same time, Kubernetes is already providing:

• Service Discovery
• DNS
• Load Balancing
• Health Monitoring

So now you have duplicate infrastructure.

---

What happens when Payment Service starts?

Kubernetes

Pod starts.

Payment Pod

↓

Service selects Pod

↓

DNS updated

Done.

---

Eureka

The same pod also says:

Hello Eureka

I'm Payment Service

IP = 10.0.2.15

Port = 8080

So Eureka stores it.

Now the same service is registered in:

• Kubernetes
• Eureka

---

When Order Service calls Payment Service

Option 1 (Using Eureka)

Order

↓

Ask Eureka

↓

Payment Instance

↓

Call Payment

Kubernetes is not involved in service discovery here (except basic networking).

---

Option 2 (Using Kubernetes)

Order

↓

http://payment-service

↓

Kubernetes Service

↓

Payment Pod

Eureka is not involved.

---

So what is the impact?

1. Extra Infrastructure

You now need to maintain:

• Eureka Server
• Kubernetes Services

Both solve the same problem.

---

2. More Memory

Instead of only running:

User

Order

Payment

you also run

Eureka Server

Extra pod.

Extra CPU.

Extra RAM.

---

3. More Network Calls

Every Eureka Client sends heartbeats periodically.

Payment

↓

Heartbeat

↓

Eureka

If you have 100 services with multiple instances, that’s a lot of additional traffic that Kubernetes doesn’t require.

---

4. Two Sources of Truth

This is the biggest issue.

Imagine:

Kubernetes says

Payment Pod

Healthy

But Eureka still thinks

Payment Pod

UP

or vice versa.

Now debugging becomes harder because two systems may disagree temporarily.

---

5. More Configuration

Instead of:

spring.application.name=payment

You now also have:

eureka.client.service-url.defaultZone=...
eureka.client.register-with-eureka=true
eureka.instance.hostname=...

All of this becomes unnecessary on Kubernetes.

---

Does it still work?

Yes.

Many companies migrated like this:

Phase 1

VMs

↓

Eureka

---

Phase 2

Kubernetes

+

Eureka

Everything still worked.

---

Phase 3

Remove Eureka

↓

Use Kubernetes DNS

Simpler architecture.

---

Why do companies migrate gradually?

Imagine you have:

• 80 microservices
• 300 developers
• Thousands of requests per second

You cannot remove Eureka in one day.

Instead:

Week 1

Move services to Kubernetes.

Week 2

Test everything.

Week 3

Update Feign clients.

Week 4

Remove Eureka.

This reduces migration risk.

---

What do modern companies do?

Nowadays, if a project starts directly on Kubernetes, they usually don’t introduce Eureka at all.

Typical stack:

Spring Boot

↓

OpenFeign

↓

http://payment-service

↓

Kubernetes DNS

↓

Kubernetes Service

↓

Payment Pods

No Eureka.

No Ribbon.

No Spring Cloud LoadBalancer (for Kubernetes service discovery).

---

Interview answer

If an interviewer asks:

Can we use Eureka with Kubernetes?

A good answer is:

“Yes, it’s technically possible and is often seen during migrations from VM-based deployments to Kubernetes. However, Kubernetes already provides native service discovery through Services and DNS, along with load balancing. Keeping Eureka adds duplicate infrastructure, extra configuration, and operational overhead without much benefit. That’s why most cloud-native applications remove Eureka after migrating to Kubernetes.”

That answer shows you understand both the old Netflix OSS architecture and the modern Kubernetes-native approach, which is exactly what many enterprise interviewers look for.