How does service discovery work in Kubernetes without installing Consul or Eureka?
Kubernetes ships service discovery built into the cluster. You don''t need Consul, Eureka, or any 3rd-party client. The mechanism has three pieces:
1. Service resource registers a name
When you create a Service, Kubernetes assigns it a stable virtual IP and registers a DNS name in CoreDNS:
apiVersion: v1
kind: Service
metadata:
name: payments-api
spec:
selector: { app: payments-api }
ports: [{ port: 80, targetPort: 8080 }]
Other pods can now resolve payments-api (same namespace) or payments-api.payments.svc.cluster.local (full FQDN).
2. Endpoints are populated by readiness
Kubernetes watches every pod matching the Service''s selector. When a pod''s readinessProbe passes, its IP:port is added to the Service''s Endpoints list. When readiness fails, it''s removed — instantly, without restarting the pod.
3. kube-proxy load-balances
kube-proxy runs on every node and watches the Endpoints list. When a pod sends a request to the Service IP, kube-proxy (using iptables or IPVS) DNATs the connection to one of the healthy backing pods, round-robin by default.
Caller code: just an HTTP client
builder.Services.AddHttpClient<IPaymentsClient, PaymentsClient>(c =>
c.BaseAddress = new Uri("http://payments-api")); // no IP, no port, no library
The .NET service doesn''t know it''s on Kubernetes. The cluster handles everything below the URL.
Why this beats Consul/Eureka for most projects
- Zero extra components to install / operate.
- Works for any language — it''s just DNS + IP.
- Tied directly to readiness probes — drains are instant.
- Free, included in every managed Kubernetes (AKS, EKS, GKE).
Reach for Consul only when you have multi-cluster, multi-region, or hybrid (VM + K8s) discovery needs.