Openshift deployment strategies
A deployment strategy defines how the old pods are replaced with new ones in a Kubernetes deployment.
Examples of scenarios that require different deployment strategies:
- Recreate all the pods because the new ones use a different database schema.
- Update an application in batches to prevent downtime and/or reduce the resources used while deploying.
- To run more than one version in parallel to test how different behaviours affects the user experience.
Differences between Kubernetes and Openshift deployments
In Kubernetes deployments are done with Deployment objects, but in Openshift it is different: it uses an intermediate object called “Deployment Configuration Object”.
The Deployment Configuration Object internally relies the management of pods to other object called “ReplicationController”. The ReplicationController is responsible of achiving the desired state for the deploy (Example: configure dependencies, scale up/down, monitor the health and errors of the pods, etc.) If ReplicationController fails it is scaled down and replaced by the previous ReplicationController.
Another difference is that when a cluster node goes down, Openshift will deploy new pods in other nodes to replace the ones in the failing node. In the same situation Kubernetes waits until the node returns to life.
Also, Openshift have these advantages over Kubernetes:
- Openshift has more deployment strategies.
- All Openshift deployments are Canary: If the deploy fails Openshift will restore the previous ReplicationController automatically.
Deployment strategies
The deployment strategies are applied by a deployment pod that manages the creation of pods for the workloads. After the deployment is completed the deployment pod is stopped.
Deployment strategies inherited from Kubernetes:
- Recreate: Destroys all the pods and after creates the new ones. This is the fastest strategy because all pods are created at once. Also, it does not consume additional resources. The dissadvantages are: it causes downtime in the period between the pods are destroyed and the new ones become ready, and rollback can fail because old pods are destroyed at the beginning of the deployment. Recreate is recommended for lift and shift applications, workloads that have to migrate dependencies before running the new pods (Example: Database migrations), or dependencies .
- Rolling: This strategy replaces pods in batches to deploy at controlled rate. Creates pods with the new version and waits until it are ready, after, balances the network traffic from the old pods to the new, and finally deletes the old pods. The advantage is that there is no downtime in the deployment and it’s safe to rollback because old pods are destroyed only after the new ones are ready. The dissadvantage is that requires extra infrastructure for deploying.
Openshift deployment strategies:
- Custom strategy: This strategy runs a deployment pod with custom image that contains the desired behaviour. You can make calls to Kubernetes API or Openshift API using a service account token.
- Lifecycle hooks: Actually, this isn’t an independent deployment strategy, but it is complementary to any other deployment strategy. Lifecycle hooks are commands that can be run at some states of the deployment process to provide custom behaviour. It’s similar to Custom Strategy, but more simple since it doesn’t require to run a custom deployment pod.
