Kubernetes Services
Understand why Services exist, how selectors connect them to pods, and how stable networking hides pod churn.
Why Services Exist
Pods are ephemeral. They can be rescheduled, recreated, or assigned new IP addresses. If other applications talked directly to pod IPs, connectivity would break constantly.
A Service gives you:
- a stable virtual IP
- a stable DNS name
- load balancing across matching pods
How a Service Connects to Pods
A Service usually uses a selector to find matching pods. Kubernetes then builds an Endpoints object that lists the actual pod IPs behind the Service.
Service → Endpoints → Pods
Client
other pod / user
Service
my-svc:80
stable IP · DNS name
Endpoints
10.0.0.1:8080 · 10.0.0.2:8080
Pod A
Pod B
Why This Indirection Is Powerful
Clients talk to the stable Service address, not directly to changing pods. That means rolling updates and self-healing become much less disruptive.
Sub-pages in This Section
| Sub-topic | What you will learn |
|---|---|
| ClusterIP | Internal-only Services and DNS naming |
| NodePort | Expose Services on each node using a static port |
| LoadBalancer | Provision cloud load balancers for public access |
Common Service Idea
A Service does not run containers. It is a networking abstraction in front of pods.
Think of a Service like a company phone number. Employees may change desks, but the public still dials one stable number.
Main Reason
Why are Services important in Kubernetes?
Endpoints Role
What does the Endpoints object represent?