OpenShift DeploymentConfig与Kubernetes Deployment的差异对比及补充疑问

Great question! You’ve already nailed the core controller chain difference—DeploymentConfig links to ReplicationControllers, while Deployments rely on ReplicaSets. But there’s a ton more that separates these two workload management tools, especially since DeploymentConfig was OpenShift’s original solution before Kubernetes standardized Deployments. Let’s dive into all the key distinctions:

1. Update Trigger Mechanisms #

This is one of the biggest gaps. DeploymentConfig has built-in, configurable triggers that automatically initiate rollouts, whereas Deployments rely on declarative changes to the pod template:

• DeploymentConfig Triggers:
  • ImageChange: Automatically updates pods when a new image is pushed to a linked OpenShift ImageStream (e.g., when a BuildConfig finishes a new build). You can configure this to watch specific tags (like latest or stable).
  • ConfigChange: Triggers a rollout when the DeploymentConfig’s own spec (e.g., resource limits, env vars) is modified.
  • Manual: Disables automatic triggers—you have to explicitly run oc rollout latest dc/<name> to start a rollout.
    Example trigger config:

  triggers:
  - type: ImageChange
    imageChangeParams:
      automatic: true
      containerNames:
      - my-app-container
      from:
        kind: ImageStreamTag
        name: my-app:latest
        namespace: my-project
  

• Deployment Updates:
  Deployments only trigger rollouts when you modify the spec.template (e.g., update the image tag, change a volume mount). There’s no native integration with image streams—you’d need external tools like ArgoCD or Tekton to automate image-based updates. To manually restart a deployment, you run kubectl rollout restart deployment/<name>.

2. Rollout History & Rollback Behavior #

Both support rollbacks, but how they track and manage revisions differs:

• DeploymentConfig:
  Revisions are stored directly in the DeploymentConfig’s status.revisions field. By default, it keeps the last 10 revisions. Rolling back uses oc rollout undo dc/<name> --to-revision=<num>. Note that each revision creates a new ReplicationController.
• Deployment:
  Revisions are tracked via unique ReplicaSets (each revision gets its own ReplicaSet with a pod-template-hash label). Kubernetes keeps old ReplicaSets around (default 10) to enable rollbacks. You use kubectl rollout undo deployment/<name> or target a specific ReplicaSet directly. Deployments also support pause/resume of rollouts natively, which DeploymentConfig requires custom strategies for.

3. OpenShift-Specific Integrations #

DeploymentConfig is deeply tied to OpenShift’s native ecosystem, which Deployments don’t support out of the box:

• ImageStream & BuildConfig Sync: As mentioned, ImageChange triggers let DeploymentConfigs automatically consume new builds from BuildConfigs without manual intervention.
• Custom Deployment Strategies: DeploymentConfig supports a Custom strategy that lets you define pre/post rollout hooks (e.g., run a migration job before updating pods) or use a custom pod to orchestrate the deployment process. This is unique to OpenShift—Deployments rely on external tools like Helm hooks or Argo Rollouts for similar functionality.

4. Deployment Strategy Options #

While both support the standard Rolling and Recreate strategies, DeploymentConfig adds extra flexibility:

• Rolling Strategy: Both support maxSurge and maxUnavailable, but DeploymentConfig lets you set timeoutSeconds for the rollout and updatePeriodSeconds between pod updates.
• Recreate Strategy: Identical in behavior—kills all old pods before starting new ones.
• Custom Strategy: Exclusive to DeploymentConfig, as noted above. You can define a customParams section to specify a pod that controls the deployment lifecycle.

5. Label & Selector Management #

The way they label pods and selectors differ, which affects how you query and manage pods:

• DeploymentConfig:
  ReplicationControllers created by DeploymentConfigs use labels like deploymentconfig=<dc-name> and deploymentconfig.revision=<revision-num> to track pods. The selector is fixed based on the DeploymentConfig’s initial labels.
• Deployment:
  ReplicaSets use a unique pod-template-hash label (generated from the pod template) to distinguish between different revisions. This hash is automatically added to the selector, ensuring each ReplicaSet only manages its own pods.

6. Deprecation & Future Roadmap #

A critical point for long-term planning:

• DeploymentConfig is considered a legacy resource in OpenShift. Red Hat has been pushing users to adopt Kubernetes-native Deployments for several releases now, as they align with standard Kubernetes practices and have better support across the broader ecosystem.
• Deployments are the standard workload controller in Kubernetes, so they’re portable across all Kubernetes distributions (not just OpenShift) and get regular updates from the Kubernetes community.

Summary #

DeploymentConfig was built to solve OpenShift’s specific CI/CD and deployment needs before Kubernetes had a standardized solution. Deployments, on the other hand, are the Kubernetes-native standard that’s now preferred for cross-cluster compatibility and ecosystem support. If you’re working on modern OpenShift clusters, Deployments are the way to go—unless you rely on specific legacy OpenShift integrations that DeploymentConfig provides.

内容的提问来源于stack exchange，提问作者Weiwei Jiang