Backend interview prep

Start Learning

Rolling Deployment in OpenShift

Learn how Rolling Deployments work in OpenShift, understand deployment strategies, zero-downtime deployments, rollback, Spring Boot implementation, and production best practices.

Introduction

One of the biggest challenges in enterprise software development is deploying a new application version without interrupting users.

Imagine a banking application processing thousands of payment transactions every minute. Stopping the application for deployment would result in failed transactions and poor customer experience.

OpenShift solves this problem using Rolling Deployments, where new Pods are gradually introduced while old Pods are removed only after the new ones are healthy.

This approach enables zero-downtime deployments and is the default deployment strategy in modern Kubernetes and OpenShift environments.

Learning Objectives

By the end of this article, you will understand:

  • What is a Rolling Deployment?
  • Why Rolling Deployments are important
  • Deployment lifecycle
  • Rolling update strategy
  • Rollback
  • Spring Boot implementation
  • Deployment configuration
  • Real-world enterprise use cases
  • Best practices

Traditional Deployment Problem

Traditional deployments often stop the running application before deploying the new version.

flowchart LR
    Users --> AppV1["Application v1"]

    AppV1 -. Stop Service .-> Down[Application Offline]

    Down --> AppV2["Application v2"]

    AppV2 --> Users

Problems:

  • Downtime
  • Failed user requests
  • Lost business transactions
  • Poor customer experience

Rolling Deployment Solution

OpenShift deploys the new version while the current version is still serving traffic.

flowchart LR
    Users --> Service

    Service --> PodV1["Pod v1"]

    Service --> PodV2["Pod v2"]

    PodV1 -. Gradually Removed .-> Removed[Old Pods Removed]

    PodV2 --> Running["New Version Running"]

Benefits:

  • Zero downtime
  • Smooth transition
  • Better availability

How Rolling Deployment Works

sequenceDiagram

participant Developer
participant Deployment
participant ReplicaSet
participant Pod
participant User

Developer->>Deployment: Deploy Version 2

Deployment->>ReplicaSet: Create New ReplicaSet

ReplicaSet->>Pod: Start New Pods

Pod-->>Deployment: Ready

Deployment->>ReplicaSet: Remove Old Pods

User-->>Pod: Continue Requests

Users never experience downtime during deployment.

Rolling Deployment Lifecycle

flowchart TD

CurrentPods["Version 1 Pods"]

--> NewPods["Create Version 2 Pods"]

--> HealthCheck["Readiness Probe"]

--> Traffic["Shift Traffic"]

--> RemoveOld["Remove Version 1 Pods"]

--> Complete["Deployment Complete"]

Spring Boot Deployment Architecture

flowchart LR
    DEV["Developer"]
    GIT["Git Repository"]
    PIPE["CI/CD Pipeline"]
    IMAGE["Container Image"]
    DEPLOY["Deployment"]
    RS["ReplicaSet"]
    PODS["Pods"]
    SVC["Service"]
    ROUTE["Route"]
    USERS["Users"]

    DEV --> GIT
    GIT --> PIPE
    PIPE --> IMAGE
    IMAGE --> DEPLOY
    DEPLOY --> RS
    RS --> PODS
    PODS --> SVC
    SVC --> ROUTE
    ROUTE --> USERS

Deployment YAML

apiVersion: apps/v1
kind: Deployment

metadata:
  name: payment-api

spec:

  replicas: 3

  strategy:
    type: RollingUpdate

    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

  selector:
    matchLabels:
      app: payment-api

  template:
    metadata:
      labels:
        app: payment-api

    spec:
      containers:
      - name: payment-api
        image: quay.io/demo/payment-api:v2

RollingUpdate Parameters

Parameter Description
maxSurge Maximum extra Pods created during update
maxUnavailable Maximum unavailable Pods during update

Example:

rollingUpdate:
  maxSurge: 1
  maxUnavailable: 0

Meaning:

  • Create one new Pod first.
  • Never make the application unavailable.

Deployment Flow

flowchart LR

Version1

--> CreatePodV2

CreatePodV2

--> HealthCheck

HealthCheck

--> RemovePodV1

RemovePodV1

--> Repeat

Repeat

--> Version2

This process repeats until every old Pod is replaced.

