Recreate update strategy in Kubernetes - Step-by-Step Execution

Process Flow - Recreate update strategy

Start Deployment

↓

Delete all old Pods

↓

Wait for all old Pods to terminate

↓

Create new Pods

↓

Wait for new Pods to be Ready

↓

Deployment Complete

The Recreate update strategy deletes all old pods before creating new ones, ensuring no overlap between old and new versions.

Execution Sample

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deploy
spec:
  strategy:
    type: Recreate

This YAML snippet defines a Deployment using the Recreate update strategy to replace pods.

Process Table

Step	Action	Old Pods State	New Pods State	Deployment Status
1	Start Deployment	3 Running	0	In Progress
2	Delete all old Pods	3 Terminating	0	In Progress
3	Wait for old Pods to terminate	0	0	In Progress
4	Create new Pods	0	3 Pending	In Progress
5	New Pods become Ready	0	3 Running	Complete

💡 All old pods terminated and new pods are running, deployment complete.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
Old Pods	3 Running	3 Terminating	0	0	0
New Pods	0	0	0	3 Pending	3 Running
Deployment Status	Not Started	In Progress	In Progress	In Progress	Complete

Key Moments - 2 Insights

Why are all old pods deleted before new pods are created?

Because the Recreate strategy ensures no overlap between old and new pods to avoid conflicts, as shown in execution_table steps 2 and 4.

What happens if new pods fail to become ready after old pods are deleted?

Deployment will be stuck waiting at step 5, since the strategy waits for new pods to be ready before completing.

Visual Quiz - 3 Questions

Look at the execution table, what is the state of old pods at step 3?

A 3 pods running

B 0 pods running

C 3 pods terminating

D 0 pods pending

💡 Hint

Refer to the 'Old Pods State' column at step 3 in the execution_table.

At which step do new pods start to be created?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Check the 'Action' column for when new pods are created in the execution_table.

If the strategy was changed to RollingUpdate, how would the execution_table change?

A Old and new pods would run simultaneously during update

B All old pods would be deleted before new pods start

C New pods would never be created

D Deployment would complete immediately

💡 Hint

Recreate deletes old pods first; RollingUpdate allows overlap, so see difference in pod states.

Concept Snapshot

Recreate update strategy in Kubernetes:
- Deletes all old pods before creating new ones
- Ensures no overlap between old and new pods
- Deployment waits for old pods termination before new pods start
- Simple but causes downtime during update
- Defined in Deployment spec under strategy.type = Recreate

Full Transcript

The Recreate update strategy in Kubernetes replaces all old pods by first deleting them all, then creating new pods. This means there is downtime because no pods run during the switch. The deployment process starts by deleting old pods, waits for them to terminate, then creates new pods and waits for them to be ready before marking deployment complete. This strategy is simple and ensures no overlap between old and new versions, but causes downtime during updates.

Practice

1. What does the Recreate update strategy do in Kubernetes?

easy

A. Deletes old pods before creating new ones, causing downtime

B. Creates new pods first, then deletes old pods to avoid downtime

C. Updates pods one by one without deleting any

D. Scales pods up and down simultaneously during update

Solution

1. Step 1: Understand the Recreate strategy behavior

   The Recreate strategy deletes all old pods before starting new pods, which causes downtime.

2. Step 2: Compare with other strategies

   Other strategies like RollingUpdate create new pods before deleting old ones to avoid downtime, unlike Recreate.

3. Final Answer:

   Deletes old pods before creating new ones, causing downtime -> Option A

4. Quick Check:

   Recreate = delete old pods first [OK]

Hint: Recreate means delete old pods first, then create new [OK]

Common Mistakes:

• Confusing Recreate with RollingUpdate
• Thinking Recreate avoids downtime
• Assuming pods update one by one

2. Which YAML snippet correctly sets the update strategy to Recreate in a Deployment?

easy

A. strategy:\n type: RollingUpdate

