Using Recreate Strategy in Kubernetes Deployments with Jenkins Pipelines

Most teams default to Kubernetes' RollingUpdate strategy—and for good reason. Zero downtime, gradual rollout, easy rollback. But there are situations where this approach causes more problems than it solves.

Think about applications that cannot run multiple versions simultaneously. Legacy systems. Apps holding file locks. Stateful services without proper version compatibility. That’s where the Recreate strategy in Kubernetes becomes surprisingly useful.

Now add Jenkins into the mix. If your CI/CD pipeline doesn’t explicitly account for deployment strategy behavior, you can end up with race conditions, broken sessions, or inconsistent states.

What is the Recreate Strategy in Kubernetes?

The Recreate strategy is the simplest deployment approach Kubernetes offers:

• All existing pods are terminated
• New pods are created afterward

No overlap. No gradual rollout. Just a clean slate.

Here’s a minimal example:

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: my-app
5spec:
6  replicas: 3
7  strategy:
8    type: Recreate
9  selector:
10    matchLabels:
11      app: my-app
12  template:
13    metadata:
14      labels:
15        app: my-app
16    spec:
17      containers:
18        - name: my-app
19          image: my-app:v2
20

When this deployment updates, Kubernetes:

1. Stops all 3 existing pods
2. Then creates 3 new pods with the updated image

Why would anyone choose downtime?

Because sometimes consistency matters more than availability.

When Recreate Strategy Actually Makes Sense

A common mistake developers make is assuming RollingUpdate is always better. It isn’t.

Recreate shines in scenarios like:

• Breaking database schema changes where old and new versions cannot coexist
• File-based workloads where multiple instances cause corruption
• Licensing constraints limiting concurrent instances
• Singleton services that must run as one instance only
• Legacy monoliths not designed for horizontal scaling

In these cases, a RollingUpdate might briefly run incompatible versions together—and that’s enough to break things.

Where Jenkins Comes In

Jenkins pipelines often trigger deployments without considering how Kubernetes executes them.

Here’s where things get interesting.

If you’re using Recreate, your pipeline needs to handle:

• Temporary downtime
• Readiness checks before proceeding
• Proper sequencing of dependent services

A naive pipeline might push an update and immediately run integration tests—while the app is still offline.

A Practical Jenkins Pipeline Example

Let’s walk through a simple Jenkins pipeline that deploys using the Recreate strategy.

1pipeline {
2  agent any
3
4  environment {
5    KUBE_CONFIG = credentials('kubeconfig')
6  }
7
8  stages {
9    stage('Build Image') {
10      steps {
11        sh 'docker build -t my-app:${BUILD_NUMBER} .'
12      }
13    }
14
15    stage('Push Image') {
16      steps {
17        sh 'docker push my-app:${BUILD_NUMBER}'
18      }
19    }
20
21    stage('Deploy to Kubernetes') {
22      steps {
23        sh '''
24        kubectl set image deployment/my-app \
25          my-app=my-app:${BUILD_NUMBER}
26        '''
27      }
28    }
29
30    stage('Wait for Deployment') {
31      steps {
32        sh 'kubectl rollout status deployment/my-app'
33      }
34    }
35
36    stage('Post-Deploy Checks') {
37      steps {
38        sh 'curl -f http://my-app/health'
39      }
40    }
41  }
42}
43

Why the rollout wait matters more here

With Recreate, your app goes fully offline before coming back. That means:

• Tests must wait for pods to be ready
• Health checks are critical
• Retries may be necessary

Skipping kubectl rollout status is a common cause of flaky pipelines.

Handling Downtime Gracefully

You can’t eliminate downtime with Recreate—but you can manage it.

Here are a few practical approaches:

1. Use Maintenance Mode

Serve a static "maintenance" page during deployment. This avoids broken user experiences.

2. Drain Traffic First

If you’re behind a load balancer or ingress controller, temporarily route traffic away before deployment.

3. Shorten Startup Time

Optimize container startup so new pods come online faster:

• Reduce image size
• Avoid heavy init scripts
• Use readiness probes efficiently

4. Use Pre-Deployment Hooks

In Jenkins, add a stage before deployment to prepare dependencies or notify users.

Recreate vs RollingUpdate: A Quick Reality Check

The key takeaway: Recreate is not outdated—it’s specialized.

Gotchas to Watch Out For

• No automatic rollback safety: If the new version fails, you’re already down
• Long startup times amplify downtime
• Database migrations must be carefully sequenced

One subtle issue: if your Jenkins pipeline updates the image before a migration completes, you can end up with an unusable system.

A safer pattern is:

1. Run migration job
2. Verify success
3. Trigger deployment

Blending Recreate with Modern Practices

You don’t have to choose between "old-school" and "modern" deployment strategies.

Some teams combine Recreate with:

• Feature flags to reduce risky changes
• Blue/Green environments at infrastructure level
• Database backward compatibility to eventually move away from Recreate

In fact, many teams use Recreate as a transitional strategy while modernizing legacy systems.

Final Thought

The Recreate strategy isn’t about convenience—it’s about control.

When paired with a well-designed Jenkins pipeline, it gives you predictable, conflict-free deployments at the cost of brief downtime. And in certain systems, that trade-off is not just acceptable—it’s necessary.

If your application behaves unpredictably during rolling updates, it might not be a Kubernetes problem. It might be a sign that Recreate is the right tool for the job.