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其他可用节点重启，两者表现是相同的。