Stop 08 · Kubernetes & OrchestrationTopics · 2/12

Pods, Deployments & Services

In short

These three objects are 80% of daily Kubernetes work. Pods run your containers, Deployments keep the right number alive, and Services give them one stable address while pods come and go.

A Pod is the smallest deployable unit (one or more containers); a Deployment manages a set of replica Pods and handles rolling updates; a Service provides stable networking to reach Pods that come and go.

The mascot manages an auto-rickshaw stand, waving in a fresh auto to replace a broken one.

Think of it like this

The auto-rickshaw stand

The stand always keeps three autos waiting. One breaks down? The manager waves in a fresh one. Riders don't care which auto they get; they just walk to the stand. Autos are pods, the manager is the Deployment, and the stand is the Service.

Watch it happen

A pod dies, the Service doesn't care

Client

Service web

Pods

Deployment

GET http://web

1/5Other apps call the Service by its stable name. Its virtual IP never changes.

The big ideas

What you need to know

Pod

The smallest unit: one or more containers sharing an IP and volumes. Pods are disposable and rarely created by hand.

Deployment

Keeps N identical pods running through a ReplicaSet, and rolls out new versions a few pods at a time.

Service

A stable name and virtual IP in front of pods, chosen by labels. ClusterIP is internal, NodePort and LoadBalancer reach outside.

Labels glue it together

Deployments and Services find pods by labels like app: web. A typo in a label means traffic goes nowhere.

See it in code

Walk through the code

yaml

1apiVersion: apps/v12kind: Deployment3metadata: { name: web }4spec:5  replicas: 36  selector: { matchLabels: { app: web } }7  template:8    metadata: { labels: { app: web } }9    spec:10      containers: [{ name: web, image: "nginx:1.27" }]11---12apiVersion: v113kind: Service14metadata: { name: web }15spec: { selector: { app: web }, ports: [{ port: 80, targetPort: 80 }] }

1/4A Deployment called web that always wants three replicas.

Save as web.yaml and run kubectl apply -f web.yaml. Then try kubectl delete pod on one of them and watch a new one appear.

Save yourself the pain

Common mistakes

Oops

Creating bare pods with kubectl run for a real app.

Do this instead

Use a Deployment. A bare pod that dies stays dead, because nothing is watching to replace it.

Oops

Hardcoding a pod's IP in another app's config.

Do this instead

Always call the Service name, like http://web. Pod IPs change every time a pod is recreated.

Your mission

Kill a pod, keep the app

~25 min

Quick check

Your Service exists but has zero endpoints. What is the most likely cause?

Go deeper

1Deploy a simple application as a Pod, then convert it into a Deployment.
2Expose the Deployment with a Service and access it from within the cluster.
3Learn why you almost never create bare Pods directly in a real workflow — Deployments manage them for you.