Service Discovery and Configuration
The Problem
In dynamic environments (Kubernetes, auto-scaling), service IPs change constantly. How does Service A find Service B?
Service Discovery Patterns
| Pattern | How | Example |
|---|---|---|
| DNS-based | Services register DNS names, resolved at call time | Kubernetes Services (ClusterIP) |
| Registry-based | Services register with a registry, clients query it | Consul, etcd, Eureka, NRF (5G) |
| Sidecar/Mesh | Proxy handles discovery transparently | Istio/Envoy service mesh |
Kubernetes Service Discovery
# Service A calls Service B by DNS name:
http://order-service.default.svc.cluster.local:8080/orders
# Kubernetes DNS resolves to current pod IPs
# kube-proxy load-balances across healthy podsConfiguration Management
- Environment variables: simple, 12-factor app style
- Config files: mounted via ConfigMaps (K8s)
- Config service: centralized (Consul KV, Spring Cloud Config)
- Feature flags: toggle features without deploy (LaunchDarkly, Unleash)
💡 Telecom Parallel
The NRF (Network Repository Function) in 5G SBA IS a service registry. NFs register their profiles, and other NFs discover them via NRF queries. Same pattern as Consul/etcd.
Key Takeaways
- Service discovery: how services find each other in dynamic environments
- Kubernetes DNS is the simplest solution in K8s environments
- Service mesh (Istio) handles discovery + load balancing + security transparently
- Configuration: env vars for simple, config service for complex/dynamic