DeploymentConfig API is being deprecated in Red Hat OpenShift Container Platform 4.14

Updated -

Disclaimer: Links contained herein to external website(s) are provided for convenience only. Red Hat has not reviewed the links and is not responsible for the content or its availability. The inclusion of any link to an external website does not imply endorsement by Red Hat of the website or their entities, products or services. You agree that Red Hat is not responsible or liable for any loss or expenses that may result due to your use of (or reliance on) the external site or content.

As of Red Hat OpenShift Container Platform 4.14, DeploymentConfig API is deprecated. DeploymentConfig objects are still supported, but are not recommended for new installations. Only security-related and critical issues will be fixed. Instead, use of Deployment objects is recommended.

In addition, Red Hat OpenShift Container Platform 4.14 and later installation allow for disabling the DeploymentConfig capability, among other optional Cluster capabilities.

Also while customers using DeploymentConfigs are encouraged to migrate to Deployments, there are currently (Red Hat OpenShift Container Platform 4.14) no plans to remove the DeploymentConfigs API. Instead the DeploymentConfigs API is being deprecated and therefore no new functionality will be provided and maintenance will be limited to security and critical fixes only.

Why are we doing this

The current implementation of DeploymentConfigs is based on management of ReplicationController objects. However development of ReplicationController has ceased and upstream recommends to use ReplicaSet objects instead.

In addition, the DeploymentConfig API is a Red Hat OpenShift Container Platform specific API that is not available in other Kubernetes distribution and in fact has been superset with Kubernetes Deployments that are available in all Kubernetes distributions.

What should affected customers do

Since Red Hat OpenShift Container Platform 4.1, it is recommended to use Deployment objects unless a specific feature or behavior provided by DeploymentConfig objects is needed.

Existing DeploymentConfig objects should be migrated to Deployment objects. See the documentation page Comparing Deployment and DeploymentConfig objects to better understand the differences.

What if we use Automatic Rollbacks

  • Please see Automatic rollbacks for more information.
  • OpenShift GitOps introduced Argo Rollouts in version 1.9 as Technology Preview feature and with Argo Rollouts, lots of capabilities are made available with regards to rollbacks and rollout strategies along other functionality that could be used when moving from DeploymentConfigs to Deployments.
  • Helm rollbacks offer an alternative approach to Argo Rollouts to support and add capabilities to rollback a problematic or even successful deployment to a previous version.

What if we use Triggers

What if we use Lifecycle Hooks

  • Please see Lifecycle hooks for more information.
  • With the available Resource Hooks in OpenShift GitOps it’s possible to trigger activity during different phases of the application sync which may help achieve the same objective, the Lifecycle hooks in DeploymentConfigs would do.
  • Chart Hooks available via helm, provides a hook mechanism to allow chart developers to intervene at certain points in a release's life cycle.

What if we use Custom Strategies

  • Please see Custom strategies for more information.
  • Deployments offer different kinds of strategies that can be used to replace old pods with new pods. For details about the available strategies and detailed configuration options, consult the Kubernetes documentation.

Comments