IntermediateIn-depth4 min readUpdated 2 Oct 2026

What is the difference between a Pod, a Deployment and a Service in Kubernetes?

SHORT ANSWER

A Pod is the smallest unit Kubernetes runs, one or more containers sharing an IP address. A Deployment keeps a chosen number of identical Pods running and handles rolling updates. A Service gives those changing Pods one stable name and IP and load-balances traffic across them.

Explain it simply

Think of a call centre. Each Pod is one agent at a desk. Agents come and go: someone falls sick, someone new joins. A Deployment is the shift manager whose rule is "there must always be five agents on the floor". If one leaves, the manager brings in a replacement. If the training changes, the manager swaps agents one by one so the floor is never empty. A Service is the single helpline number customers call. Customers never need to know which agent picks up; the number routes them to whoever is free.

Example

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP

bash

kubectl apply -f web.yaml
kubectl get deployments,pods,services
kubectl set image deployment/web web=nginx:1.28   # rolling update
kubectl rollout undo deployment/web               # roll back

Any other Pod in the same namespace can now call http://web, and Kubernetes spreads those requests across the three Pods.

How it works

Pod. Containers in a Pod share a network namespace, so they share one IP address and can talk over localhost. They can also share volumes. Usually a Pod has one main container, sometimes with a helper "sidecar" (for example, a log shipper). Pods are disposable: if a node dies, its Pods are gone, and a new Pod gets a new IP.

Deployment. You declare the desired state: this image, this many replicas. The Deployment creates a ReplicaSet, and the ReplicaSet creates and replaces Pods to match the count. On a new image, the Deployment creates a new ReplicaSet and shifts Pods over gradually, controlled by maxSurge and maxUnavailable. The old ReplicaSet is kept so you can roll back.

Service. Since Pod IPs keep changing, clients need something stable. A Service picks Pods by label selector (app: web here), gets a stable virtual IP and a DNS name, and forwards traffic to the healthy matching Pods. Common types:

ClusterIP (default): reachable only inside the cluster.
NodePort: opens the same port on every node.
LoadBalancer: asks the cloud provider for an external load balancer.

For HTTP routing by hostname or path from outside, you usually put an Ingress or Gateway in front of ClusterIP Services.

Real-world use

An e-commerce site might run its checkout API as a Deployment with ten replicas during a sale and three at night. The frontend calls http://checkout through a Service and never cares which Pods exist. When the team ships a fix, the rolling update replaces Pods with zero downtime, and if error rates jump they run kubectl rollout undo.

Common mistakes

Creating bare Pods in production. Nothing recreates them when they die; use a Deployment.
A Service selector that does not match the Pod labels, so the Service has no endpoints and requests fail.
Calling Pod IPs directly instead of the Service name.
Using a Deployment for a database that needs stable identity and its own disk per replica. That is what a StatefulSet is for.
Thinking a Service runs as a process. It is a set of routing rules, programmed into each node by kube-proxy or a CNI plugin.

What to say in the interview

"A Pod is the smallest deployable unit, one or more tightly coupled containers sharing a network namespace and storage. Pods are ephemeral. A Deployment manages Pods declaratively through ReplicaSets: it keeps the desired number of replicas running, replaces failed Pods, and does rolling updates and rollbacks. A Service gives a stable virtual IP and DNS name to a set of Pods selected by labels and load-balances across them, so clients are not affected when Pods are replaced. So Deployment handles how many Pods run, and Service handles how you reach them."

Follow-up questions

What is the difference between a Deployment and a StatefulSet?
How does a Service know which Pods to send traffic to?
What is the difference between a Service of type LoadBalancer and an Ingress?
How would you scale a Deployment automatically?

Go deeper

Read these once the basics above feel easy.

A Service is backed by EndpointSlice objects that list the current ready Pod IPs. kube-proxy watches them and writes iptables or IPVS rules on every node, so the "load balancing" happens in the kernel of whichever node sends the traffic. A headless Service (clusterIP: None) skips the virtual IP and returns Pod IPs directly in DNS, which StatefulSets use to give each Pod a stable name like db-0.db.

#kubernetes #pods #deployments #services