Kubernetes中的复制控制器与部署的区别

Question

我想了解Kubernetes（1.2）中Replication Controller 和 Deployment的区别。阅读了入门文档(http://kubernetes.io/docs/hellonode/)后，我创建了一个Deployment，但它在Web UI上没有显示。

当我从Web UI创建应用程序时，它们被创建为复制控制器。然而它们在功能上似乎非常相似(它们都管理pod和service)。

那么，这两者有什么区别，我该在什么情况下使用它们呢？

- byteSlayer

Answer 1

部署是比复制控制器更高级的概念。它们负责管理副本集的部署（也是一个新概念，但与复制控制器几乎相同），并允许轻松更新副本集以及回滚到先前的部署。

以前，需要使用 kubectl rolling-update 进行操作，但这种方法不太规范，并且没有提供回滚功能。

Kubernetes Dashboard尚未更新支持部署，目前仅支持复制控制器（请参见Deployments not visible in Kubernetes Dashboard）。

编辑：现在面板已支持部署。

- Pixel Elephant

---

那么，Deployments是否应该用于新的应用程序？另外 - 是否有办法使用kubectl命令行工具获取部署/其Pod的统计数据（CPU、内存使用情况）？ - byteSlayer

个人而言，由于缺乏仪表板支持，我迄今为止一直没有使用部署。我不知道是否存在这样的命令 - 我认为您必须以某种方式直接查询Heapster。 - Pixel Elephant

您可以使用 kubectl get deployments、kubectl describe deployments 和 kubectl get pods -l <在部署 pod spec 中放置的标签，例如 foo=bar> 获取部署的统计信息。 - janetkuo

据我所知，这些命令都不会真正显示CPU或内存使用情况，但如果我漏掉了什么，请告诉我。 - Pixel Elephant

@PixelElephant，我错过了您需要查看CPU/内存使用情况的要求。目前我们没有这种类型的命令，但是我们计划添加kubectl top命令来支持此功能。请随时在相关问题中发表评论。 - janetkuo

Answer 2

这里是关于在4年前开始提出的问题的最新答案——2020年答案

2017年有一个很好的回答，您可以查看以下链接：https://www.mirantis.com/blog/kubernetes-replication-controller-replica-set-and-deployments-understanding-replication-options/

现在我们使用的是Kubernetes 1.17版本，它包括3种类型：

Deployment（推荐）

Deployment是一种更高级别的API对象，类似于kubectl rolling-update方式更新其底层的Replica Sets和Pods。如果需要滚动更新功能，则建议使用Deployments，因为与kubectl rolling-update不同，它们是声明式、服务器端的，并且具有其他功能。

ReplicaSet

ReplicaSet是下一代ReplicationController，支持新的基于集合的标签选择器。它主要由Deployment用作协调Pod创建、删除和更新的机制。请注意，除非需要自定义更新协调或根本不需要更新，否则我们建议使用Deployments而不是直接使用Replica Sets。

ReplicationController（不推荐使用）

ReplicationController（复制控制器）是 Kubernetes 中一种用来确保在任何时候指定数量的 Pod 副本都在运行的机制。换句话说，它可以确保一个 Pod 或者一组同质的 Pods 始终处于可用状态。

- Swam Guru

Answer 3

部署仍处于beta版（其API位于extensions/v1beta1下），这可能是为什么它们不在UI中显示的原因。它们在保持Pod存活的基础上自动化状态转换。来自链接页面：

部署提供Pod和Replica Set（下一代复制控制器）的声明性更新。您只需要在部署对象中描述所需状态，部署控制器将以受控速率将实际状态更改为所需状态。您可以定义部署以创建新资源或通过新资源替换现有资源。

它们还提供了回滚历史记录和其他有用功能。

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

- kichik

Answer 4

现在，发布1.1版的仪表盘已支持部署。您可以在不等待k8s 1.3版本的情况下部署或更新仪表盘。例如，您可以使用官方YAML，我们今天刚刚更改为使用部署。

一般来说，我建议（Google和Kubernetes贡献者也是如此）使用部署而不是RC，因为它们是一个更强大的基元（包括滚动更新、版本控制/审计、金丝雀/蓝绿部署、回滚等）。

- puja

---

顺便说一下，我最近写了一篇关于部署和为什么使用它们的博客文章：https://blog.giantswarm.io/understanding-basic-kubernetes-concepts-using-deployments-manage-services-declaratively/ - puja

Answer 5

根据我的经验，部署并不能提供我所需的全部功能。或者说，也许是我使用它们的方式不正确。

当需要重新启动节点服务器时 - 所有由部署启动的 pod 都会失败。我找不到避免这种情况的方法。

但是，

我认为解决方案是复制控制器。至少在描述中写明了它处理这种情况。

我认为主要的部署优势在于你需要不断更改应用程序版本时。

因此，两种方式都是好的，但出于不同的原因。

- Tomas Šatas

---

对于这种情况，复制控制器和部署之间没有区别（毕竟部署只是一个围绕着副本集的包装器）。你想做的是在重新启动节点之前排空节点。一旦它恢复正常，你可以使用uncordon让它再次开始接受Pods。 - Pixel Elephant

如果节点意外失败，该怎么处理？我的意思是 - 如果我没有机会将其排出怎么办？ - Tomas Šatas

也许有点晚了，但我认为运行一个守护进程集应该可以解决这个问题 @TomasŠatas - leberknecht

Answer 6

仪表盘（Web UI）已经进行了大规模的重新设计，以支持管理更多资源（例如Deployments和DaemonSets等），当前的仪表盘在Deployments方面的支持非常有限。

在Kubernetes 1.3中，将很快支持在仪表板中管理部署（请参见问题功能请求：处理部署）。

- janetkuo

Answer 7

2023年：

Kubernetes中的复制控制器与部署

复制控制器是副本集的旧版本。

所以，复制控制器（rc）与副本集（rs）与部署（deploy）。

rs可以使用基于集合的选择器工作，而rc则不能。

以前，我们可以通过以下方式自动更新rc的pod：

kubectl rolling-update old_rc_manifest -f new_rc_manifest

现在，kubectl已经移除了这个功能。

如果我们手动创建rs，就无法自动更新其pod - 也就是说，没有任何命令可以逐个删除旧的pod并逐个创建新的pod。我们必须手动完成。然而，如果我们通过部署来创建rs，那么我们可以使用部署功能自动更新pod。

因此，rc是一个没有优点的旧东西。相反，使用rs。

如果我们想以有用的方式更新rs的pod，请不要手动创建rs，而是使用部署。部署会自动创建rs，rs再创建pod。

- Alex