B. strategy:\n type: Recreate

C. updateStrategy:\n type: Recreate

D. deploymentStrategy:\n type: Recreate

Solution

1. Step 1: Identify correct field name for update strategy

   The correct field under Deployment spec is strategy with a nested type.

2. Step 2: Check correct value for Recreate

   The value must be exactly Recreate to set that strategy.

3. Final Answer:

   strategy:\n type: Recreate -> Option B

4. Quick Check:

   strategy.type = Recreate [OK]

Hint: Use 'strategy.type: Recreate' exactly in Deployment spec [OK]

Common Mistakes:

• Using wrong field names like updateStrategy or deploymentStrategy
• Setting type to RollingUpdate instead of Recreate
• Incorrect indentation or YAML syntax

3. Given this Deployment with strategy.type: Recreate, what happens when you update the container image?

medium

A. Pods update one by one without downtime

B. New pods start first, then old pods terminate, no downtime

C. All old pods are terminated before new pods start, causing downtime

D. Pods scale up and down simultaneously

Solution

1. Step 1: Understand Recreate update behavior on image change

   When the image changes, Recreate deletes all old pods before creating new pods.

2. Step 2: Recognize downtime impact

   Because old pods are deleted first, there is downtime until new pods are ready.

3. Final Answer:

   All old pods are terminated before new pods start, causing downtime -> Option C

4. Quick Check:

   Recreate update = downtime during pod replacement [OK]

Hint: Recreate deletes old pods first, causing downtime on update [OK]

Common Mistakes:

• Assuming pods update without downtime
• Confusing with RollingUpdate behavior
• Thinking pods update one by one

4. You set strategy.type: Recreate but notice pods are not deleted before new ones start. What is the likely issue?

medium

A. The Deployment has maxUnavailable set to 0, causing RollingUpdate behavior

B. The Deployment is using StatefulSet instead of Deployment

C. The pods have readinessProbe misconfigured

D. The strategy type is misspelled or incorrectly set

Solution

1. Step 1: Check strategy type correctness

   If pods are not deleted first, the strategy type may be misspelled or set incorrectly, so Kubernetes defaults to RollingUpdate.

2. Step 2: Rule out other causes

   maxUnavailable affects RollingUpdate, readinessProbe affects pod readiness, and StatefulSet is a different resource type.

3. Final Answer:

   The strategy type is misspelled or incorrectly set -> Option D

4. Quick Check:

   Misspelled strategy.type causes default RollingUpdate [OK]

Hint: Check exact spelling of strategy.type: Recreate [OK]

Common Mistakes:

• Assuming maxUnavailable affects Recreate
• Ignoring YAML syntax errors
• Confusing Deployment with StatefulSet

5. You have an app that cannot run multiple versions simultaneously. How do you configure the Deployment update strategy to avoid version conflicts?

hard

A. Set strategy.type: Recreate to delete old pods before new ones

B. Set strategy.type: RollingUpdate with maxSurge=1

C. Use kubectl rollout restart without changing strategy

D. Set strategy.type: BlueGreen for zero downtime

Solution

1. Step 1: Identify app requirement

   The app cannot run multiple versions at the same time, so pods must not overlap.

2. Step 2: Choose update strategy

   Recreate deletes old pods before creating new ones, ensuring no version overlap.

3. Step 3: Rule out other options

   RollingUpdate allows overlapping versions, kubectl restart doesn't change strategy, BlueGreen is not a built-in Kubernetes strategy.

4. Final Answer:

   Set strategy.type: Recreate to delete old pods before new ones -> Option A

5. Quick Check:

   App needs no overlap = use Recreate [OK]

Hint: Use Recreate strategy to avoid running multiple versions [OK]

Common Mistakes:

• Choosing RollingUpdate which allows overlap
• Thinking kubectl restart changes update strategy
• Assuming BlueGreen is a native Kubernetes strategy