复制控制器
一个复制控制器确保在任意时刻运行指定数量的pod副本。换句话说，ReplicationController确保一个pod或一组相同的pod始终处于可用状态。
ReplicationController是如何工作的
如果POD太多，ReplicationController将终止多余的POD。如果POD太少，ReplicationController将启动更多的POD。与手动创建的POD不同，ReplicationController维护的POD在失败、删除或终止时将自动替换。例如，您的POD将在之后在节点上重新创建r中断性维护，如内核升级。因此，即使您的应用程序只需要一个pod，您也应该使用ReplicationController。ReplicationController类似于进程管理器，但它不是监视单个节点上的单个进程，而是跨多个节点监视多个pod多个节点。
ReplicationController在讨论中通常缩写为“rc”，并作为kubectl命令中的快捷方式。
一个简单的例子是创建一个ReplicationController对象来可靠地无限期运行Pod的一个实例。一个更复杂的用例是运行一个复制服务的几个相同的副本，比如web服务器。
运行ReplicationController的示例
此示例ReplicationController配置运行nginx web服务器的三个副本。
apiVersion：v1种类：复制控制器元数据：的名字：nginx规范：副本：3.选择器：应用程序：nginx样板：元数据：的名字：nginx标签：应用程序：nginx规范：容器：-的名字：nginx图像：nginx港口：-集装箱港口：80通过下载示例文件运行示例作业，然后运行命令:
kubectl应用-fhttps://k8s.io/examples/controllers/replication.yaml输出类似如下:
已创建replicationcontroller/nginx使用该命令检查ReplicationController的状态。
kubectl描述replicationcontrollers / nginx输出类似如下:
名称：nginx命名空间：默认选择器：app=nginx标签：app=nginx注释：副本：3个当前/3个所需的Pod状态：0正在运行/3正在等待/0成功/0失败的Pod模板：标签：app=nginx容器：nginx:Image:nginx端口：80/TCP环境：装载：卷：事件：首次看到的Su最近看到的计数bobjectPath类型原因消息------------------------------20s 20s 1{复制控制器}正常成功创建pod:nginx-qrm3m 20s 20s 1{复制控制器}正常成功创建pod:nginx-3ntk0 20s 20s 1{复制控制器}正常成功创建pod:nginx-4ok8v 在这里，创建了三个吊舱，但没有一个正在运行，这可能是因为图像正在被提取。稍后，相同的命令可能会显示：
豆荚状态:3.运行/0等待/0成功/0失败的要以机器可读的形式列出属于ReplicationController的所有pod，可以使用如下命令:
豆荚＝$ (Kubectl得到pod，选择器＝应用程序＝nginx,输出＝jsonpath= {. items . . metadata.name｝）回响$pods输出类似如下:
nginx-3ntk0 nginx-4ok8v nginx-qrm3m这里，选择器与ReplicationController的选择器相同(见库贝特尔描述输出），并在replication.yaml．的——输出= jsonpath选项使用返回列表中每个pod的名称指定表达式。
编写ReplicationController Spec
和所有其他Kubernetes配置一样，ReplicationController也需要apiVersion，种类和元数据字段。ReplicationController对象的名称必须是有效的DNS域名．有关使用配置文件的一般信息，请参见对象管理．
复制控制器还需要一个规格部分．
豆荚模板
的.规格模板的唯一必填字段是规格．
的.规格模板是一个豆荚模板．它和a有完全相同的基模豆荚，但它是嵌套的且没有apiVersion或种类．
除了Pod的必填字段外，ReplicationController中的Pod模板还必须指定适当的标签和适当的重新启动策略。对于标签，请确保不与其他控制器重叠。看见豆荚选择器．
只有一个.spec.template.spec.restartPolicy等于总是允许，如果未指定，则为默认值。
对于本地容器重启，ReplicationController将委托给节点上的代理，例如Kubelet或者码头工人。
ReplicationController上的标签
ReplicationController本身可以有标签(.metadata.labels)。通常，您会将这些设置与.spec.template.metadata.labels如果.metadata.labels如果未指定，则默认为.spec.template.metadata.labels．但是，他们可以是不同的，并且.metadata.labels不要影响ReplicationController的行为。
豆荚选择器
的.spec.selector字段是一个标签选择器．ReplicationController使用与选择器匹配的标签管理所有pod。它不区分自己创建或删除的豆荚和另一个人或进程创建或删除的豆荚。这允许在不影响运行pod的情况下更换ReplicationController。
如果指定，则.spec.template.metadata.labels必须等于.spec.selector，否则将被API拒绝。如果.spec.selector，则默认为.spec.template.metadata.labels．
此外，您通常不应直接使用另一个ReplicationController或其他控制器（如Job）创建其标签与此选择器匹配的任何播客。如果您这样做，ReplicationController会认为它创建了其他播客。Kubernetes不会阻止您这样做。
如果最终多个控制器的选择器重叠，则必须自己管理删除操作（请参阅在下面).
多个副本
您可以通过设置.spec.replicas您希望同时运行的pod数量。在任何时候运行的pod数量都可能会更高或更低，例如，复制副本刚刚增加或减少，或者pod正常关闭，并且更换工作提前开始。
如果没有指定.spec.replicas，则默认为1。
使用ReplicationControllers
删除ReplicationController及其pod
如果需要删除一个ReplicationController及其所有pod，请使用kubectl删除. Kubectl将ReplicationController缩放为零，并等待它删除每个pod，然后再删除ReplicationController本身。如果此kubectl命令被中断，则可以重新启动。
当使用REST API或Go客户端库时，您需要显式地执行这些步骤(将副本缩放到0，等待pod删除，然后删除ReplicationController)。
仅删除一个ReplicationController
您可以删除ReplicationController而不影响其任何播客。
使用kubectl，指定--级联=孤立选项kubectl删除．
当使用REST API或Go客户端库时，可以删除ReplicationController对象。
删除原始副本后，您可以创建一个新的ReplicationController来替换它.spec.selector如果相同，那么新的将采用旧的吊舱。然而，它不会做出任何努力使现有的pod与新的、不同的pod模板匹配。要以受控方式将POD更新为新规范，请使用滚动更新．
从ReplicationController中隔离pods
通过更改pod的标签，可以将其从ReplicationController的目标集中移除。这种技术可用于从服务中移除吊舱，以便进行调试和数据恢复。以这种方式删除的pod将被自动替换(假设副本的数量没有改变)。
常见的使用模式
重新安排
如上所述，无论您希望保持运行的pod是1个还是1000个，ReplicationController都将确保存在指定数量的pod，即使在节点故障或pod终止(例如，由于另一个控制代理的操作)的情况下。
缩放比例
ReplicationController支持通过手动或自动伸缩控制代理，通过更新副本字段。
滚动更新
ReplicationController的设计是通过逐个替换pod来实现对服务的滚动更新。
在解释# 1353时，建议使用1个replica创建一个新的ReplicationController，将新(+1)控制器和旧(-1)控制器依次伸缩，当旧控制器的replica数达到0时再删除旧控制器。这可预测地更新豆荚集，而不考虑意外故障。
理想情况下，滚动更新控制器将考虑应用程序就绪情况，并确保在任何给定时间都有足够数量的豆荚有效地提供服务。
这两个ReplicationControllers需要创建至少具有一个区分标签的pod，例如pod的主容器的image标签，因为通常是图像更新激发滚动更新。
多个版本跟踪
除了在进行滚动更新时运行应用程序的多个版本外，通常还会在一段较长的时间内运行多个版本，甚至连续运行多个版本，使用多个版本跟踪。这些曲目将被标签区分开来。
例如，一个服务可能针对所有具有层入（前端），环境入（产品）．现在假设你有10个复制的豆荚组成这一层。但是您希望能够“探测”该组件的新版本。您可以使用副本设置为9的大部分副本，带有标签tier=前端，environment=产品，track=稳定，以及另一个具有副本对于带标签的金丝雀，设置为1层=前端,环境=刺激、跟踪=金丝雀. 现在这项服务覆盖了金丝雀和非金丝雀荚。但是，您可以单独使用ReplicationController进行测试、监视结果等。
使用带服务的ReplicationControllers
多个replicationcontroller可以位于单个服务的后面，因此，例如，一些流量会流向旧版本，一些会流向新版本。
ReplicationController永远不会自行终止，但它的寿命不会像服务那么长。服务可能由多个ReplicationControllers控制的pods组成，在一个服务的生命周期内，可能会创建和销毁多个replicationcontroller(例如，执行运行服务的pods的更新)。两个服务本身和它们的客户端都应该保持对维护服务荚的replicationcontroller的忽略。
编写复制程序
ReplicationController创建的pod是可替换的、语义相同的，尽管随着时间的推移，它们的配置可能会变得异构。这显然适合复制的无状态服务器，但ReplicationControllers也可以用来维护主选、分片和工作池应用程序的可用性。这样的应用程序应该使用动态工作分配机制，例如RabbitMQ工作队列，而不是静态/一次性定制每个pod的配置，后者被认为是一种反模式。执行的任何pod定制，如垂直自动调整资源大小(例如，cpu或内存)，都应该由另一个在线控制器进程执行，与ReplicationController本身类似。
复制控制器的职责
ReplicationController确保所需数量的POD与其标签选择器匹配，并且可以正常工作。目前，只有终止的POD被排除在其计数之外。将来，准备从系统中获得的其他信息也可能被考虑在内，我们可能会对替换策略添加更多的控制，并且我们计划发出事件，外部客户端可以使用这些事件来实现任意复杂的替换和/或缩小策略。
ReplicationController永远只能承担这一狭隘的职责。它本身不会执行就绪性或活动性探测。它不是执行自动缩放，而是由外部自动缩放器控制（如中所述）# 492)，这将改变它的副本字段。我们不会添加调度策略(例如，传播)复制控制器。它也不应该验证控制的POD是否与当前指定的模板匹配，因为这将阻碍自动调整大小和其他自动化过程。类似地，完成期限、排序依赖关系、配置扩展和其他功能也属于其他地方。我们甚至计划考虑批量豆荚的形成机制(# 170).
ReplicationController旨在成为一个可组合的构建块原语。我们希望在it和其他补充原语的基础上构建更高级别的API和/或工具，以方便将来的用户。kubectl（运行、规模）目前支持的“宏”操作就是这方面的概念证明示例。例如，我们可以想象阿斯加德管理replicationcontroller、自动伸缩器、服务、调度策略、金丝雀等。
API对象
复制控制器是Kubernetes REST API中的顶级资源。关于API对象的更多细节可以在下面找到:ReplicationController API对象．
ReplicationController的替代方案
复制集
复制集下一代ReplicationController是否支持新版本基于集合的标签选择器. 它主要用于部署作为协调pod创建、删除和更新的机制。请注意，我们建议使用部署而不是直接使用副本集，除非您需要自定义更新业务流程或根本不需要更新。
部署(推荐)
部署是一个高级API对象，它更新其底层副本集及其pod。如果需要这种滚动更新功能，建议进行部署，因为它们是声明性的、服务器端和其他特性。
光荚
与用户直接创建POD的情况不同，ReplicationController会替换因任何原因（如节点故障或中断性节点维护，如内核升级）而删除或终止的POD。因此，我们建议您使用ReplicationController，即使您的应用程序只需要一个pod。将其与流程主管类似，只是它跨多个节点管理多个POD，而不是单个节点上的单个流程。ReplicationController将本地容器重启委托给节点上的某个代理（例如Kubelet或Docker）。
工作
使用工作而不是针对预期自行终止的POD（即批处理作业）的ReplicationController。
DaemonSet
使用DaemonSet而不是用于提供机器级功能（如机器监控或机器日志记录）的POD的ReplicationController。这些pod的使用寿命与机器的使用寿命相关：pod需要在其他pod启动之前在机器上运行，并且在机器准备重新启动/关闭时可以安全终止。