Demo Rolling vs Recreate

In this hands-on demo you’ll see the practical difference between the RollingUpdate and Recreate deployment strategies in Kubernetes. We’ll deploy a small HTTP app that returns its version (v1 or v2) and observe behavior during an upgrade. This shows how each strategy affects availability and rollout behavior. What you’ll learn:

How to deploy a simple Deployment and Service
How RollingUpdate preserves availability during updates
How Recreate causes downtime by terminating all pods before creating new ones

Deployment manifest (patterns/release/deployment.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
  labels:
    app: app-demo
spec:
  replicas: 5
  selector:
    matchLabels:
      app: app-demo
  template:
    metadata:
      labels:
        app: app-demo
    spec:
      containers:
      - name: app
        image: siddharth67/app:v1
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 3311

Note: The manifest above omits a strategy section. Kubernetes defaults to the RollingUpdate strategy when strategy is not specified.

If you require zero-downtime updates, RollingUpdate is the default and preferred choice. The Recreate strategy will terminate all existing pods before creating new ones, which causes an interruption in service.

1) Clone the repo and apply resources

Run the commands below to prepare the demo namespace and apply the manifests:

# Clone the demos repo
git clone http://localhost:5000/kk-org/cgoa-demos
cd cgoa-demos/patterns/release

# Create namespace and apply deployment + service
kubectl create ns rolling-recreate
kubectl -n rolling-recreate apply -f .

Verify the resources were created:

kubectl -n rolling-recreate get all

Example output:

NAME                          READY   STATUS    RESTARTS   AGE
pod/app-8455fbd799-6xwx4      1/1     Running   0          9s
pod/app-8455fbd799-7qzmr      1/1     Running   0          9s
pod/app-8455fbd799-8vmj8      1/1     Running   0          9s
pod/app-8455fbd799-mjphc      1/1     Running   0          9s
pod/app-8455fbd799-nrc9f      1/1     Running   0          9s

NAME                 TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
service/app-service  NodePort   10.106.209.30    <none>        80:32431/TCP   9s

NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/app  5/5     5            5           9s

The app exposes a simple endpoint (/app) that returns the version string:

A web browser window displaying a centered banner that reads "Application Version: v1" in large blue text inside a rounded, blue-outlined box on a light blue gradient background. The address bar shows a localhost URL.

2) Poll the endpoint continuously to observe updates

Use the following shell loop to poll the NodePort and colorize v1 / v2 responses. Replace the NodePort (32431) if yours differs.

while true; do
  echo -n "$(date '+%H:%M:%S') - "
  curl -s --max-time 1 http://localhost:32431/app 2>/dev/null | \
  awk '{
    if (/^Application Version:/) {
      if ($0 ~ /v1/) print "\033[34m" $0 "\033[0m";
      else if ($0 ~ /v2/) print "\033[33m" $0 "\033[0m";
      else print $0;
    } else {
      print "\033[31mERROR: Service unreachable\033[0m"
    }
  }'
  sleep 1
done

Leave the loop running in a terminal. This will make the effect of each update immediately visible.

3) Rolling update (no downtime)

Because RollingUpdate is the default strategy, updating the Deployment image will perform a rolling upgrade: new pods are created and traffic shifts gradually from old pods to new pods. Update the image to v2 using kubectl set image:

kubectl -n rolling-recreate set image deployment/app app=siddharth67/app:v2

kubectl will respond:

deployment.apps/app image updated

Sample polling output (shows continuous responses transitioning from v1 to v2 without downtime):

16:34:14 - Application Version: v1
16:34:15 - Application Version: v1
...
16:34:32 - Application Version: v2
16:34:33 - Application Version: v2
...

Explanation: RollingUpdate creates new pods running v2 while terminating old v1 pods in a controlled manner, maintaining service availability during the rollout.

4) Recreate strategy (introduce downtime)

To demonstrate downtime, change the Deployment strategy to Recreate. Edit the deployment:

kubectl -n rolling-recreate edit deployment app

Add or modify the strategy section in the spec:

strategy:
  type: Recreate

Save the edit. Confirm the deployment now uses Recreate:

kubectl -n rolling-recreate get deploy app -o yaml

You should see:

spec:
  replicas: 5
  strategy:
    type: Recreate

Now update the image again (flip it back to v1 to see downtime):

kubectl -n rolling-recreate set image deployment/app app=siddharth67/app:v1

kubectl will report:

deployment.apps/app image updated

Behavior: With Recreate, Kubernetes terminates all existing pods immediately and only then creates the new pods. During the gap between pod termination and the new pods becoming Ready, the Service has no ready endpoints and will return timeouts or errors. Example polling output showing downtime:

35:30 - Application Version: v2
35:31 - Application Version: v2
35:32 - ERROR: Service unreachable
35:33 - ERROR: Service unreachable
35:34 - Application Version: v1
35:35 - Application Version: v1

Using the Recreate strategy will cause downtime because all old pods are terminated before new pods are created. Use Recreate only when you must avoid running multiple versions concurrently and can tolerate interruptions.

Comparison: RollingUpdate vs Recreate

Strategy	Behavior during update	Use case
RollingUpdate	Gradually replaces pods; maintains availability	Zero-downtime updates; safe in production
Recreate	Terminates all old pods, then creates new ones (downtime)	When concurrent versions must not coexist

References

Summary

RollingUpdate (default): incrementally updates pods and preserves availability.
Recreate: shuts down all existing pods first, then starts new ones — which causes downtime.

This concludes the demo showing the practical differences between RollingUpdate and Recreate strategies for Kubernetes Deployments.

ArgoCD

Argo Workflow

Argo Rollouts

Argo Events

Introduction

Demo Rolling vs Recreate

1) Clone the repo and apply resources

2) Poll the endpoint continuously to observe updates

3) Rolling update (no downtime)

4) Recreate strategy (introduce downtime)

Comparison: RollingUpdate vs Recreate

References

Watch Video

Practice Lab

​1) Clone the repo and apply resources

​2) Poll the endpoint continuously to observe updates

​3) Rolling update (no downtime)

​4) Recreate strategy (introduce downtime)

​Comparison: RollingUpdate vs Recreate

​References

Watch Video

Practice Lab

1) Clone the repo and apply resources

2) Poll the endpoint continuously to observe updates

3) Rolling update (no downtime)

4) Recreate strategy (introduce downtime)

Comparison: RollingUpdate vs Recreate

References