DeploymentConfig deprecated

Kubernetes has become the default home for many modern workloads, and for stateless applications the native Deployment o

Kubernetes has become the default home for many modern workloads, and for stateless applications the native Deployment object is now the standard way to declare replicas, rollout strategy, and rollout history. That said, teams working in older OpenShift environments or early Kubernetes releases often ran into DeploymentConfig, frequently shortened to DC. Although it was once a practical option, it has since been marked Deprecated. The change reflects a broader push toward a single, core Kubernetes API and away from OpenShift-specific extensions that duplicate native functionality.
The deprecation was not simply a cosmetic rename. It came from a growing recognition that the Kubernetes ecosystem needed a consistent way to manage deployments.

  • Native Deployment already supports rolling updates, rollbacks, and declarative scaling.
  • DeploymentConfig added OpenShift-oriented behavior, especially around triggers and operational tooling.
  • The overlap created two competing deployment models.
  • API stability improved when the community focused on the core Deployment resource.

As the native Deployment matured, the extra layer became harder to justify. Maintaining both systems increased complexity for users, operators, and platform teams.

What Deprecated Means in Practice

A deprecation notice usually signals that a resource is no longer recommended. Over time, support may be limited, behavior may be frozen, or compatibility may be removed in later releases.

For teams still using DeploymentConfig, the practical impact can be felt during upgrades, audits, and new project planning. Even before removal, the direction is clear: new designs should prefer Deployment.

Core Differences Between DeploymentConfig and Deployment

Trigger Handling

DeploymentConfig could watch ConfigMaps and Secrets and trigger a new rollout when they changed. This was useful for configuration-driven restarts.

The native Deployment does not provide the same direct trigger mechanism. Teams often need alternatives such as:

  • A sidecar container like k8s-auto-reload.
  • Application-level hot reload.
  • An Operator or custom controller that reacts to config changes.

Rollback Behavior

DeploymentConfig offered rollback support through commands such as oc rollback.

The native Deployment uses kubectl rollout undo. The intent is similar, but the command names and workflows differ.

Update Strategy

DeploymentConfig used a Rolling strategy and allowed tuning through fields such as maxSurge and maxUnavailable.

The native Deployment supports RollingUpdate and Recreate. The configuration may be nested under strategy.rollingUpdate, which means direct translation is not always straightforward.

Migration Strategy

Migrating away from DeploymentConfig should be treated as a structured project rather than a quick find-and-replace.

  1. Audit the environment

    • Locate every DeploymentConfig resource.
    • Identify OpenShift-specific fields and triggers.

  2. Map required behavior

    • Determine how configuration changes should restart pods.
    • Confirm rollback and update strategy requirements.

  3. Convert manifests

    • Change kind to Deployment.
    • Align selector fields with template.metadata.labels.
    • Remove unsupported fields.

  4. Add replacement automation

    • Introduce sidecar containers, hot reload, or controllers.

  5. Validate in a staging environment

    • Test rolling updates, rollbacks, and config changes.

Final Thoughts

The deprecation of DeploymentConfig marks an important step in standardizing Kubernetes operations. While migration may require adjustments, the long-term benefit of using the native Deployment resource is clear. Teams planning new systems should avoid DeploymentConfig, and existing systems should begin migration planning as soon as possible.