Backend interview prep

Start Learning

OpenShift High Availability

Learn how to build highly available Spring Boot applications on OpenShift. Understand High Availability architecture, replica management, self-healing, anti-affinity, multi-zone deployments, rolling updates, Pod Disruption Budgets, and enterprise best practices.

Introduction

Enterprise applications must remain available even when infrastructure components fail.

Consider an online banking system.

Customers expect to:

  • Check balances
  • Transfer money
  • Pay bills
  • Apply for loans

24 hours a day, 365 days a year.

A single Pod failure should never cause an application outage.

This is the goal of High Availability (HA).

OpenShift provides built-in capabilities to ensure applications continue running even when:

  • Pods crash
  • Nodes fail
  • Containers restart
  • Deployments occur
  • Availability Zones become unavailable

Learning Objectives

By the end of this article, you will understand:

  • What is High Availability?
  • High Availability Architecture
  • ReplicaSets
  • Multiple Pods
  • Self-Healing
  • Pod Anti-Affinity
  • Multi-Zone Deployment
  • Pod Disruption Budget
  • Rolling Updates
  • Enterprise Best Practices

What is High Availability?

High Availability means an application continues serving users even when failures occur.

Goals:

  • Zero downtime
  • Automatic recovery
  • Fault tolerance
  • Continuous availability
  • Resilient deployments

Single Pod Deployment

flowchart LR
    A[Client]
    B[Route]
    C[Spring Boot Pod]

    A --> B
    B --> C

Problem:

If the Pod crashes, the application becomes unavailable.

High Availability Deployment

flowchart LR
    A[Client]
    B[OpenShift Route]
    C[Service]

    D[Pod 1]
    E[Pod 2]
    F[Pod 3]

    A --> B
    B --> C

    C --> D
    C --> E
    C --> F

Traffic is distributed across multiple Pods.

ReplicaSet

A ReplicaSet ensures the desired number of Pods are always running.

Example:

spec:
  replicas: 3

If one Pod fails, OpenShift automatically creates another.

ReplicaSet Architecture

flowchart LR
    A[Deployment]
    B[ReplicaSet]
    C[Pod 1]
    D[Pod 2]
    E[Pod 3]

    A --> B
    B --> C
    B --> D
    B --> E

Self-Healing

When a Pod crashes:

flowchart LR
    A[Pod Failure]
    B[ReplicaSet Detects Failure]
    C[Create New Pod]

    A --> B
    B --> C

No manual intervention is required.

Node Failure

If an entire worker node fails:

flowchart LR
    A[Node 1]
    B[Node 2]
    C[Node 3]

    D[Pod A]
    E[Pod B]
    F[Pod C]

    A --> D
    B --> E
    C --> F

Pods from the failed node are recreated on healthy nodes.

Multi-Node Deployment

flowchart TD
    A[Worker Node 1]
    B[Worker Node 2]
    C[Worker Node 3]

    D[Payment Pod]
    E[Payment Pod]
    F[Payment Pod]

    A --> D
    B --> E
    C --> F

Applications remain available even if one node fails.

Pod Anti-Affinity

Never schedule all replicas on the same node.

flowchart LR
    A[Node 1]
    B[Node 2]
    C[Node 3]

    D[Pod]
    E[Pod]
    F[Pod]

    A --> D
    B --> E
    C --> F

Anti-affinity improves resilience.

Anti-Affinity Configuration

podAntiAffinity:

  preferredDuringSchedulingIgnoredDuringExecution:

  - weight: 100

OpenShift spreads Pods across worker nodes.

Multi-Zone Deployment

Production clusters often span multiple Availability Zones.

flowchart LR
    A[Zone A]
    B[Zone B]
    C[Zone C]

    D[Pod]
    E[Pod]
    F[Pod]

    A --> D
    B --> E
    C --> F

If an entire zone fails, the application continues running.

Rolling Update

flowchart LR
    A[Version 1]

    B[Version 2]

    C[Traffic Shift]

    A --> B
    B --> C

Users experience zero downtime.

Rolling Deployment Process

sequenceDiagram
    participant User
    participant Route
    participant OldPod
    participant NewPod

    User->>Route: Request

    Route->>OldPod: Forward

    NewPod->>Route: Ready

    Route->>NewPod: New Traffic

Pod Disruption Budget

