Introduction

In Kubernetes, a rollout is the process of applying a change to a workload gradually and tracking that change until the new version is fully running. Most often, people mean a Deployment rollout, where Kubernetes creates a new ReplicaSet, shifts pods from the old version to the new one, and lets you monitor or undo the update if something goes wrong.

What Actually Changes During a Rollout

A rollout starts when the Deployment template changes. Common triggers are:

• a new container image
• changed environment variables
• updated labels or annotations in the pod template
• modified resource requests or limits

For example:

kubectl set image deployment/web web=nginx:1.27

That command changes the pod template, so Kubernetes creates a new ReplicaSet and begins replacing old pods with new ones.

RollingUpdate Versus Recreate

The default rollout strategy for a Deployment is RollingUpdate. That means Kubernetes does not destroy everything at once. Instead, it controls how many old pods may go down and how many extra new pods may come up during the transition.

A typical strategy looks like this:

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: web
5spec:
6  replicas: 4
7  strategy:
8    type: RollingUpdate
9    rollingUpdate:
10      maxUnavailable: 1
11      maxSurge: 1

With this configuration, Kubernetes can take at most one old pod offline and create at most one additional new pod beyond the desired replica count while the rollout is in progress.

Recreate is the simpler alternative. Kubernetes stops the old pods first and then starts the new ones. That is easier to reason about but usually means downtime.

How to Observe a Rollout

You do not have to guess what Kubernetes is doing. The basic commands are:

1kubectl rollout status deployment/web
2kubectl rollout history deployment/web
3kubectl get rs
4kubectl get pods

rollout status tells you whether the update has completed. rollout history shows previous revisions. Looking at ReplicaSets is often useful because it makes the old-to-new handoff visible.

Rollback Is Part of the Feature

A rollout is not only about pushing changes forward. Kubernetes also lets you undo a bad deployment:

kubectl rollout undo deployment/web

That returns the deployment to the previous revision. Rollback works best when your deployments are image-versioned clearly and when application startup probes and readiness probes accurately reflect whether the new version is healthy.

Readiness Matters

A rollout is only as safe as the signals Kubernetes uses to judge pod health. If a pod reports ready too early, traffic may shift to a container that is still warming up or still failing internally.

A good readiness probe makes rollouts safer:

1readinessProbe:
2  httpGet:
3    path: /healthz
4    port: 8080
5  initialDelaySeconds: 5
6  periodSeconds: 5

Without good readiness behavior, a rollout can look successful from the control plane while users still see failures.

Rollout Is Not the Same as a Full Release Strategy

Kubernetes Deployment rollouts handle the pod replacement mechanics. They are not the same thing as canary releases, blue-green deployments, or progressive delivery platforms, even though those strategies may build on the same primitives.

So when someone asks "what is a rollout," the direct answer is: it is Kubernetes updating a workload revision and managing the transition from old pods to new pods.

Common Pitfalls

• Assuming any change triggers a rollout is incorrect; the pod template has to change for a new rollout revision to begin.
• Treating a rollout as safe without readiness probes is risky because Kubernetes may advance even while the app is not truly ready for traffic.
• Using Recreate unintentionally can cause avoidable downtime.
• Forgetting to watch ReplicaSets makes rollout debugging harder when old pods do not disappear or new pods never become ready.
• Thinking rollout and rollback are separate concepts misses the point that Kubernetes deployments are designed to support both.

Summary

• A rollout is Kubernetes applying a new workload revision, usually through a Deployment.
• The default RollingUpdate strategy replaces pods gradually instead of all at once.
• 'kubectl rollout status, history, and undo are the core operational commands.'
• Readiness probes are critical because they determine whether the new pods are actually safe to serve traffic.
• Rollouts manage version transitions; higher-level release strategies may add more control on top of them.