Full Stack • Java • System Design • Cloud • AI Engineering

OpenShift DeploymentConfig vs Deployment

Learn the differences between DeploymentConfig and Deployment in OpenShift, understand their architecture, deployment strategies, image triggers, and when to use each in enterprise Spring Boot applications.


Introduction

One of the most confusing topics for developers new to OpenShift is the difference between Deployment and DeploymentConfig.

Many enterprise applications still use DeploymentConfig, while modern OpenShift versions recommend using the standard Kubernetes Deployment resource.

Understanding the differences helps you choose the right deployment strategy for your Spring Boot applications.


Learning Objectives

By the end of this article, you will understand:

  • What is a Deployment?
  • What is a DeploymentConfig?
  • Deployment Architecture
  • DeploymentConfig Architecture
  • Feature comparison
  • Deployment strategies
  • Image triggers
  • Rollback
  • Enterprise use cases
  • Best practices

What is a Deployment?

A Deployment is the standard Kubernetes resource used to manage Pods.

Responsibilities:

  • Create Pods
  • Scale Pods
  • Perform rolling updates
  • Rollback deployments
  • Maintain desired replicas

It is the recommended deployment method for modern OpenShift applications.


Kubernetes Deployment Architecture

flowchart TD

Deployment

--> ReplicaSet

ReplicaSet

--> Pod1

ReplicaSet

--> Pod2

ReplicaSet

--> Pod3

Deployment manages ReplicaSets, which in turn manage Pods.


What is DeploymentConfig?

DeploymentConfig is an OpenShift-specific deployment resource introduced before Kubernetes Deployments became mature.

Additional capabilities include:

  • Image Change Triggers
  • Config Change Triggers
  • Custom Deployment Strategies

DeploymentConfig creates ReplicationControllers instead of ReplicaSets.


DeploymentConfig Architecture

flowchart TD

DeploymentConfig

--> ReplicationController

ReplicationController

--> Pod1

ReplicationController

--> Pod2

ReplicationController

--> Pod3

Deployment vs DeploymentConfig

flowchart TB
    REG["Image Registry"]

    subgraph Kubernetes
        DEPLOY["Deployment"]
        KPODS["Pods"]
        DEPLOY --> KPODS
    end

    subgraph OpenShift
        DC["DeploymentConfig"]
        OPODS["Pods"]
        DC --> OPODS
    end

    REG --> DEPLOY
    REG --> DC

Both deploy Pods, but the internal controllers differ.


Resource Comparison

Feature Deployment DeploymentConfig
Standard Kubernetes
OpenShift Specific
ReplicaSet
ReplicationController
Rolling Update
Rollback
Image Change Trigger
Config Change Trigger
Future Recommendation Legacy Support

Deployment Workflow

flowchart LR
    DEV["Developer"]
    GIT["Git Repository"]
    PIPE["CI/CD Pipeline"]
    REG["Container Registry"]

    DEPLOY["Deployment"]
    RS["ReplicaSet"]
    POD1["Pod 1"]
    POD2["Pod 2"]
    POD3["Pod 3"]

    DEV --> GIT
    GIT --> PIPE
    PIPE --> REG
    REG --> DEPLOY
    DEPLOY --> RS
    RS --> POD1
    RS --> POD2
    RS --> POD3

DeploymentConfig Workflow

flowchart LR
    DEV["Developer"]
    GIT["Git Repository"]
    BC["BuildConfig"]
    IS["ImageStream"]

    DC["DeploymentConfig"]
    RC["ReplicationController"]
    POD["Application Pods"]

    DEV --> GIT
    GIT --> BC
    BC --> IS
    IS --> DC
    DC --> RC
    RC --> POD

DeploymentConfig integrates closely with ImageStreams.


Image Change Trigger

One of the biggest advantages of DeploymentConfig is automatic deployment when a new image becomes available.

flowchart LR
    BUILD["BuildConfig"]
    IMAGE["Container Image"]
    IS["ImageStream"]
    DC["DeploymentConfig"]
    RC["ReplicationController"]
    POD["New Pods"]

    BUILD --> IMAGE
    IMAGE --> IS
    IS --> DC
    DC --> RC
    RC --> POD

Developers don't manually redeploy.


Kubernetes Deployment Update

With Deployment, developers update the image manually.

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

Deployment creates a new ReplicaSet automatically.


Rolling Update

flowchart LR

OldPod1

OldPod2

OldPod3

-->

NewPod1

NewPod2

NewPod3

During deployment:

  • New Pods start.
  • Old Pods terminate gradually.
  • No downtime.

Rollback Process

flowchart LR

Version1

--> Version2

--> Version3

--> Rollback

--> Version2

Rollback is supported by both Deployment and DeploymentConfig.


Spring Boot Deployment Example

Deployment YAML

apiVersion: apps/v1
kind: Deployment

