Services & Networking
Pods come and go — a Service gives them one stable front door.
Pods are disposable and their IP addresses change every time they’re recreated. So how does the rest of your system reliably reach them? The answer is a Service — a stable network endpoint that always points to a healthy set of Pods.
🎯 Learning Objectives
By the end of this lesson you will:
- Understand why Services exist
- Know the Service types: ClusterIP, NodePort, LoadBalancer
- Understand how Services find Pods using labels
- Know what an Ingress adds on top
Why Services Exist
Each Pod gets its own IP, but that IP disappears when the Pod is replaced. If your frontend hard-coded a backend Pod’s IP, it would break constantly.
A Service solves this: it has a stable IP and DNS name, and automatically load-balances across whatever healthy Pods currently match its label selector.
Frontend ──▶ Service (stable) ──┬──▶ Pod (changes)
backend:80 ├──▶ Pod (changes)
└──▶ Pod (changes)How a Service Finds Pods
Services use labels, not IPs. The Service’s selector matches the labels on the Pods:
apiVersion: v1
kind: Service
metadata:
name: backend
spec:
selector:
app: web # match Pods labelled app=web
ports:
- port: 80 # the Service port
targetPort: 80 # the Pod's container portAny Pod with the label app: web is automatically added to this Service — no matter when it was created or what its IP is.
💡 Service discovery by DNS
Inside the cluster, other Pods reach this Service simply as backend (or backend.namespace.svc.cluster.local). Kubernetes runs an internal DNS that resolves Service names automatically.
The Service Types
| Type | Reachable from | Use for |
|---|---|---|
| ClusterIP (default) | Inside the cluster only | Internal communication between services |
| NodePort | A port on every node’s IP | Simple external access / testing |
| LoadBalancer | A cloud load balancer with a public IP | Production external access on cloud |
# Expose the deployment as different service types
kubectl expose deployment web --port=80 --type=ClusterIP
kubectl expose deployment web --port=80 --type=NodePort
kubectl expose deployment web --port=80 --type=LoadBalancerIngress — Smart HTTP Routing
Giving every service its own cloud LoadBalancer is expensive. An Ingress is a single entry point that routes HTTP traffic to many services based on hostname or path:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-ingress
spec:
rules:
- host: shop.example.com
http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: backend
port:
number: 80
- path: /
pathType: Prefix
backend:
service:
name: frontend
port:
number: 80💡 Ingress needs a controller
An Ingress object is just rules. You also need an Ingress controller (like NGINX Ingress or Traefik) running in the cluster to actually enforce them. It handles TLS termination and routing for all your services at once.
🧪 Hands-on Lab
Expose an App Internally and Externally
- Create a ClusterIP Service for your
webDeployment - Verify another Pod can reach it by the Service name
- Create a LoadBalancer Service and note the external IP
🧠 Knowledge Check
How does a Service know which Pods to send traffic to?
You want a single entry point that routes shop.example.com/api and shop.example.com/ to different services. What do you use?
💼 Interview Preparation
Explain how traffic flows from a user's browser to a Pod in Kubernetes.
Summary
You now understand how Services give Pods a stable address, the ClusterIP / NodePort / LoadBalancer types, label-based selection, and how Ingress routes external HTTP traffic. Next, you’ll handle configuration and scaling with ConfigMaps, Secrets, and autoscaling.