前言

• 〖重磅！慟！！〗在 OCP 4.14 之後，Red Hat 將 DeploymentConfig 標記為即將淘汰的 Workload。 以前搞出 DeploymentConfig 是為了解決 Deployment 缺少的功能。 但隨著 K8s 原生 Deployment 已經成熟，為了減少重複功能，且讓 OCP 與上游的 K8s 一致，因此之後會建議讓 DeploymentConfig 改成 Deployment。
• 另外，不能因為這東西未來被放棄，就不了解，因為還是有很高機會會遇到，歷史包袱到處都有！！
• 雖然在本系列 【Day 5】 從文件了解 K8s 的基本 Workload 及使用場景 有略提到 Deployment，但尚未特別拿出來和 OCP 的慣用做法進行比較。 在對於 OCP 的操作有初步認識後，來看一下 K8s/OCP 支援的 Deployment 和 OCP 特有的 DeploymentConfig。

名詞

Deployment

• 打開 K8s 文件，Kubernetes Documentation / Concepts / Workloads / Workload Management / Deployments
  • 連結： https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

  副標題寫著： A Deployment manages a set of Pods to run an application workload, usually one that doesn't maintain state.

• Deployment 裡面會寫出 期望狀態 (Desired State)
  • 希望運行的 Pod 運行的數量、最高或最低的數量。
  • 用什麼 container image ?
  • 用什麼方式升級 ?

  但他不會「真正去操控狀態」，因為是 「Deployment Controller」 去操控。

Deployment Controller

• 可以參考 OCP 文件，7.1.4.2. Deployment-specific features
  • 連結： https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/building_applications/deployments
• 監聽 API Server 中 Deployment 物件的變化
• 建立/更新 ReplicaSet
• ReplicaSet 再去管控 Pod 的數量與狀態
• 如果 Pod Crash、ReplicaSet < desired replicas，會重新建立 Pod

  [Deployment Spec]   (宣告式狀態)
          │
          ▼
  [Deployment Controller]  ← 控制器邏輯 (在 kube-controller-manager 裡)
          │
          ▼
  [ReplicaSet(s)]   ← 實際建立/刪除 Pods
          │
          ▼
  [Pods] (running containers)
  

  Deployment 定義規則 (desired state)
  Deployment Controller 負責管控 Pods 狀態（透過 ReplicaSet 來間接管理）

DeploymentConfig

• 先打開文件連結，閱讀 OCP 文件 / Build Application / Chapter 7. Deployments
  • 連結： https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/building_applications/deployments
• 與 Deployment 的比較（重點差異）
  • Deployment (K8s)：單純控制 Pod 副本數 + 滾動更新，需外部工具來觸發更新。
  • DeploymentConfig (OCP)：內建 自動觸發機制 (ImageStream/BuildConfig)，天然與 OCP CI/CD 整合。

（原） K8s & OCP Deployment 比較表

淘汰 DeploymentConfig

• 未來一陣子都可以預期得到，要把 OCP特有種 DeploymentConfig 改成 K8s原生種 Deployment，先用下表格來評估差異吧。

小結

• 二分法判斷能不能修改？
  • 如果只是一般 K8s 相容部署 → 可以改回去 用 Deployment。
  • 如果需要用到跟 OCP BuildConfig、ImageStream 整合，自動化 CI/CD → 只能繼續使用 DeploymentConfig。
• 現在 OCP 已經提供更完整的 Pipelines (Tekton)、ArgoCD (GitOps)，這些比 DC 更強大、彈性。
• Red Hat 承諾 DC 還會「支援」（不會馬上消失），但只修 安全性與重大錯誤，不再投入新功能。

轉換方式說明

1. 清查現有 DC，確認哪些 DC 有使用 ImageStream trigger、哪些是 手動觸發。

   oc get dc -A
   

2. 建立等價 Deployment YAML
   • 把 DC 裡的 spec.template（Pod 模板部分）搬到 Deployment。
   • 設定 replicas、strategy 等保持一致。
3. 範例 / 原 DC

   apiVersion: apps.openshift.io/v1
   kind: DeploymentConfig
   metadata:
     name: myapp
   spec:
     replicas: 3
     strategy:
       type: Rolling
     template:
       spec:
         containers:
         - name: myapp
           image: image-registry.openshift-image-registry.svc:5000/myproj/myapp:latest
   
   

4. 範例 / 修成 Deployment

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: myapp
   spec:
     replicas: 3
     strategy:
       type: RollingUpdate
     selector:
       matchLabels:
         app: myapp
     template:
       metadata:
         labels:
           app: myapp
       spec:
         containers:
         - name: myapp
           image: image-registry.openshift-image-registry.svc:5000/myproj/myapp:latest
   
   

5. 另外處理 ImageStream / BuildConfig
   • 原本很潮的串接 CI/CD，現在要替換成別種...
   • DC 的 image trigger 要改由外部工具處理：
     • Tekton Pipeline：監聽 Build 完成 → 更新 Deployment YAML → Apply
     • ArgoCD (GitOps)：監聽 Git Repo → 同步到 Deployment
     • Webhook：由 Image Registry 推送通知 → oc rollout restart
   • 簡單替代方案（短期）：手動 oc rollout restart deploy/<name>
6. 測試部署
   部署新的 Deployment，觀察行為

   oc apply -f myapp-deployment.yaml
   oc rollout status deploy/myapp
   

7. 切換流量
   • 先同時部署新 Deployment 與舊 DeploymentConfig。
   • 切換 Service / Route 指到新的 Deployment Pod。
   • 確認穩定後，刪除舊的 DeploymentConfig。

結論

• 棄坑真的很阿雜，不過既然原生 K8s 都有了，那棄坑合理啦。