Introduction

Eureka and Kubernetes both help distributed systems find running services, but they solve that problem at different layers. Understanding the difference matters because many teams add both, then discover they are maintaining duplicate discovery systems without a clear reason.

What Each Tool Actually Does

Eureka is an application-level service registry. A service instance starts, registers itself, sends heartbeats, and clients query the registry to find healthy instances. This model came from the Netflix OSS stack and works well when services run on virtual machines or mixed environments.

Kubernetes is a container orchestrator. It already tracks pods, health, endpoints, and networking. A Kubernetes Service object gives you stable discovery through cluster DNS, so most in-cluster applications can call another service by name without an external registry.

1apiVersion: v1
2kind: Service
3metadata:
4  name: orders
5spec:
6  selector:
7    app: orders
8  ports:
9    - port: 8080
10      targetPort: 8080

With that service in place, another pod in the same namespace can reach http://orders:8080. Across namespaces, the full DNS name is typically orders.default.svc.cluster.local.

When Kubernetes Replaces Eureka

If all your services run inside one cluster, Kubernetes usually makes Eureka unnecessary. Readiness probes decide whether a pod should receive traffic, and kube-dns resolves the service name to the current healthy endpoints.

For a Spring Boot service, the client code can be very simple because it only needs the Kubernetes service name.

1spring:
2  application:
3    name: gateway
4
5orders:
6  base-url: http://orders:8080

1import java.net.URI;
2import java.net.http.HttpClient;
3import java.net.http.HttpRequest;
4import java.net.http.HttpResponse;
5
6public class OrdersClient {
7    private final HttpClient client = HttpClient.newHttpClient();
8
9    public String fetchOrders() throws Exception {
10        HttpRequest request = HttpRequest.newBuilder()
11            .uri(URI.create("http://orders:8080/api/orders"))
12            .build();
13
14        return client.send(request, HttpResponse.BodyHandlers.ofString()).body();
15    }
16}

This is simpler than adding a registry server, client libraries, heartbeats, and registry tuning.

When Eureka Still Makes Sense

Eureka can still be justified when your topology is mixed. For example, you may have some services in Kubernetes, some on virtual machines, and some consumed by clients that already depend on Spring Cloud Netflix. In that case, Eureka becomes a registry that spans environments, while Kubernetes still handles orchestration for the containerized part.

If you combine them, the main task is publishing pod-reachable addresses into Eureka. A pod restarting on a new IP is normal in Kubernetes, so registration data must follow the live pod identity.

1env:
2  - name: EUREKA_INSTANCE_PREFER_IP_ADDRESS
3    value: "true"
4  - name: EUREKA_INSTANCE_IP_ADDRESS
5    valueFrom:
6      fieldRef:
7        fieldPath: status.podIP

That configuration helps a Eureka client advertise the current pod IP instead of a hostname that other services cannot resolve.

Operational Tradeoffs

Running both systems means more moving parts. Kubernetes already knows health and endpoint state. Eureka also tracks health and lease expiry. If those systems disagree, troubleshooting becomes harder. You need to ask whether a call failed because the pod was unready, because the service had no endpoints, or because Eureka still exposed a stale instance.

A good rule is simple: use one discovery authority when possible. Inside Kubernetes, that authority should usually be Kubernetes itself. Add Eureka only when you have a real integration boundary that cluster DNS cannot cover cleanly.

Common Pitfalls

• Running Eureka inside Kubernetes without a clear cross-environment need usually adds complexity without adding useful capability.
• Registering hostnames that are not resolvable from other pods causes intermittent client failures.
• Ignoring readiness probes means Kubernetes may route traffic differently from what Eureka reports.
• Hard-coding pod IP addresses in configuration breaks as soon as pods restart or reschedule.
• Treating service discovery and load balancing as the same concern leads to unclear ownership between application code and cluster networking.

Summary

• Eureka is an application-level registry, while Kubernetes provides platform-level service discovery.
• In a pure Kubernetes deployment, cluster DNS and Service objects usually replace Eureka.
• Eureka is still reasonable for hybrid environments or legacy Spring Cloud ecosystems.
• If both are used, registration data must reflect the current pod identity and network reachability.
• Keeping one discovery system as the source of truth reduces operational confusion.