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.