CHAPTER 3. DEPLOYMENTS One important difference between  Deployment  and  DeploymentConfig  objects is the properties of the  CAP theorem  that each design has chosen for the rollout process.   objects prefer consistency, whereas  Deployments  objects take availability over consistency. For  DeploymentConfig  objects, if a node running a deployer pod goes down, it will not get replaced. The process waits until the node comes back online or is manually deleted. Manually deleting the node also deletes the corresponding pod. This means that you can not delete the pod to unstick the rollout, as the kubelet is responsible for deleting the associated pod. However, deployment rollouts are driven from a controller manager. The controller manager runs in high availability mode on masters and uses leader election algorithms to value availability over consistency. During a failure it is possible for other masters to act on the same deployment at the same time, but this issue will be reconciled shortly after the failure occurs. 3.1.4.2. DeploymentConfig object-specific features Automatic rollbacks Triggers Lifecycle hooks Custom strategies 3.1.4.3. Deployment-specific features Rollover Proportional scaling Pausing mid-rollout Currently, deployments do not support automatically rolling back to the last successfully deployed replica set in case of a failure. Deployments have an implicit config change trigger in that every change in the pod template of a deployment automatically triggers a new rollout. If you do not want new rollouts on pod template changes, pause the deployment: $ oc rollout pause deployments/<name> Deployments do not yet support any lifecycle hooks. Deployments do not support user-specified custom deployment strategies yet. The deployment process for  Deployment  objects is driven by a controller loop, in contrast to  DeploymentConfig  objects which use deployer pods for every new rollout. This means that the  Deployment  object can have as many active replica sets as possible, and eventually the deployment controller will scale down all old replica sets and scale up the newest one. DeploymentConfig  objects can have at most one deployer pod running, otherwise multiple deployers end up conflicting while trying to scale up what they think should be the newest replication controller. Because of this, only two replication controllers can be active at any point in time. Ultimately, this translates to faster rapid rollouts for  Deployment  objects. Because the deployment controller is the sole source of truth for the sizes of new and old replica sets owned by a deployment, it is able to scale ongoing rollouts. Additional replicas are distributed proportionally based on the size of each replica set. Deployments cannot be scaled when a rollout is ongoing because the controller will end up having issues with the deployer process about the size of the new replication controller. 49