mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-07 00:48:01 +01:00
73 lines
4.1 KiB
Plaintext
73 lines
4.1 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * applications/deployments/what-deployments-are.adoc
|
|
|
|
[id="deployments-comparing-deploymentconfigs_{context}"]
|
|
= Comparing Deployment and DeploymentConfig objects
|
|
|
|
Both Kubernetes `Deployment` objects and {product-title}-provided `DeploymentConfig` objects are supported in {product-title}; however, it is recommended to use `Deployment` objects unless you need a specific feature or behavior provided by `DeploymentConfig` objects.
|
|
|
|
The following sections go into more detail on the differences between the two object types to further help you decide which type to use.
|
|
|
|
include::snippets/deployment-config-deprecated.adoc[]
|
|
|
|
[id="deployments-design_{context}"]
|
|
== Design
|
|
|
|
One important difference between `Deployment` and `DeploymentConfig` objects is the properties of the link:https://en.wikipedia.org/wiki/CAP_theorem[CAP theorem] that each design has chosen for the rollout process. `DeploymentConfig` 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.
|
|
|
|
[id="delpoyments-specific-features_{context}"]
|
|
== Deployment-specific features
|
|
|
|
[discrete]
|
|
==== Rollover
|
|
|
|
The deployment process for `Deployment` objects is driven by a controller loop, in contrast to `DeploymentConfig` objects that 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 might conflict when 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 results in faster rapid rollouts for `Deployment` objects.
|
|
|
|
[discrete]
|
|
==== Proportional scaling
|
|
|
|
Because the deployment controller is the sole source of truth for the sizes of new and old replica sets owned by a `Deployment` object, it can scale ongoing rollouts. Additional replicas are distributed proportionally based on the size of each replica set.
|
|
|
|
`DeploymentConfig` objects cannot be scaled when a rollout is ongoing because the controller will have issues with the deployer process about the size of the new replication controller.
|
|
|
|
[discrete]
|
|
==== Pausing mid-rollout
|
|
|
|
Deployments can be paused at any point in time, meaning you can also pause ongoing rollouts. However, you currently cannot pause deployer pods; if you try to pause a deployment in the middle of a rollout, the deployer process is not affected and continues until it finishes.
|
|
|
|
[id="delpoymentconfigs-specific-features_{context}"]
|
|
== DeploymentConfig object-specific features
|
|
|
|
[discrete]
|
|
==== Automatic rollbacks
|
|
|
|
Currently, deployments do not support automatically rolling back to the last successfully deployed replica set in case of a failure.
|
|
|
|
[discrete]
|
|
==== Triggers
|
|
|
|
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:
|
|
|
|
[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.
|