What Is a Kubernetes Deployment? Rolling Updates, Rollbacks, and EKS Examples

What is a Kubernetes Deployment?

A Deployment is a Kubernetes object that describes the application you want running. Once you create one, the Deployment controller continuously compares the actual state of the cluster with your description and corrects any differences.

If a pod crashes, the controller replaces it. If a node fails and takes several pods with it, replacements are scheduled on healthy nodes. If you push a new container image, the Deployment rolls it out gradually with no downtime. If the update causes problems, you can roll back to the previous version with a single command.

Deployments are the most commonly used workload object in Kubernetes and the default way to run containerised applications on Amazon EKS. If you have created your first EKS cluster and are ready to run an application, a Deployment is almost certainly what you need.

A simple way to think about Deployments

If you are new to Kubernetes, think of a Deployment as a standing instruction you give to the cluster:

• Describe the application you want running: the image, the port, the number of copies.
• Kubernetes accepts that description and keeps the cluster in exactly that state.
• If a pod dies, Kubernetes replaces it with no action needed from you.
• If you update the description with a new image version, Kubernetes updates the running pods gradually so traffic is never interrupted.

The alternative is creating pods directly. Bare pods are not restarted when they crash, so they are only suitable for one-off debugging. In production, always use a Deployment.

What a Deployment does

Desired state. You specify a replica count and a pod template. The Deployment controller watches the cluster and acts whenever the actual state diverges from your definition.

Self-healing. If a pod crashes or is evicted, the controller immediately schedules a replacement. If a node goes offline, replacements appear on healthy nodes. You do not need to write restart scripts or health-check automation.

Scaling. You can change the replica count at any time with kubectl scale or by editing the manifest. You can also attach a Horizontal Pod Autoscaler to scale the replica count automatically based on CPU or custom metrics.

Rolling updates. When you update the pod template, typically by changing the container image tag, the Deployment replaces pods incrementally. New pods are started and verified before old ones are removed. Your application stays available throughout.

Rollbacks. Kubernetes keeps a history of previous Deployment versions. If an update causes problems, a single kubectl command rolls back to the previous version using the same controlled process as the original update.

How a Deployment works with Pods and ReplicaSets

A Deployment does not manage pods directly. The relationship works in layers:

• Deployment manages one or more ReplicaSets
• ReplicaSets manage Pods

When you create a Deployment, it creates a ReplicaSet. The ReplicaSet is responsible for keeping the right number of pods running. The Deployment wraps the ReplicaSet and adds update logic on top.

When you update a Deployment by changing the container image, the Deployment creates a new ReplicaSet for the new version and gradually scales it up. At the same time, the old ReplicaSet is scaled down. Once the update completes, the old ReplicaSet is kept at zero replicas. It is not deleted.

This is what makes rollbacks fast. Kubernetes scales the old ReplicaSet back up and scales the current one down. No new images to pull, no new objects to create.

kubectl get replicasets -l app=my-app

You will see one active ReplicaSet with a matching replica count, and older ReplicaSets sitting at zero.

When to use a Deployment

Deployments are the right controller for most containerised workloads:

• Web applications: any HTTP server handling requests from users or other services
• REST and GraphQL APIs: stateless request handlers where any pod can serve any request
• Stateless microservices: services that do not need stable identity or per-pod persistent storage
• Background workers: event consumers or queue processors that run continuously

If your workload does not care which specific pod served a previous request, and it does not need persistent disk storage that survives pod restarts, a Deployment is the right choice.

When not to use a Deployment

Kubernetes provides other controllers for workloads that need something a Deployment cannot offer:

StatefulSet: use this when your pods need a stable network identity (fixed hostname and DNS name), ordered startup and shutdown, or persistent storage that stays bound to a specific pod identity across restarts. Databases, Kafka brokers, and Elasticsearch nodes typically use StatefulSets.

DaemonSet: use this when you need exactly one pod running on every node in the cluster. Typical uses are log collectors, node monitoring agents, and network plugins.

Job: use this when you need to run a task to completion rather than keep it running continuously. A Job runs one or more pods until they exit successfully.

CronJob: use this when you need to run a Job on a schedule. Batch reports, data exports, and scheduled cleanup tasks typically run as CronJobs.

Deployment vs Pod vs StatefulSet

