mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-06 06:46:26 +01:00
106 lines
4.0 KiB
Plaintext
106 lines
4.0 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * applications/deployments/what-deployments-are.adoc
|
|
|
|
[id="deployments-comparing-deploymentconfigs_{context}"]
|
|
= Comparing Deployments and DeploymentConfigs
|
|
|
|
Both Kubernetes Deployments and {product-title}-provided
|
|
DeploymentConfigs are supported in {product-title}; however, it is
|
|
recommended to use Deployments unless you need a specific feature or behavior
|
|
provided by DeploymentConfigs.
|
|
|
|
The following sections go into more detail on the differences between the two
|
|
object types to further help you decide which type to use.
|
|
|
|
[id="deployments-design_{context}"]
|
|
== Design
|
|
|
|
One important difference between Deployments and DeploymentConfigs is the
|
|
properties of the link:https://en.wikipedia.org/wiki/CAP_theorem[CAP theorem]
|
|
that each design has chosen for the rollout process. DeploymentConfigs prefer
|
|
consistency, whereas Deployments take availability over consistency.
|
|
|
|
For DeploymentConfigs, 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, Deployments 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.
|
|
|
|
[id="delpoymentconfigs-specific-features_{context}"]
|
|
== DeploymentConfigs-specific features
|
|
|
|
[discrete]
|
|
==== Automatic rollbacks
|
|
|
|
Currently, Deployments do not support automatically rolling back to the last
|
|
successfully deployed ReplicaSet in case of a failure.
|
|
|
|
[discrete]
|
|
==== Triggers
|
|
|
|
Deployments have an implicit `ConfigChange` 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:
|
|
|
|
[source,terminal]
|
|
----
|
|
$ oc rollout pause deployments/<name>
|
|
----
|
|
|
|
[discrete]
|
|
==== Lifecycle hooks
|
|
|
|
Deployments do not yet support any lifecycle hooks.
|
|
|
|
[discrete]
|
|
==== Custom strategies
|
|
|
|
Deployments do not support user-specified Custom deployment
|
|
strategies yet.
|
|
|
|
[id="delpoyments-specific-features_{context}"]
|
|
== Deployments-specific features
|
|
|
|
[discrete]
|
|
==== Rollover
|
|
|
|
The deployment process for Deployments is driven by a controller
|
|
loop, in contrast to DeploymentConfigs which use deployer pods for every
|
|
new rollout. This means that a Deployment can have as many active
|
|
ReplicaSets as possible, and eventually the deployment controller will scale
|
|
down all old ReplicaSets and scale up the newest one.
|
|
|
|
DeploymentConfigs 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 ReplicationController. Because of this, only two
|
|
ReplicationControllers can be active at any point in time. Ultimately, this
|
|
translates to faster rapid rollouts for Deployments.
|
|
|
|
[discrete]
|
|
==== Proportional scaling
|
|
|
|
Because the Deployment controller is the sole source of truth for the sizes of
|
|
new and old ReplicaSets owned by a Deployment, it is able to scale ongoing
|
|
rollouts. Additional replicas are distributed proportionally based on the size
|
|
of each replica set.
|
|
|
|
DeploymentConfigs cannot be scaled when a rollout is ongoing because the
|
|
DeploymentConfig controller will end up having issues with the deployer
|
|
process about the size of the new ReplicationController.
|
|
|
|
[discrete]
|
|
==== Pausing mid-rollout
|
|
|
|
Deployments can be paused at any point in time, meaning you can also
|
|
pause ongoing rollouts. On the other hand, you cannot pause deployer pods
|
|
currently, so if you try to pause a DeploymentConfig in the middle of a
|
|
rollout, the deployer process will not be affected and will continue until it
|
|
finishes.
|