Kubernetes中的Replication Controller VS部署

Question 1

我想知道复制控制器和Kubernetes（1.2）中的Deployment有什么区别。浏览入门文档（http://kubernetes.io/docs/hellonode/），我已经创建了一个部署-但它没有显示在Web UI上。

当我从Web UI创建应用程序时-它们被创建为复制控制器。但是在功能上，它们看起来非常相似（它们既管理pod并提供服务）。

所以-有什么区别，什么时候应该使用它们？

Question 2

部署是比Replication Controllers更新和更高级别的概念。它们管理副本集的部署（也是一个较新的概念，但与复制控制器相当），并允许轻松更新副本集以及回滚到以前的部署的能力。

以前必须这样做，kubectl rolling-update因为它不是声明性的，并且不提供回滚功能。

~~Kubernetes Dashboard尚未进行更新以支持Deployment，并且当前仅支持Replication Controller（请参阅Kubernetes Dashboard中不可见的Deployment）。~~

编辑：仪表板现在支持部署。

Question 3

部署仍处于测试阶段（其API在之下extensions/v1beta1），这可能是为什么它们未显示在UI中的原因。它们仅使Pod处于活动状态即可自动进行状态转换。从链接页面：

部署为Pod和副本集（下一代Replication Controller）提供声明性更新。您只需要在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.

Question 4

这是对4年之前于2016年开始的问题的最新2020年答案

2017年给出了一个很好的答案 https://www.mirantis.com/blog/kubernetes-replication-controller-replica-set-and-deployments-understanding-replication-options/

现在我们在Kubernetes版本-1.17中，我们得到了3种类型

部署（推荐）

部署是一个高级API对象，它以类似于kubectl滚动更新的方式更新其基础副本集及其Pod。如果您需要此滚动更新功能，则建议部署，因为与kubectl滚动更新不同，它们是声明性的，服务器端的，并具有其他功能。

复制集

ReplicaSet是支持新的基于集合的标签选择器的下一代ReplicationController。部署主要将其用作协调Pod创建，删除和更新的机制。请注意，除非您需要自定义更新编排或完全不需要更新，否则我们建议使用部署而不是直接使用副本集。

ReplicationController（不推荐）

确保任何时候都在运行指定数量的Pod副本。换句话说，ReplicationController确保一个容器或一组相同的容器始终处于可用状态。

Question 5

现在，在1.1版中，仪表板确实支持部署。您可以部署或更新仪表板，而不必等待1.3版本的k8s。例如，您可以使用官方的YAML，我们将其更改为今天使用Deployments。

通常，我建议（以及来自Google和Kubernetes贡献者的人也这样做）使用RC上的Deployments，因为它们是更强大的原语（包括滚动更新，版本控制/审计，canaray /蓝绿色部署，回滚等）。。

Question 6

仪表板（Web UI）经过了重新设计，可以支持管理更多资源（例如Deployments和DaemonSets，等等），而当前的仪表板不允许过多的关注Deployments。

不久将在kubernetes 1.3中支持在仪表板中管理部署（请参阅发行功能请求：处理部署）。

Question 7

根据我的经验，部署并不能提供我需要的所有功能。或者，也许是我以错误的方式使用它们。

当需要重新启动节点服务器时，该服务器上运行的所有Pod都是由部署启动的，但确实会失败。而且我找不到避免这种情况的方法。

但，

Think解决方案是复制控制器。至少在描述中写成处理了这种情况。

如我所见，主要的部署优势是需要不断更改应用程序版本时。

因此，两种方法都不错，但原因有所不同。