Definition
- Eureka -- each instance registers with the server, renews a lease via heartbeats (default 30s), and is evicted when heartbeats stop; clients query for instances and load-balance client-side.
- Self-preservation -- during a partition, Eureka keeps stale registrations rather than emptying the registry (AP choice).
- Kubernetes -- a Service object + readiness probes + CoreDNS; the platform tracks ready pods and resolves the service name; no library needed.
- Eureka: library + server -- heartbeats, client-side LB, works anywhere.
- K8s: platform-native -- DNS + probes, server-side/kube-proxy LB, only works in-cluster.
- When Eureka -- off-K8s, multi-cloud, gradual migration.
Eureka is a central phone directory: every branch phones in when it opens and keeps calling to say 'still open.' Kubernetes is a smart building that knows which rooms are staffed. If your branches are in different buildings run by different companies, you still need the phone directory.
Understanding the Concepts
How does Eureka work?
Registration and heartbeats
// Spring Cloud Eureka client: auto-registers on startup
@SpringBootApplication
@EnableDiscoveryClient
public class TransferServiceApplication {
public static void main(String[] args) {
SpringApplication.run(TransferServiceApplication.class, args);
}
}
// application.yml:
// eureka.client.service-url.defaultZone: http://eureka-server:8761/eureka
// Instance registers, sends heartbeat every 30s, lease expires if missed
Client-side discovery
// Caller fetches instances, load-balances locally
List<ServiceInstance> instances = discoveryClient.getInstances("transfer-service");
ServiceInstance chosen = instances.get(rng.nextInt(instances.size()));
String url = chosen.getUri() + "/api/v1/transfers";
How does Kubernetes-native discovery work?
# The Service IS the discovery mechanism
apiVersion: v1
kind: Service
metadata:
name: transfer-service
spec:
selector:
app: transfer
ports:
- port: 80
targetPort: 8080
# Caller just does: http://transfer-service/api/v1/transfers
# CoreDNS resolves it to ready pod endpoints
How do they compare?
| Aspect | Eureka | Kubernetes |
|---|---|---|
| Registration | Application heartbeats (library) | Platform readiness probes |
| Discovery | Client queries registry | DNS resolution (CoreDNS) |
| Load balancing | Client-side | Server-side (kube-proxy) |
| Extra server | Eureka cluster required | None (platform-native) |
| Consistency model | AP (keeps stale registrations) | Endpoint controller (consistent) |
| Works where | Anywhere with a network | Inside K8s cluster only |
When do you still need Eureka?
// Off-Kubernetes: services on VMs or bare metal → need Eureka
// Multi-cloud: no single K8s cluster spans all environments → need Eureka
// Gradual migration: some services in K8s, some on VMs → Eureka as the bridge
// Fully on single K8s cluster: Eureka is redundant complexity
What is self-preservation?
During a network partition, Eureka stops evicting instances because it cannot tell 'instance died' from 'network blip.' It keeps stale registrations on the theory that a stale list is safer than an empty one.
What are common mistakes?
// WRONG: adding Eureka in a greenfield single-cluster K8s deployment
// K8s already provides discovery; Eureka adds a server to operate for no benefit
// WRONG: hardcoding instance addresses
String url = "http://10.0.1.42:8080/api/transfers"; // dies when instance moves
// CORRECT: use logical service names resolved by discovery
String url = "http://transfer-service/api/transfers";
What should a senior engineer know?
- Service discovery is the same problem everywhere: find healthy instances and route to them.
- The right tool is whatever already owns your runtime: K8s-native when on K8s, Eureka when not.
- During migration, Eureka bridges both worlds; retire it per service once fully in-cluster.
- Never hardcode addresses; always resolve by logical name.
Visual Overview
Eureka (Library + Server)
┌──────────────┐ register + heartbeat ┌──────────────┐
│ Instance-1 │ ──────────────────────► │ Eureka │
│ Instance-2 │ ──────────────────────► │ Server │
│ Instance-3 │ └──────┬───────┘
└──────────────┘ │ query
┌──────▼───────┐
│ Client │
│ (cache + │
│ client LB) │
└──────────────┘
Kubernetes (Platform-Native)
┌──────────────┐ readiness probe ┌──────────────┐
│ Pod-1 │ ◄─────────────── │ Endpoint │
│ Pod-2 │ ◄─────────────── │ Controller │
│ Pod-3 │ └──────┬───────┘
└──────────────┘ │ DNS
┌──────▼───────┐
│ CoreDNS │
│ resolves │
│ service name │
└──────────────┘
No extra server, no library, no heartbeat code
Key Takeaway
Eureka is a self-registration service registry with heartbeat leases. Each instance registers on startup, sends heartbeats to renew a lease, and is evicted when heartbeats stop. Clients query the registry, cache it locally, and load-balance client-side. Eureka favors availability over consistency: during a partition it keeps stale registrations rather than emptying the registry.
Kubernetes-native discovery removes the separate registry by making discovery a platform capability. A Service object plus readiness probes plus CoreDNS tracks ready pods and resolves the service name. No registration library, no heartbeat code. The crucial difference is that Eureka is a library plus a server you operate, while Kubernetes is built-in.
Use Eureka when you are not on Kubernetes (VMs, bare metal), span multiple clouds, or during a gradual migration. In a greenfield single-cluster Kubernetes deployment, Eureka is usually redundant complexity. At National Bank of India, Eureka bridged VM-based services and Kubernetes services during migration, and was retired per service once fully in-cluster.
Remember one sentence: Eureka is a self-registration directory with heartbeat leases for client-side discovery; Kubernetes bakes the same capability into the platform with Services and CoreDNS; use Eureka off-Kubernetes, across clouds, or mid-migration.
---