OpenShift DeploymentConfigs are a core resource in OpenShift used to manage the deployment and lifecycle of applications. While Kubernetes uses Deployments to manage the rolling updates of applications, OpenShift introduces the concept of DeploymentConfigs with additional features specific to OpenShift that help with deployment strategies, triggers, and more.

Key Differences:

Feature	Kubernetes Deployment	OpenShift DeploymentConfig
Basic Purpose	Declarative updates to applications.	Declarative updates with additional features for OpenShift.
Triggers	Manual updates.	ImageChange, ConfigChange, Manual triggers.
Deployment Strategies	Rolling updates by default.	Rolling, Recreate, and Custom strategies.
Rollback Support	No automatic rollback, manual intervention required.	Automatic rollback on failure, making it more resilient.
Integration with CI/CD	Standard Kubernetes CI/CD pipelines.	Integrated with OpenShift BuildConfig, ImageStreams, and CI/CD.
Health Check Mechanism	Standard Kubernetes health checks (readiness and liveness).	Additional hooks for pre/post-deployment actions.
Use Case	Ideal for simpler use cases.	Ideal for OpenShift-specific workflows and more complex needs.

Key Features of OpenShift DeploymentConfig:

1. Deployment Strategy:
   DeploymentConfigs allow you to specify different deployment strategies to handle updates:
   • Rolling: The default strategy where the deployment is gradually updated without downtime. Pods are updated one by one, ensuring that some are always running.
   • Recreate: All the old pods are killed and replaced with new ones at the same time. This is used when you need a clean slate for the deployment.
   • Custom: Allows you to specify your own custom strategy, for more advanced use cases.
2. Triggers:
   DeploymentConfigs support various triggers that can automatically initiate a deployment. These include:
   • Image Change Trigger: A new deployment is triggered automatically when the image in the container registry is updated.
   • Config Change Trigger: A deployment is triggered when there is a change in the DeploymentConfig itself (e.g., a change in environment variables or configuration).
   • Manual Trigger: A manual deployment is triggered by the user.
3. Rollback:
   OpenShift provides the ability to rollback to a previous version of the DeploymentConfig if something goes wrong with the current deployment. This is handy for maintaining application stability.
4. Replicas:
   Like Kubernetes Deployments, DeploymentConfigs manage the number of replicas of the application running. It ensures that the specified number of replicas are maintained, and OpenShift will create, scale, and manage these pods as necessary.
5. Environment Variables:
   DeploymentConfigs allow you to define environment variables, which can be injected into your application containers. These are often used to provide configuration to the application at runtime.
6. Health Checks:
   DeploymentConfigs allow you to configure readiness and liveness probes to ensure that pods are running properly. If a pod fails these checks, it is replaced automatically.
7. Deployment Hooks:
   DeploymentConfigs support hooks that allow you to execute commands at different stages of the deployment lifecycle. For example:
   • Pre-deployment hooks: Run before a new deployment starts.
   • Post-deployment hooks: Run after a deployment has completed.

Example of a DeploymentConfig YAML:

apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: myrepo/myapp:latest
        ports:
        - containerPort: 8080
  strategy:
    type: Rolling
  triggers:
    - type: ImageChange
      imageChangeParams:
        automatic: true
        from:
          kind: ImageStreamTag
          name: "myapp:latest"

Breakdown of the Example:

1. Metadata:
   • name: The name of the DeploymentConfig, in this case, myapp.
2. Spec:
   • replicas: The number of instances (pods) of the application to run. In this case, 3 replicas are specified.
   • selector: This selects the pods that this DeploymentConfig manages by the app: myapp label.
   • template: Defines the pod template, including the container image and ports. It specifies that the myapp-container will be using the myrepo/myapp:latest image and exposing port 8080.
   • strategy: Defines the deployment strategy, here it’s set to Rolling for zero-downtime updates.
   • triggers: Configures an image change trigger that automatically triggers a new deployment whenever the myapp:latest image in the ImageStream is updated.

Key Differences Between Deployment and DeploymentConfig:

• DeploymentConfig has more OpenShift-specific features like triggers (e.g., ImageChange, ConfigChange) and deployment strategies that are optimized for OpenShift.
• Deployment is a standard Kubernetes resource and doesn’t include OpenShift-specific features like triggers or the advanced deployment strategies.
• In OpenShift, DeploymentConfig is the preferred method for managing deployments of applications, especially for more complex use cases that require integrated triggers or detailed management of deployment processes.

