4.3.2　Deployments與Deployment Config的對比

在OpenShift 3版本中的應用部署管理主要使用Deployment Config（簡稱DC），而Kubernetes的應用部署管理使用Deployments，這會讓很多OpenShift的使用者產生困惑。本小節將給出兩者的對比，由于篇幅有限，完整測試內容見Repo中“OpenShift中的Deployment和DeploymentConfig”。

產生不一致的原因在于K8S 1.0在剛推出的時候，缺乏很多企業客戶需要的組件（如Ingress、BuildConfig、DeploymentConfig、RBAC等），為了滿足客戶的需求，紅帽開發了這些組件。OpenShift的開發團隊嘗試將這些代碼提交到K8S社區，有的被采納了，如RBAC，有的雖然未必采納，但Kubernetes根據OpenShift的思路，開發了自己的組件，如Deployments。

現在OpenShift也已經全面兼容Deployments，OpenShift集群的組件也都是采用Deployments而非Deployment Config（為了和K8S統一）。紅帽的建議是如果沒有特殊原因，優先使用Deployments；如果有的應用從OpenShift 3遷移過來，還可以繼續使用Deployment Config。在OpenShift中部署容器化應用時，可以選擇是以Deployment Config還是以Deployments方式部署，然后自動生成對應的配置。

那么，Deployment Config和Deployments的設計架構有什么區別呢？

·從副本控制器上說：

從Deployment Config到Pod的關系是：Deployment Config→Replication Controller→Pod。

從Deployment到Pod的關系是：Deployment→ReplicaSet→Pod

所以說，DeploymentConfig中的Pod副本控制器是Replication Controller，而Deployments中的Pod副本控制器是ReplicaSet。

·從設計架構上說：

根據CAP理論，Deployment Config首選一致性，而Deployment則首選可用性。

對于Deployment Config：如果運行Deployer Pod（Deployment Config在執行部署或Rollout時，通過Deployer Pod完成任務）的OpenShift節點發生故障，Deployer Pod不會在其他OpenShift節點重啟，而是會一直等待故障節點恢復或者節點被手工刪除。

而Deployment Rollouts被Controller Manager驅動，Controller Manager以HA模式運行在OpenShift集群的多個Master節點上，并使用領導者選舉算法來評估可用性而不是一致性。因此，如果一個Deployment在進行Rollout時對應的OpenShift節點出現故障，那么Deployment會在其他可用的節點重啟Pod。

Deployment Config強在版本控制，我們可以通過命令行實現Rollout和Rollback。

---

# oc rollout latest/dc_name 
# oc rollout history dc/dc_name --revision=1

---

Deployment默認是無法像Deployment Config那樣通過命令行或者圖形化界面觸發Rollout（配置有變化也會自動進行）：如果想像Deployment Config那樣Rollout，則需要通過修改Deployment中的注釋值實現手工觸發。

---

# oc patch deployment/tomcat-deployments --patch "{\"spec\":{\"template\":{\"met
    adata\":{\"annotations\":{\"last-restart\":\"`date +'%s'`\"}}}}}"

---

需要指出的是，在Pod正常運行的情況下，如果OpenShift的節點發生故障，Deployment和Deployment Config部署的應用都會在OpenShift其他可用節點重啟，兩者表現是相同的。