部署是比复制控制器更新和更高级别的概念。它们管理副本集的部署（也是一个较新的概念，但与复制控制器相当），并允许轻松更新副本集以及回滚到以前的部署。
以前，这必须用kubectl rolling-update来完成，它不是声明性的，也不提供回滚特性。
Kubernetes Dashboard尚未更新以支持部署，目前仅支持复制控制器（请参阅Kubernetes Dashboard中不可见的部署）。
编辑： Jmeter 板现在支持部署。

这是最新的 *2020答案 * 的问题开始于2016年，4年前
一个很好的答案在2017 https://www.mirantis.com/blog/kubernetes-replication-controller-replica-set-and-deployments-understanding-replication-options/中给出
现在我们在Kubernetes version - 1.17，我们有3种类型

部署（推荐）

Deployment是一个更高级别的API对象，它以类似于kubectl rolling-update的方式更新其底层副本集及其Pod。如果您想要这种滚动更新功能，建议使用部署，因为与kubectl rolling-update不同，它们是声明式的，服务器端的，并且具有其他功能。

ReplicaSet

ReplicaSet是下一代ReplicationController，支持新的基于集合的标签选择器。它主要被Deployment用作编排pod创建、删除和更新的机制。请注意，我们建议您使用“部署”，而不是直接使用“副本集”，除非您需要自定义更新业务流程或根本不需要更新。

ReplicationController（不推荐）

确保指定数量的pod副本同时运行。换句话说，ReplicationController确保一个pod或一组同类的pod始终处于启动状态并且可用。

Deployments仍处于测试阶段（他们的API在extensions/v1beta1下），这可能是他们没有显示在UI中的原因。它们在保持pod存活的基础上自动化状态转换。从链接页面：
Deployment为Pod和副本集（下一代复制控制器）提供声明性更新。您只需要在Deployment对象中描述所需的状态，Deployment控制器将以受控的速率将实际状态更改为所需的状态。您可以定义部署以创建新资源，或用新资源替换现有资源。
它们还提供了卷展历史记录和其他有用的功能。

$ 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

它也跟踪变化。

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

现在release 1.1 Dashboard支持Deployments。您可以部署或更新您的 Jmeter 板，而不必等待k8s的1.3版本。例如，您可以使用official YAML，我们刚刚更改为使用Deployments。
一般来说，我建议（Google和Kubernetes的贡献者也建议）使用Deployments over RC，因为它们是一个更强大的原语（包括滚动更新，版本控制/审计，canaray/绿蓝部署，回滚等）。

Jmeter 板（Web UI）经过了巨大的重新设计，以支持管理更多的资源（如Deployments和DaemonSets等），而当前的 Jmeter 板不允许太多关于Deployments。
在dashboard中管理部署将很快在kubernetes 1.3中得到支持（请参阅问题Feature request: handle Deployments）。

根据我的经验，部署并不能提供我需要的所有功能。或者，也许，我正在以错误的方式使用它们。
当需要重新启动节点服务器时-部署启动的该服务器上运行的所有pod-确实会失败。我找不到一个方法来避免这一点。
但是
认为解决方案是一个复制控制器。至少在描述中写着它处理这种情况。
在我看来，主要的部署优势是当您需要不断更改应用程序的版本时。
这两种方法都很好，但原因不同。

2023年：
复制控制器VS Kubernetes中的部署
复制控制器是副本集的旧版本。
因此，复制控制器（rc）与复制集（rs）与部署（deploy）也是如此。
RS可以与基于集合的选择器一起工作。RC不能。
在我们可以通过自动更新rc的pod之前
kubectl滚动更新old_rc_manifest -f new_rc_manifest
现在这个功能已经从kubectl中删除了。
如果我们手动创建rs，我们不能自动更新它的pod-也就是说，没有任何命令可以逐个删除旧的pod并逐个创建新的pod。我们应该手动操作但是，如果我们通过deployment创建rs，那么我们可以使用deploy特性自动更新pod。
所以rc是没有优点的老东西。而是使用RS。如果我们想以一种有用的方式更新rs的pod，不要手动创建rs，而是使用deploy。deploy automatically create rs，rs create pod.