Replication Controller VS Deployment in Kubernetes

Question

I wanted to know what is the difference between a Replication Controller and a Deployment within Kubernetes (1.2). Going through the getting started document ( http://kubernetes.io/docs/hellonode/ ) I have created a deployment - but it doesn't show up on the web UI.

When I create apps from the web UI - they are created as replication controllers. Functionally though, they seem very similar (they both manage pods and have services).

So - what is the difference and when should I use each?

Answer 1

Deployments are a newer and higher level concept than Replication Controllers. They manage the deployment of Replica Sets (also a newer concept, but pretty much equivalent to Replication Controllers), and allow for easy updating of a Replica Set as well as the ability to roll back to a previous deployment.

Previously this would have to be done with kubectl rolling-update which was not declarative and did not provide the rollback features.

Kubernetes Dashboard has not yet been updated to support Deployments, and currently only supports Replication Controllers (see Deployments not visible in Kubernetes Dashboard ).

EDIT: The dashboard now supports Deployments.

Answer 2

Here is the latest 2020 answer to the question started in 2016, 4 years ago

A good answer is given in 2017 https://www.mirantis.com/blog/kubernetes-replication-controller-replica-set-and-deployments-understanding-replication-options/

Now we are in Kubernetes version - 1.17 , we got 3 types

Deployment (Recommended)

Deployment is a higher-level API object that updates its underlying Replica Sets and their Pods in a similar fashion as kubectl rolling-update. Deployments are recommended if you want this rolling update functionality, because unlike kubectl rolling-update, they are declarative, server-side, and have additional features.

ReplicaSet

ReplicaSet is the next-generation ReplicationController that supports the new set-based label selector. It's mainly used by Deployment as a mechanism to orchestrate pod creation, deletion and updates. Note that we recommend using Deployments instead of directly using Replica Sets, unless you require custom update orchestration or don't require updates at all.

ReplicationController (Not Recommended)

Ensures that a specified number of pod replicas are running at any one time. In other words, a ReplicationController makes sure that a pod or a homogeneous set of pods is always up and available.

Answer 3

Deployments are still in beta (their API is under extensions/v1beta1 ), which is probably why they don't show up in the UI. They automate state transitions on top of just keeping pods alive. From the linked page:

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. You can define Deployments to create new resources, or replace existing ones by new ones.

They also provide rollout history and other useful features.

$ kubectl rollout history deployment/nginx-deployment
deployments "nginx-deployment":
REVISION    CHANGE-CAUSE
1           kubectl create -f docs/user-guide/nginx-deployment.yaml --record
2           kubectl apply -f docs/user-guide/new-nginx-deployment.yaml
3           kubectl apply -f docs/user-guide/bad-nginx-deployment.yaml

It keeps track of the changes too.

$ kubectl rollout history deployment/nginx-deployment --revision=2
deployments "nginx-deployment" revision 2
Labels:     app=nginx,pod-template-hash=1564180365
Annotations:    kubernetes.io/change-cause=kubectl apply -f docs/user-guide/new-nginx-deployment.yaml
Image(s):   nginx:1.9.1
No volumes.

Answer 4

Now with release 1.1 Dashboard does support Deployments. You can deploy or update your dashboard without having to wait for the 1.3 release of k8s. You can for example use the official YAML , which we just changed to use Deployments today.

Generally, I'd recommend (and folks from Google and Kubernetes contributors also do) using Deployments over RCs as they are a much more powerful primitive (include rolling updates, versioning/auditing, canaray/green-blue deployments, rollbacks, etc.).

Answer 5

The dashboard (web UI) has been hugely redesigned to support managing more resources (like Deployments and DaemonSets , etc.) and the current dashboard doesn't allow much regarding Deployments .

Managing Deployments in dashboard will be supported soon in kubernetes 1.3 (refer to issue Feature request: handle Deployments ).

Answer 6

From my experience deployments provide not all the functionality I need. Or, maybe, I am using them in a wrong fashion.

When there is a need to restart node server - all pods running on that server started by deployment - do fail. And I can not find a way to avoid this.

But,

Think solution is a replication controller. At least in description it is written that it handles such cases.

Main deployment advantage, as I see it, is when you need to change version of your app constantly.

So both ways are good but for different reasons.