Kubernetes Services: Stable Networking and Service Discovery for Transient Pods
A Service provides a stable network endpoint (fixed IP + DNS name) for a dynamic set of pods — because pod IPs change every time a pod is restarted, replaced...
Quick Answer: A Service provides a stable network endpoint (fixed IP + DNS name) for a dynamic set of pods — because pod IPs change every time a pod is restarted, replaced, or rescheduled.
Detailed Answer:
Pods are ephemeral — every time a pod is replaced (update, crash, reschedule), it gets a new IP address. If Service A needs to talk to Service B, it can't hardcode pod IPs. A Service solves this by:
- Selecting pods via label selector — always pointing to the current healthy pods
- Providing a stable ClusterIP — a virtual IP that never changes
- Registering a DNS name —
my-svc.my-namespace.svc.cluster.local - Load balancing — distributing traffic across all matching pods
apiVersion: v1
kind: Service
metadata:
name: my-app-svc
namespace: production
spec:
selector:
app: my-app # Finds all pods with this label
ports:
- name: http
port: 80 # Port the Service listens on
targetPort: 8080 # Port on the Pod
protocol: TCP
type: ClusterIP # Internal only (default)
# How Services find pods — via Endpoints
kubectl get endpoints my-app-svc
# NAME ENDPOINTS AGE
# my-app-svc 10.0.1.5:8080,10.0.1.6:8080,... 5m
# If endpoints are empty → label selector doesn't match any pods
# This is one of the most common networking bugs in Kubernetes
The DNS Magic:
CoreDNS automatically creates DNS records for every Service:
my-app-svc → resolves within same namespace
my-app-svc.production → resolves from any namespace
my-app-svc.production.svc.cluster.local → fully qualified, always works
Key Takeaway: Services decouple consumers from the dynamic pod infrastructure — always communicate with Services, never with pod IPs directly.
Finished reading?
Mark as complete to claim your +10 XP and track progress.