metadata:
  name: payment-api

spec:

  replicas: 3

  selector:
    matchLabels:
      app: payment-api

  template:

    metadata:

      labels:

        app: payment-api

    spec:

      containers:

      - name: payment-api

        image: quay.io/demo/payment:1.0

        ports:

        - containerPort: 8080

DeploymentConfig Example

apiVersion: apps.openshift.io/v1

kind: DeploymentConfig

metadata:

  name: payment-api

spec:

  replicas: 3

  selector:

    app: payment-api

  template:

    metadata:

      labels:

        app: payment-api

    spec:

      containers:

      - name: payment-api

        image: quay.io/demo/payment:1.0

Enterprise Banking Example

Payment Service deployment.

flowchart LR
    DEV["Developer"]
    GIT["Git Repository"]
    JENKINS["Jenkins CI/CD"]
    BUILD["Docker Build"]
    QUAY["Quay Registry"]

    subgraph OCP["OpenShift Cluster"]
        DEPLOY["Deployment"]
        POD1["Payment Pod 1"]
        POD2["Payment Pod 2"]
        SVC["Service"]
        ROUTE["Route"]
    end

    USER["Customer"]

    DEV --> GIT
    GIT --> JENKINS
    JENKINS --> BUILD
    BUILD --> QUAY
    QUAY --> DEPLOY
    DEPLOY --> POD1
    DEPLOY --> POD2
    POD1 --> SVC
    POD2 --> SVC
    SVC --> ROUTE
    ROUTE --> USER

Modern banking applications typically use Kubernetes Deployments.


Legacy Banking Example

Older OpenShift clusters may still use DeploymentConfig.

flowchart LR
    GIT["Git"]
    BUILD["Build"]
    IMAGESTREAM["ImageStream"]
    DC["DeploymentConfig"]
    PODS["Payment Pods"]

    GIT --> BUILD
    BUILD --> IMAGESTREAM
    IMAGESTREAM --> DC
    DC --> PODS

This approach remains common in long-lived enterprise environments.


When to Use Deployment?

Choose Deployment if:

  • Building new applications
  • Using Kubernetes-native resources
  • Running OpenShift 4.x
  • Deploying Spring Boot microservices
  • Using GitOps or Argo CD

When to Use DeploymentConfig?

Use DeploymentConfig if:

  • Maintaining legacy OpenShift applications
  • Relying on ImageStreams
  • Using Image Change Triggers
  • Existing enterprise applications already depend on it

Deployment Lifecycle

sequenceDiagram

participant Developer

participant Deployment

participant ReplicaSet

participant Pods

Developer->>Deployment: Apply YAML

Deployment->>ReplicaSet: Create ReplicaSet

ReplicaSet->>Pods: Create Pods

Pods-->>Developer: Running

DeploymentConfig Lifecycle

sequenceDiagram

participant ImageStream

participant DeploymentConfig

participant RC

participant Pods

ImageStream->>DeploymentConfig: Image Updated

DeploymentConfig->>RC: Create Controller

RC->>Pods: Deploy Pods

Best Practices

✅ Prefer Kubernetes Deployments for new applications.

✅ Use ReplicaSets instead of ReplicationControllers.

✅ Enable readiness and liveness probes.

✅ Configure resource requests and limits.

✅ Use immutable image tags.

✅ Store configuration in ConfigMaps.

✅ Store credentials in Secrets.


Common Mistakes

❌ Mixing Deployment and DeploymentConfig for the same application.

❌ Using DeploymentConfig for new Kubernetes-native projects without a legacy requirement.

❌ Using the latest image tag in production.

❌ Forgetting health probes.

❌ Deploying without resource limits.


Summary

Both Deployment and DeploymentConfig manage application deployments, but they serve different purposes.

Key takeaways:

  • Deployment is the Kubernetes standard and the preferred choice for new applications.
  • DeploymentConfig is an OpenShift-specific resource mainly used in legacy environments.
  • Deployment uses ReplicaSets, while DeploymentConfig uses ReplicationControllers.
  • DeploymentConfig provides automatic image change triggers, whereas Deployments rely on Kubernetes-native workflows.
  • For most modern Spring Boot applications on OpenShift 4.x, use Deployment unless you have a specific legacy requirement.

Interview Questions

  1. What is a Deployment?
  2. What is a DeploymentConfig?
  3. What is the difference between ReplicaSet and ReplicationController?
  4. Which deployment type is recommended for OpenShift 4.x?
  5. What is an Image Change Trigger?
  6. Can DeploymentConfig automatically redeploy after an ImageStream update?
  7. Which resource is Kubernetes-native?
  8. Why is Deployment preferred for GitOps?
  9. How does rolling deployment work?
  10. When would you still choose DeploymentConfig?

Loading likes...

Comments

Share a question, correction, or practical insight about this article.

Loading approved comments...