Recreate update strategy in Kubernetes - Deep Dive

Overview - Recreate update strategy

What is it?

The Recreate update strategy in Kubernetes is a way to update applications by stopping all existing instances before starting new ones. Instead of running old and new versions together, it shuts down the current pods completely and then creates new pods with the updated version. This ensures only one version runs at a time but causes downtime during the switch. It is simple and useful when running multiple versions simultaneously is not possible or safe.

Why it matters

Without the Recreate update strategy, updating an application that cannot run multiple versions at once would be risky or cause conflicts. This strategy solves the problem by ensuring only one version runs at a time, preventing issues like data corruption or incompatible behavior. It matters because some applications need this strict update method to keep data safe and maintain correctness, even if it means a short downtime.

Where it fits

Before learning this, you should understand basic Kubernetes concepts like pods, deployments, and rolling updates. After this, you can explore other update strategies like RollingUpdate or Blue-Green deployments to handle zero-downtime updates and advanced release techniques.

Mental Model

Core Idea

Recreate update strategy replaces all old pods by deleting them first, then creating new pods, ensuring only one version runs at a time.

Think of it like...

It's like closing a store completely to renovate it before reopening with a new look, instead of renovating while still open.

┌───────────────┐       delete all old pods       ┌───────────────┐
│ Old Version   │ ──────────────────────────────▶ │ No pods       │
│ Pods Running  │                                │ (downtime)    │
└───────────────┘                                └───────────────┘
                                                      │
                                                      │ create new pods
                                                      ▼
                                              ┌───────────────┐
                                              │ New Version   │
                                              │ Pods Running  │
                                              └───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Kubernetes Pods

Concept: Pods are the smallest units in Kubernetes that run containers.

A pod is like a small box that holds one or more containers running your application. Kubernetes manages pods to run your app reliably. When you update your app, you update the pods.

Result

You know that pods are the units that get updated or replaced during deployment changes.

Understanding pods is essential because update strategies control how pods are replaced or updated.

2

Foundation

What is an Update Strategy?

Concept: Update strategy defines how Kubernetes replaces old pods with new ones during deployment changes.

Kubernetes can update your app in different ways. The update strategy tells Kubernetes whether to replace pods all at once or gradually. This controls downtime and availability during updates.

Result

You understand that update strategies affect how your app stays available or goes down during updates.

Knowing update strategies helps you choose the right balance between downtime and safety for your app updates.

3

Intermediate

How Recreate Strategy Works

Concept: Recreate strategy deletes all old pods before creating new pods.

When you use Recreate, Kubernetes first stops all running pods of your app. This causes downtime because no pods serve traffic. After all old pods are gone, Kubernetes creates new pods with the updated version.

Result

Your app is temporarily unavailable during the update, but only one version runs at a time.

Understanding this helps you predict downtime and know when Recreate is suitable for your app.

4

Intermediate

Configuring Recreate Strategy in Deployment

🤔Before reading on: do you think Recreate strategy requires special YAML fields or is it the default? Commit to your answer.

Concept: You specify the Recreate strategy explicitly in the deployment YAML under strategy.type.

In your deployment YAML, under spec.strategy.type, set the value to "Recreate". This tells Kubernetes to use the Recreate update method instead of the default RollingUpdate. Example snippet: spec: strategy: type: Recreate

Result

Kubernetes will delete all old pods before creating new ones during updates.

Knowing how to configure the strategy lets you control update behavior precisely.

5

Intermediate

When to Use Recreate Strategy

🤔Before reading on: do you think Recreate is best for apps needing zero downtime or apps that can't run multiple versions? Commit to your answer.

Concept: Recreate is best for apps that cannot safely run multiple versions at once or need exclusive access to resources.

Some applications, like databases or apps with shared state, can break if old and new versions run together. Recreate ensures only one version runs at a time, preventing conflicts. However, it causes downtime during updates.

Result

You can decide when Recreate is the safest update method despite downtime.

Understanding app constraints helps you pick the right update strategy to avoid errors.

6

Advanced

Comparing Recreate with RollingUpdate

🤔Before reading on: do you think Recreate causes less or more downtime than RollingUpdate? Commit to your answer.

Concept: Recreate causes downtime by stopping all pods first, while RollingUpdate replaces pods gradually to avoid downtime.

RollingUpdate updates pods one by one, keeping the app available during the process. Recreate stops all pods first, causing downtime but ensuring no version overlap. RollingUpdate is default and preferred for most apps needing high availability.

Result

You understand trade-offs between downtime and version overlap in update strategies.

Knowing these trade-offs helps you balance availability and safety in production.

7

Expert

Recreate Strategy in Production and Pitfalls

🤔Before reading on: do you think Recreate can cause issues in large-scale clusters or stateful apps? Commit to your answer.

Concept: Recreate can cause downtime and disrupt stateful apps if not managed carefully; experts use it with readiness probes and maintenance windows.

In production, using Recreate requires planning downtime windows. Experts combine it with readiness and liveness probes to avoid traffic to pods that are not ready. For stateful apps, they may use Recreate with persistent volumes and careful data handling to prevent loss. Misuse can cause outages or data corruption.

Result

You learn how to safely use Recreate in real environments and avoid common failures.

Understanding production challenges prevents costly downtime and data issues when using Recreate.

Under the Hood

