Kubernetes Deployments Support
Kubernetes provides a first-class object type in OKD called deployments . This object type (referred to here as Kubernetes deployments for distinction) serves as a descendant of the deployment configuration object type.
Support for Kubernetes deployments is available as a Technology 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 one hello-openshift pod:
apiVersion: apps/v1 kind: Deployment metadata: name: hello-openshift spec: replicas: 1 selector: matchLabels: app: hello-openshift template: metadata: labels: app: hello-openshift spec: containers: - name: hello-openshift image: openshift/hello-openshift:latest ports: - containerPort: 80
After saving the definition to a local file, you could then use it to create a Kubernetes deployment:
$ oc create -f hello-openshift-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
describe. For the object type, use
deploy for Kubernetes deployments and
rs for replica sets.
Because deployment configurations existed in OKD prior to deployments being added in Kubernetes 1.2, the latter object type naturally diverges slightly from the former. The long-term goal in OKD 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 OKD. Given the current feature set of Kubernetes deployments, you may want to use them instead of deployment configurations in OKD 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 OKD-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.
Kubernetes deployments do not yet support user-specified Custom deployment strategies yet.
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.