This covers the most common points of confusion for people new to Kubernetes:

For most applications on EKS, you want a Deployment. If you are building something stateful like a database or message broker, reach for a StatefulSet instead.

Deployment YAML example

Here is a complete Deployment for a web application running three replicas on EKS:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: web-app
        version: "2.1.0"
    spec:
      containers:
      - name: web-app
        image: 123456789012.dkr.ecr.eu-west-1.amazonaws.com/web-app:2.1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: 200m
            memory: 256Mi
          limits:
            cpu: 1000m
            memory: 512Mi
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 15

Key fields explained:

• replicas: 3: the number of pod copies to keep running at all times.
• selector.matchLabels: must match the labels in template.metadata.labels. This is how the Deployment identifies which pods it owns.
• template.metadata.labels: applied to every pod this Deployment creates. Kubernetes Services use these labels to route traffic to the right pods.
• image: the container image URI. This example pulls from ECR. Always use a specific version tag, never latest.
• readinessProbe: Kubernetes only sends traffic to a pod once this probe passes. Without it, pods receive requests before they are ready to serve them.
• livenessProbe: Kubernetes restarts a pod if this probe fails. Used to detect hanging processes that are running but not responding.
• strategy.type: RollingUpdate: replace pods incrementally rather than all at once.
• maxSurge: 1: allow one extra pod above the desired count during an update. With 3 replicas, up to 4 pods run simultaneously during the rollout.
• maxUnavailable: 0: never reduce below the desired replica count during an update. Capacity stays at 100% throughout.

You can apply this manifest with kubectl or manage it through Helm. If your application needs secrets or credentials at runtime, see managing secrets in Kubernetes before deploying to production.

How rolling updates work

When you change the container image tag in a Deployment, the following sequence happens:

1. Kubernetes creates a new ReplicaSet with the updated pod template.
2. A new pod starts from the new image. Kubernetes waits for it to pass its readiness probe.
3. Once the new pod is ready and serving traffic, one old pod is gracefully terminated.
4. Steps 2 and 3 repeat until all pods are running the new version.
5. The old ReplicaSet is scaled to zero but kept in history for rollback.

With maxUnavailable: 0 and maxSurge: 1, capacity temporarily rises to 4 pods during the update but never drops below 3. Traffic flows uninterrupted throughout.

# Trigger an update by changing the container image
kubectl set image deployment/web-app web-app=123456789012.dkr.ecr.eu-west-1.amazonaws.com/web-app:2.2.0

# Watch the rollout progress in real time
kubectl rollout status deployment/web-app

# Check which ReplicaSets exist and their current replica counts
kubectl get replicasets -l app=web-app

For more complex release strategies that let you validate changes before a full rollout, see canary deployments and blue-green deployments.

How rollbacks work

If a deployment introduces a problem, roll back immediately:

# Roll back to the previous version
kubectl rollout undo deployment/web-app

# Roll back to a specific revision number
kubectl rollout undo deployment/web-app --to-revision=2

# View rollout history to find a revision number
kubectl rollout history deployment/web-app

A rollback is itself a rolling update. Kubernetes scales up the previous ReplicaSet and scales down the current one using the same controlled process. It is fast and safe, not an emergency restart.

kubectl annotate deployment/web-app kubernetes.io/change-cause="v2.2.0: added payment retry logic"

For visibility into rollout behaviour and pod health over time, connect EKS monitoring to your Deployment events. If you manage deployments through a CI/CD pipeline, rollbacks in CodeDeploy covers the equivalent rollback controls at the pipeline level.

RollingUpdate vs Recreate

Kubernetes supports two built-in deployment strategies:

RollingUpdate (default) replaces pods incrementally, keeping your application available throughout. Old and new pods run simultaneously for a brief window.

• Use this for: web apps, APIs, and any service that can tolerate two versions running in parallel
• Trade-off: API and schema changes must be backwards-compatible during the update window

Recreate terminates all existing pods before starting new ones. This causes a brief outage but guarantees only one version ever runs at a time.

• Use this for: applications that cannot tolerate mixed-version execution, such as a worker with a breaking database schema change
• Trade-off: your service is offline until new pods start and pass their readiness checks

# Recreate strategy - causes downtime during every deployment
strategy:
  type: Recreate