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
×
Kubernetes deployments Support
Important
Azure Red Hat OpenShift 3.11 will be retired 30 June 2022. Support for creation of new Azure Red Hat OpenShift 3.11 clusters continues through 30 November 2020. Following retirement, remaining Azure Red Hat OpenShift 3.11 clusters will be shut down to prevent security vulnerabilities.
Follow this guide to create an Azure Red Hat OpenShift 4 cluster. If you have specific questions, please contact us
deployments Object Type
Kubernetes provides a first-class object type in Azure Red Hat OpenShift called deployments . This object type (referred to here as Kubernetes deployments for distinction) serves as a descendant of the deployment configuration object type.
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:
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:
$ 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 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.
Kubernetes deployments Versus deployment Configurations
Because deployment configurations existed in Azure Red Hat OpenShift prior to deployments being added in Kubernetes 1.2, the latter object type naturally diverges slightly from the former. The long-term goal in Azure Red Hat OpenShift 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 Azure Red Hat OpenShift. Given the current feature set of Kubernetes deployments, you may want to use them instead of deployment configurations in Azure Red Hat OpenShift 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.
deployment Configuration-Specific Features
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:
$ 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 Azure Red Hat OpenShift-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 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.
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.
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.