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

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.

Answer 2

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 3

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 4

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 5

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.).