🔍Key Takeaways
- 1Service discovery solves 'how does Service A find Service B's IP address in a dynamic environment?'
- 2Client-side: client queries a registry and chooses a server; Server-side: load balancer queries the registry
- 3DNS-based is simplest but has TTL caching issues; dedicated registries (Consul, etcd) are more dynamic
- 4In Kubernetes, kube-dns + Services provide built-in service discovery
Finding Services in Dynamic Environments
In microservices, services are deployed across many hosts with dynamic IPs. Containers start, stop, and move constantly. Hardcoded IP addresses are impossible. Service discovery is the mechanism by which services locate each other.
Discovery Patterns
Client queries the service registry (Consul, etcd) for available instances of the target service. Client picks one (with client-side load balancing).
Pros: No extra network hop, client can implement smart routing.
Cons: Every client needs discovery logic, language-specific client libraries required.
Service Discovery Tools
| Tool | Type | Health Checks | Key Feature |
|---|---|---|---|
| Consul | Registry + DNS | HTTP, TCP, gRPC, script | Multi-DC, service mesh integration |
| etcd | Distributed KV store | Via watcher pattern | Used by Kubernetes, strong consistency (Raft) |
| ZooKeeper | Coordination service | Ephemeral nodes + sessions | Apache ecosystem, battle-tested |
| Kubernetes DNS | Built-in DNS | Readiness/liveness probes | Native to K8s, zero additional infra |
| AWS Cloud Map | Managed registry | Route 53 health checks | AWS-native, integrates with ECS/EKS |
Advantages
- •Enables dynamic, elastic microservice architectures
- •Automatic failover from unhealthy instances
- •Zero-config in Kubernetes
Disadvantages
- •Adds infrastructure complexity
- •Registry itself must be highly available
- •DNS caching creates stale routing
🧪 Test Your Understanding
Knowledge Check1/1
In Kubernetes, how is service discovery typically implemented?