When to Use DeploymentConfig in OpenShift:

• When you need advanced deployment strategies and control over the lifecycle of your pods.
• When you need automatic triggers (like ImageChange triggers) to trigger deployments based on image changes.
• When working within the OpenShift ecosystem and utilizing OpenShift-specific features like deployment hooks, rollback support, and integrated build and image stream workflows.

Note: While DeploymentConfig is used in OpenShift, it is worth noting that Kubernetes has moved more toward using Deployments as the standard for managing workloads. OpenShift still supports DeploymentConfig for compatibility and its additional features.

The difference between Kubernetes Deployments and OpenShift DeploymentConfigs can be subtle, but there are significant distinctions, especially when comparing them in the context of OpenShift, which builds on Kubernetes and adds its own features.

Here’s a detailed comparison:

1. Deployment (Kubernetes):

A Kubernetes Deployment is a resource that provides declarative updates to applications. It ensures that the desired number of replicas of a pod are running and automatically manages the rolling updates of the application. Kubernetes Deployments are part of the core Kubernetes API.

Key Features:

• Rolling Updates: Kubernetes Deployment manages the rolling updates, meaning new pods are gradually created, and old ones are terminated, ensuring no downtime.
• Replicas: It controls the desired number of replicas for scaling.
• Pod Health Checks: Deployments use readiness and liveness probes to ensure that pods are healthy and can be restarted if necessary.
• No Triggers: In Kubernetes Deployments, you manually trigger updates or rollbacks (e.g., by changing the image version).
• No Built-in Rollbacks: If a deployment fails, Kubernetes doesn’t automatically revert to the previous state. Rollbacks are done manually by applying the previous deployment configuration.

Example of Kubernetes Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: myrepo/myapp:latest
        ports:
        - containerPort: 8080

2. DeploymentConfig (OpenShift):

DeploymentConfig is a custom OpenShift resource that is similar to Kubernetes Deployments but with added OpenShift-specific features like deployment triggers, deployment strategies, and rollback mechanisms.

Key Features:

• Triggers:
  • Image Change Trigger: Automatically triggers a new deployment whenever the container image is updated (e.g., new version of the image is pushed to the registry).
  • Config Change Trigger: Automatically triggers a deployment when the configuration (such as environment variables) changes.
  • Manual Trigger: You can manually trigger a deployment.
• Deployment Strategies:
  • Rolling: Gradual update with zero downtime (like Kubernetes).
  • Recreate: All old pods are terminated before new pods are created.
  • Custom: Allows you to define your own deployment strategy.
• Rollback: OpenShift provides automatic rollback to a previous version if a deployment fails, offering more stability and easier recovery compared to Kubernetes deployments.
• Health Checks: DeploymentConfigs support deployment hooks, which run commands before or after the deployment process.
• Integration with OpenShift Build and Image Streams: OpenShift integrates DeploymentConfigs tightly with its BuildConfig and ImageStream resources. This allows automatic deployment when new images are built using OpenShift’s integrated CI/CD pipeline.

Example of OpenShift DeploymentConfig:

apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: myrepo/myapp:latest
        ports:
        - containerPort: 8080
  strategy:
    type: Rolling
  triggers:
    - type: ImageChange
      imageChangeParams:
        automatic: true
        from:
          kind: ImageStreamTag
          name: "myapp:latest"

When to Use Which:

• Kubernetes Deployment: If you’re working with standard Kubernetes and need basic management for application updates with rolling deployments, then Kubernetes Deployment is the way to go.
• OpenShift DeploymentConfig: If you’re working within OpenShift and need more advanced features like automatic rollback, integration with OpenShift’s build system, deployment triggers, and greater flexibility in deployment strategies, then DeploymentConfig is a better option.

Summary:

• Kubernetes Deployment is part of the Kubernetes core API, providing basic deployment functionality.
• OpenShift DeploymentConfig extends Kubernetes Deployments with OpenShift-specific features like triggers, custom deployment strategies, automatic rollback, and integration with the OpenShift ecosystem (e.g., ImageStreams and BuildConfig).

In simple terms:

• Deployment = Standard Kubernetes resource.
• DeploymentConfig = OpenShift’s extended version with additional management features, triggers, and rollback capabilities.