Kubernetes Deployment controller watches the deployment spec. When an update occurs with Recreate strategy, it first scales down the ReplicaSet by deleting all pods. Only after all pods are terminated does it scale up the new ReplicaSet with updated pod templates. This sequential delete-then-create process ensures no overlap of old and new pods.

Why designed this way?

Recreate was designed to support applications that cannot tolerate multiple versions running simultaneously, such as those with exclusive resource locks or incompatible data formats. It trades availability for safety by enforcing a strict version switch. Alternatives like RollingUpdate were introduced later to reduce downtime but require apps to handle version overlap.

┌─────────────────────────────┐
│ Deployment Controller        │
├─────────────────────────────┤
│ Detects update request       │
│                             │
│ ┌───────────────┐           │
│ │ Delete old    │           │
│ │ pods (scale 0)│──────────▶│
│ └───────────────┘           │
│                             │
│ Waits for all pods to stop  │
│                             │
│ ┌───────────────┐           │
│ │ Create new    │           │
│ │ pods (scale up)│─────────▶│
│ └───────────────┘           │
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does Recreate strategy update pods one by one to avoid downtime? Commit yes or no.

Common Belief: Recreate updates pods gradually like RollingUpdate, so there is no downtime.

Reality: Recreate deletes all old pods before creating new ones, causing downtime during the update.

Why it matters: Believing Recreate avoids downtime can lead to unexpected outages in production.

Quick: Can Recreate strategy run old and new versions simultaneously? Commit yes or no.

Common Belief: Recreate allows old and new pods to run at the same time during updates.

Reality: Recreate ensures no overlap; old pods are fully deleted before new pods start.

Why it matters: Misunderstanding this can cause incorrect assumptions about app behavior and resource conflicts.

Quick: Is Recreate the default update strategy in Kubernetes? Commit yes or no.

Common Belief: Recreate is the default update strategy for deployments.

Reality: RollingUpdate is the default; Recreate must be explicitly set.

Why it matters: Assuming Recreate is default may cause confusion when updates behave differently than expected.

Quick: Does Recreate strategy guarantee zero downtime for all apps? Commit yes or no.

Common Belief: Recreate can be used to achieve zero downtime updates.

Reality: Recreate causes downtime by design; zero downtime requires other strategies like RollingUpdate or Blue-Green.

Why it matters: Expecting zero downtime with Recreate leads to poor user experience and service interruptions.

Expert Zone

1

Recreate strategy can be combined with preStop hooks to gracefully shut down pods before deletion, reducing impact.

2

Using readiness probes with Recreate helps prevent traffic routing to pods that are not fully ready after recreation.

3

In stateful applications, Recreate must be coordinated with persistent storage and data migration to avoid corruption.

When NOT to use

Avoid Recreate when your application requires high availability or zero downtime. Instead, use RollingUpdate or Blue-Green deployment strategies that allow gradual replacement or parallel versions.

Production Patterns

In production, Recreate is often used for critical database schema changes or apps with exclusive locks. It is scheduled during maintenance windows with alerts to users. Operators combine it with health checks and backups to ensure safe updates.

Connections

Blue-Green Deployment

Alternative update strategy with zero downtime by running two environments in parallel.

Understanding Recreate highlights why Blue-Green is preferred for zero downtime, as it avoids stopping all pods at once.

RollingUpdate Strategy

Default Kubernetes update strategy that contrasts with Recreate by updating pods gradually.

Knowing Recreate clarifies the trade-offs RollingUpdate makes to keep apps available during updates.

Database Migration

Recreate strategy is often used when database schema changes require exclusive access during updates.

Recognizing this connection helps coordinate app updates with data changes safely.

Common Pitfalls

#1 Updating deployment without setting strategy causes unexpected downtime or version overlap.

Wrong approach:

apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 3
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: myapp:v2

Correct approach:

apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 3
strategy:
type: Recreate
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: myapp:v2

Root cause:

Forgetting to specify the update strategy leads Kubernetes to use the default RollingUpdate, which may not be suitable for apps needing Recreate.

#2 Using Recreate without readiness probes causes traffic to pods before they are ready.

Wrong approach:

spec:
strategy:
type: Recreate
template:
spec:
containers:
- name: app
image: app:v2

Correct approach:

spec:
strategy:
type: Recreate
template:
spec:
containers:
- name: app
image: app:v2
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
periodSeconds: 10

Root cause:

Not defining readiness probes means Kubernetes may send traffic to pods that are not fully initialized, causing errors.

#3 Running Recreate updates during peak traffic causes user-visible downtime.

Wrong approach:

# No scheduling or maintenance window
kubectl apply -f deployment.yaml

Correct approach:

# Schedule update during low traffic or maintenance window
# Notify users
kubectl apply -f deployment.yaml

Root cause:

Ignoring downtime impact of Recreate leads to poor user experience and potential revenue loss.

Key Takeaways

Recreate update strategy replaces all old pods by deleting them first, causing downtime but ensuring only one version runs at a time.

It is useful for applications that cannot run multiple versions simultaneously due to resource or data constraints.

Recreate must be explicitly configured in the deployment YAML under strategy.type; the default is RollingUpdate.

Understanding the trade-offs between downtime and version overlap helps choose the right update strategy for your app.

In production, Recreate requires careful planning, readiness probes, and maintenance windows to avoid service disruption.

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