Replication Controller VS Deployment in Kubernetes

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.

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.

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.