Menu
After far as I know:
vs.
Otherwise, do these two resources have additional differences?
The more detail the better.
667
Both Kubernetes and OpenShift are popular container management systems, and each has its unique features and benefits. While Kubernetes helps automate application deployment, scaling, and operations, OpenShift is the container platform that works with Kubernetes to help applications run more efficiently.
In short, a pod is the core building block for running applications in a Kubernetes cluster; a deployment is a management tool used to control the way pods behave.
Docker, Kubernetes and OpenShift are independent container technologies that are related to each other in many ways and complement each other. Kubernetes can deploy Docker images and orchestrate. Similarly, OpenShift seamlessly manages the Kubernetes cluster. With Kubernetes, one can manage hundreds of containers.
A Deployment provides declarative updates for Pods and Replica Sets (the next-generation Replication Controller). You only need to describe the desired state in a Deployment object, and the Deployment controller will change the actual state to the desired state at a controlled rate for you.
A DeploymentConfig (DC) in OpenShift is more or less equivalent to a Kubernetes Deployment, nowadays. Main difference (besides that one is using ReplicationController and the other using ReplicaSet as you rightly pointed out) is that
there are a few things you can do with a DeploymentConfig (around triggers) that you can't do with a Deployment.
DeploymentConfig's are first-class citizens in the Web console.
The reason DeploymentConfig's exist is because we (Red Hat) are innovating. In other words: DeploymentConfig's predate Deployment's and while we're always trying to propose these innovations upstream, they are not always accepted by the community as is. For example, in the case of RBAC, the stuff we had in OpenShift was accepted upstream and that's why you have the same RBAC resources etc. now in OpenShift and Kubernetes. With DeploymentConfig's that was not the case. Over time one would expect that DeploymentConfig's are phased out in favor of Deployment's but I can't give you a timeline. If portability is your primary concern, I'd say, use Deployment's.
150
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