ReplicaSet During Deployment

flowchart TD

Deployment

--> ReplicaSetV1

Deployment

--> ReplicaSetV2

ReplicaSetV1

--> OldPod1

ReplicaSetV1

--> OldPod2

ReplicaSetV2

--> NewPod1

ReplicaSetV2

--> NewPod2

Both ReplicaSets coexist temporarily during deployment.

Readiness Probe

Traffic should only be sent to healthy Pods.

readinessProbe:
  httpGet:
    path: /actuator/health
    port: 8080

  initialDelaySeconds: 15

  periodSeconds: 10

If the application is not ready, OpenShift continues routing traffic to the old Pods.

Liveness Probe

Detects unhealthy Pods.

livenessProbe:
  httpGet:
    path: /actuator/health
    port: 8080

  initialDelaySeconds: 30

If a Pod becomes unhealthy, Kubernetes automatically recreates it.

Enterprise Banking Example

Suppose a payment service is upgraded from Version 1 to Version 2.

flowchart LR

Customers

--> LoadBalancer

LoadBalancer

--> PaymentV1

LoadBalancer

--> PaymentV2

PaymentV2

--> Database

As Version 2 becomes healthy:

  • New customer requests are routed to Version 2.
  • Version 1 Pods are gradually removed.
  • No transactions are lost.

Rolling Deployment Timeline

flowchart LR

Time1["3 Pods v1"]

--> Time2["2 Pods v1 + 1 Pod v2"]

--> Time3["1 Pod v1 + 2 Pods v2"]

--> Time4["3 Pods v2"]

Traffic continues flowing throughout the deployment.

Update Container Image

Deploy a new version:

oc set image deployment/payment-api \
payment-api=quay.io/demo/payment-api:v2

OpenShift automatically performs a rolling deployment.

Monitor Deployment

View rollout status:

oc rollout status deployment/payment-api

Check deployment history:

oc rollout history deployment/payment-api

Rollback Deployment

If Version 2 contains a bug:

oc rollout undo deployment/payment-api

OpenShift restores the previous stable ReplicaSet.

Rollback Workflow

flowchart LR

Version1

--> Version2

Version2

--> IssueDetected

IssueDetected

--> Rollback

Rollback

--> Version1

Deployment Strategies

Strategy Downtime Use Case
Rolling No Most applications
Recreate Yes Database schema changes
Blue-Green No Production releases
Canary No Gradual feature rollout

Rolling Deployment is the default strategy for most Spring Boot applications.

Best Practices

  • Always configure Readiness Probes.
  • Always configure Liveness Probes.
  • Keep at least two replicas in production.
  • Use immutable image tags (v1.0.0, v2.0.0).
  • Test deployments in Dev and QA first.
  • Monitor rollout progress.
  • Enable resource requests and limits.
  • Use rolling deployments for stateless services.

Common Mistakes

❌ Using the latest image tag.

❌ Deploying with only one replica.

❌ Missing readiness probes.

❌ Ignoring rollout status.

❌ Deploying directly to Production without testing.

Advantages

  • Zero downtime
  • High availability
  • Automatic rollback support
  • Gradual traffic migration
  • Better user experience
  • Reduced deployment risk
  • Native Kubernetes support

Summary

Rolling Deployment is the recommended deployment strategy for modern Spring Boot applications running on OpenShift.

Key takeaways:

  • Rolling Deployment gradually replaces old Pods with new Pods.
  • Users continue accessing the application throughout the deployment.
  • ReplicaSets manage both old and new Pods during the transition.
  • Readiness and Liveness Probes ensure only healthy Pods receive traffic.
  • Rollback allows quick recovery if deployment issues occur.
  • Rolling Deployments are ideal for enterprise microservices and cloud-native applications.

Interview Questions

  1. What is a Rolling Deployment?
  2. How does Rolling Deployment prevent downtime?
  3. What is the purpose of maxSurge?
  4. What is the purpose of maxUnavailable?
  5. Why are Readiness Probes important?
  6. What happens if a new Pod fails its health check?
  7. How do you monitor rollout status?
  8. How do you rollback a deployment?
  9. What is the difference between Rolling and Recreate deployment strategies?
  10. Why are Rolling Deployments preferred for Spring Boot microservices?