In the upstream Kubernetes project, a new first-class object type called deployments was added in version 1.2. This object type (referred to here as Kubernetes deployments for distinction) serves as a descendant of the deployment configuration object type that has been in OpenShift Origin since 1.0. Starting in OpenShift Origin 1.4, support for Kubernetes deployments is available as a Tech Preview feature.
Like deployment configurations, Kubernetes deployments describe the desired state of a particular component of an application as a pod template. Kubernetes deployments create replica sets (an iteration of replication controllers), which orchestrate pod lifecycles.
For example, this definition of a Kubernetes deployment creates a replica set to bring up three nginx pods:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
After saving the definition to a local file, you could then use it to create a Kubernetes deployment:
$ oc create -f nginx-deployment.yaml
You can use the CLI to inspect and operate on Kubernetes deployments and replica
sets like other object types, as described in
Common
Operations, like get and describe. For the object type, use deployments
or deploy for Kubernetes deployments and replicasets or rs for replica
sets.
See the Kubernetes documentation for more details about
Deployments and
Replica Sets,
substituting oc for kubectl in CLI usage examples.
Because deployment configurations existed in OpenShift Origin prior to deployments being added in Kubernetes 1.2, the latter object type naturally diverges slightly from the former. The long-term goal in OpenShift Origin is to reach full feature parity in Kubernetes deployments and switch to using them as a single object type that provides fine-grained management over applications.
Kubernetes deployments are supported to ensure upstream projects and examples that use the new object type can run smoothly on OpenShift Origin. Given the current feature set of Kubernetes deployments, you may want to use them instead of deployment configurations in OpenShift Origin if you do not plan to use any of the following in particular:
The following sections go into more details on the differences between the two object types to further help you decide when you might want to use Kubernetes deployments over deployment configurations.
Kubernetes deployments do not support automatically rolling back to the last successfully deployed replica set in case of a failure. This feature should be added soon.
Kubernetes 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:
$ oc rollout pause deployments/<name>
At the moment, Kubernetes deployments do not support ImageChange triggers. A
generic triggering mechanism has been proposed upstream, but it is unknown if
and when it may be accepted. Eventually, a OpenShift Origin-specific mechanism
could be implemented to layer on top of Kubernetes deployments, but it would be
more desirable for it to exist as part of the Kubernetes core.
The deployment process for Kubernetes deployments is driven by a controller loop, in contrast to deployment configurations which use deployer pods for every new rollout. This means that a Kubernetes deployment 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.
Deployment configurations can have at most one deployer pod running, otherwise multiple deployers end up fighting with each other 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 Kubernetes deployments.
Because the Kubernetes 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.
Deployment configurations cannot be scaled when a rollout is ongoing because the deployment configuration controller will end up fighting with the deployer process about the size of the new replication controller.
Kubernetes 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 deployment configuration in the middle of a rollout, the deployer process will not be affected and will continue until it finishes.