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
- What is a Deployment?
- What is a DeploymentConfig?
- What is the difference between ReplicaSet and ReplicationController?
- Which deployment type is recommended for OpenShift 4.x?
- What is an Image Change Trigger?
- Can DeploymentConfig automatically redeploy after an ImageStream update?
- Which resource is Kubernetes-native?
- Why is Deployment preferred for GitOps?
- How does rolling deployment work?
- When would you still choose DeploymentConfig?
Comments
Share a question, correction, or practical insight about this article.
Checking login status...
Loading approved comments...