Understanding Kubernetes Pods and Deployments

1Understanding Kubernetes Pods and Deployments

In Kubernetes, a Pod is the smallest thing you can deploy — one or more containers that share a network address and storage and are always scheduled together. A Deployment is a higher-level object that manages Pods for you, ensuring the right number are running and handling updates. In short: Pods run your containers, and Deployments keep those Pods healthy.

You almost never create Pods by hand. You describe a Deployment, and Kubernetes creates, replaces, and scales the underlying Pods automatically to match what you asked for.

2What Is a Pod?

A Pod is a wrapper around one or more containers that must live and die together. Containers in the same Pod share an IP address, ports, and mounted volumes, so they can communicate over localhost as if on the same machine.

Most Pods hold a single container. The multi-container case is for tightly coupled helpers — a sidecar that ships logs, or an init container that prepares data before the main container starts. If two containers do not need to share resources this closely, they belong in separate Pods.

3Why Not Create Pods Directly?

A bare Pod has no safety net. If it crashes or its node fails, nothing brings it back — it simply disappears along with your workload.

• No self-healing: a crashed standalone Pod is not recreated.
• No scaling: you cannot ask for more copies without creating each by hand.
• No rolling updates: changing the image means deleting and recreating manually.
• No rollback: there is no record of previous versions to revert to.

4What Is a Deployment?

A Deployment is a controller that manages a set of identical Pods, keeping the number you asked for running at all times. You declare the desired state — which image, how many replicas — and Kubernetes works continuously to make reality match.

If a Pod dies, the Deployment notices and starts a replacement. If you change the image, it rolls the change out gradually. This declarative, self-healing behaviour is the reason Deployments are the standard way to run stateless apps.

• Desired state: you specify the image and replica count.
• Self-healing: dead Pods are replaced automatically.
• Scaling: change the replica number and Kubernetes adjusts.
• Rolling updates: new versions roll out Pod by Pod with health checks.

5How Pods, ReplicaSets, and Deployments Fit Together

There is one more object in the chain. A Deployment does not manage Pods directly — it manages a ReplicaSet, which manages the Pods. Understanding this layering explains how updates and rollbacks work.

6A Deployment Manifest

Deployments are defined in YAML and applied with kubectl apply. This example runs three replicas of an nginx container.

Apply it with kubectl apply -f deployment.yaml, and Kubernetes creates the ReplicaSet and three Pods, then keeps them running.

• 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

7Common Commands

A handful of kubectl commands cover everyday work with Deployments and Pods.

• kubectl apply -f deployment.yaml # create or update the Deployment
• kubectl get pods # list running Pods
• kubectl scale deployment web --replicas=5 # scale up
• kubectl set image deployment/web web=nginx:1.28 # rolling update
• kubectl rollout undo deployment/web # roll back the last update
• kubectl logs <pod-name> # view a Pod's logs

8Best Practices

A few habits keep Deployments reliable and updates safe.

• Always run workloads through a Deployment, never as bare Pods.
• Define readiness and liveness probes so rolling updates wait for healthy Pods.
• Set resource requests and limits so the scheduler places Pods sensibly.
• Pin image tags rather than using latest for predictable rollouts.
• Run multiple replicas so a single Pod or node failure is survivable.

9Common Mistakes to Avoid

Newcomers to Kubernetes tend to trip over the same issues.

• Creating bare Pods that vanish on failure with no self-healing.
• Omitting readiness probes, so traffic reaches Pods before they are ready.
• Running a single replica, turning any Pod failure into downtime.
• Using the latest tag, making rollouts and rollbacks unpredictable.

10Key Takeaways

The essentials of Pods and Deployments come down to a few points.

• A Pod is the smallest deployable unit — containers that share network and storage.
• Pods are ephemeral; never rely on a single one or create them directly.
• A Deployment manages Pods, keeping the desired number running and healing failures.
• Deployments create ReplicaSets, which create Pods, enabling rolling updates and rollback.
• Use probes, resource limits, pinned tags, and multiple replicas for reliable workloads.

11Frequently Asked Questions

Q: What is the difference between a Pod and a Deployment? A: A Pod is the smallest unit that runs your containers. A Deployment is a controller that manages Pods — keeping the right number running, healing failures, and handling updates. You define Deployments; they create Pods for you.

Q: Can a Pod have more than one container? A: Yes. Containers in one Pod share network and storage and run together, which suits tightly coupled helpers like a logging sidecar or an init container. Most Pods, however, hold a single container.

Q: What is a ReplicaSet? A: A ReplicaSet ensures a specified number of identical Pods are running. Deployments create and manage ReplicaSets for you; the layering is what makes rolling updates and quick rollbacks possible.

Q: How do rolling updates work? A: When you change a Deployment, it creates a new ReplicaSet and shifts Pods from old to new gradually, checking health along the way. If something fails, kubectl rollout undo scales the previous ReplicaSet back up.