PDB prevents all Pods from being unavailable simultaneously.

Example

apiVersion: policy/v1

kind: PodDisruptionBudget

spec:

  minAvailable: 2

At least two Pods remain available.

Load Balancing

flowchart LR
    A[Client]
    B[Route]
    C[Service]

    D[Pod 1]
    E[Pod 2]
    F[Pod 3]

    A --> B
    B --> C

    C --> D
    C --> E
    C --> F

Traffic is evenly distributed.

Health Checks

High Availability depends on:

  • Startup Probe
  • Readiness Probe
  • Liveness Probe
flowchart LR
    A[Pod]
    B[Startup]
    C[Readiness]
    D[Liveness]

    A --> B
    B --> C
    C --> D

Only healthy Pods receive traffic.

Autoscaling

High Availability works together with Horizontal Pod Autoscaler.

flowchart LR
    A[CPU Usage High]
    B[Horizontal Pod Autoscaler]
    C[Increase Replicas]

    A --> B
    B --> C

Enterprise Banking Architecture

flowchart TD
    A[Internet]

    B[OpenShift Router]

    C[Payment Service]

    D[Pod 1]
    E[Pod 2]
    F[Pod 3]

    G[(Oracle RAC)]

    H[Kafka Cluster]

    A --> B
    B --> C

    C --> D
    C --> E
    C --> F

    D --> G
    E --> G
    F --> G

    D --> H
    E --> H
    F --> H

Every layer is designed for high availability.

Enterprise HA Architecture

flowchart TD
    A[Users]

    B[OpenShift Router]

    C[API Gateway]

    D[Customer Service]
    E[Payment Service]
    F[Order Service]

    G[Prometheus]
    H[Loki]
    I[Jaeger]

    A --> B
    B --> C

    C --> D
    C --> E
    C --> F

    D --> G
    E --> H
    F --> I

Monitoring ensures high availability is maintained.

Useful Commands

View Pods

oc get pods

View Deployments

oc get deployment

Scale Application

oc scale deployment payment-service --replicas=5

View ReplicaSets

oc get rs

Describe Deployment

oc describe deployment payment-service

Common Problems

Single Replica

Never run production workloads with:

replicas: 1

Pods on Same Node

Configure Pod Anti-Affinity.

Missing Health Checks

Without health probes:

  • Failed Pods continue receiving traffic.

No PDB

Cluster maintenance may terminate all Pods simultaneously.

Production Best Practices

  • Deploy at least three replicas.
  • Enable Liveness, Readiness, and Startup probes.
  • Configure Pod Anti-Affinity.
  • Deploy across multiple Availability Zones.
  • Use Pod Disruption Budgets.
  • Enable Horizontal Pod Autoscaler.
  • Monitor application health continuously.
  • Use Rolling Updates.
  • Avoid single points of failure.
  • Test disaster recovery procedures regularly.

Common Mistakes

❌ Running production with one Pod.

❌ No health probes.

❌ Scheduling all Pods on one node.

❌ Sharing a single database instance without HA.

❌ No autoscaling configuration.

❌ Ignoring node failures.

Advantages

  • Zero downtime
  • Automatic recovery
  • Self-healing infrastructure
  • Improved resilience
  • Better fault tolerance
  • Cloud-native scalability
  • Continuous availability
  • Enterprise-grade reliability

Summary

High Availability is a core design principle for running Spring Boot applications on OpenShift.

Key takeaways:

  • Deploy multiple replicas to eliminate single points of failure.
  • ReplicaSets automatically replace failed Pods.
  • Pod Anti-Affinity distributes workloads across nodes.
  • Rolling Updates provide zero-downtime deployments.
  • Pod Disruption Budgets protect applications during maintenance.
  • Combining health probes, autoscaling, and multi-zone deployments ensures resilient enterprise applications.

Interview Questions

  1. What is High Availability?
  2. Why should production workloads have multiple replicas?
  3. What is the purpose of a ReplicaSet?
  4. How does Pod Anti-Affinity improve availability?
  5. What happens when a worker node fails?
  6. What is a Pod Disruption Budget?
  7. How do Rolling Updates prevent downtime?
  8. Why are health probes critical for HA?
  9. How does HPA complement High Availability?
  10. What are the best practices for designing highly available applications on OpenShift?