Kubernetes Deployments Support

    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 ), which orchestrate pod lifecycles.

    For example, this definition of a Kubernetes deployment creates a replica set to bring up one hello-openshift pod:

    Example Kubernetes Deployment Definition hello-openshift-deployment.yaml

    After saving the definition to a local file, you could then use it to create a Kubernetes deployment:

    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 and describe. For the object type, use deployments or for Kubernetes deployments and replicasets or rs for replica sets.

    See the Kubernetes documentation for more details about and Replica Sets, substituting for kubectl in CLI usage examples.

    Kubernetes Deployments Versus Deployment Configurations

    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.

    Automatic Rollbacks

    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.

    Triggers

    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:

    Lifecycle Hooks

    Kubernetes deployments do not support any lifecycle hooks.

    Custom Strategies

    Kubernetes deployments do not yet support user-specified Custom deployment strategies yet.

    Canary Deployments

    Kubernetes deployments do not yet run canaries as part of a new rollout.

    Test Deployments

    Kubernetes deployments do not support running test tracks.

    Kubernetes Deployment-Specific Features

    Rollover

    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.

    Proportional Scaling

    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.

    Pausing Mid-rollout

    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.