Introduction
OpenShift deployment is a replication controller based on a user-defined template called a deployment configuration. A template describes a set of objects that can be parameterized and processed to produce a list of objects like services, build configurations, and deployment configurations for creation by OpenShift. It can also be used to assign labels to every object defined in a template. An object is an entity like pod, service and deployment etc, that can be used to create resources in OpenShift, most of these objects have been derived from Kubernetes and extended by OpenShift to provide a more feature-rich development lifecycle platform. OpenShift Deployments are created manually or in response to triggered events. While the Kubernetes deployment controller provides a declarative way to create and update pods and replicaSets.
For managed OpenShift solutions, consider SAAP to simplify your OpenShift eco-system.
Comparison
OpenShift Deployment configuration differs from Kubernetes deployment in the following ways:
1. Dependency
Deployment configuration uses a replication controller while Kubernetes deployment uses a replicaSet controller.
2. Rollback
Deployment configuration controller will rollback to the previous state in case of a failure which Kubernetes deployment does not support this feature.
3. Triggers
Deployment configuration has an implicit ConfigChange trigger that gets triggered due to change in pod template of deployment for a new rollout. It also provides ImageChange trigger. While Kubernetes deployment triggers new rollout on ConfigChange.
4. Lifecycle Hooks
Deployment configuration supports lifecycle hooks, while it is not supported in Kubernetes deployment.
5. Canary Deployments
Deployment configuration supports canary deployment, while it is not supported in Kubernetes deployment.
6. Rollover
In the deployment process, Kubernetes deployments use a controller loop, while OpenShift deployment configuration uses 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.
OpenShift deployment configuration 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.
7. Proportional Scaling
Kubernetes deployment can scale ongoing rollouts because additional replicas are distributed proportionally based on the size of each replica set. While it is not possible in OpenShift deployment controller because it will end up fighting with the deployer process about the size of the new replication controller.
8. Pausing Rollout
Kubernetes deployments ongoing rollout can be paused at any time. While the OpenShift deployment controller cannot be paused during rollout because the deployer process will not be affected until it finishes its job.
How it works
Kubernetes applications need configuration, whether related to authentication with parameters such as API keys, tokens, or other credentials, or general parameters such as logging configuration, environment variables, or other flags. In Kubernetes, these are usually handled by either ConfigMaps or Secrets. And configuration can be updated, whether it be for credential updates or rotation, or toggling logging on or off, or updating a particular environment parameter. Updates may take place frequently or rarely depending on the application, and there will be cases where we would like such updates to be reflected immediately within our applications. At this point, Reloader plays its part by continuously watching Secrets and ConfigMaps. Whenever there is an update in either, Reloader will then check whether any Deployment, DaemonSet or StatefulSet is dependent on it. Once dependent resources are identified, Reloader will trigger automatic updates for all resources.
Improvements
Reloader’s previous version only supported the Kubernetes environment but now it also supports OpenShift. Now Reloader can be deployed using the deployment configuration controller.
In Closing
Stakater Reloader has significant improvements compared to other similar open-source controllers. With its support for different resource types, open-source license, and stable code base, it is a good controller to use when pods need to be automatically restarted on configuration update.
More information is available at the Stakater Reloader GitHub Repository.
To further enhance your OpenShift management capabilities, explore Managing OpenShift Operators Lifecycle with Argo CD. These tools offer complementary functionalities for streamlined management and deployment within your OpenShift environment.
Commentaires