原文地址：http://kubernetes.io/v1.0/docs/user-guide/replication-controller.html

Labels
由Replication Controller监控的Pod的数量是是由一个叫 label selector（标签选择器）决定的，label selector在Replication Controller和被控制的pod创建了一个松散耦合的关系,与pod相比，pod与他们的定义文件关系紧密。我们故意的不使用固定长度的数组来存储被管理的pod,因为根据我们的经验，如果那样作了，会增加管理的复杂度，不论是系统还是客户

replication controller 需要确认那些从特定模版创建出来的pod拥有label selector所要求的标签，尽管，它还没有这么作，我们需要通过确认replication controllers的label selectors 没有覆盖设置来确定仅有一个Replication Controller控制所指定的Pod（这段话有点怪）

记住这个：replication controller自己也可以由标签，would generally carry the labels their corresponding pods have in common，但是这些标签并不影响replication controller的行为

Pod会被replication controller删除，如果修改那些pod的标签，这个功能可能会被应用在从服务中删除pod来作测试，数据恢复等。Pod如果是以这种方式被删除的话，那么那个pod会被自动的替换（前提是宗的副本数量未修改）

类似的，删除一个replication controller不会影响它创建的pod,如果向删除那些它那些控制的pod，需要首先拔replcas的值设置为0（注意，用户端工具kubectl 提供了一个命令stop,来删除replication controller以及它控制的pod,但是，这个功能在现在的api中不存在）

Responsibilities of the replication controller（replication controller的责任）

replication controller的任务就是保证预计数量的pod并并保证其可用性，目前，只有那些被终止的Pod是从总数量中排除的，在将来，可读性以及其它系统信息可能会被纳入统计，我们肯能会增加更多的替代策略，并且我们计划可以执行其它外部程序可以使使用并实现复杂的替换或者策略

replication controller的任务永远都只会是单一的。它自身不会进行是否可读和是否可用的检测，相比与自动进行缩放和放大，replication controller更倾向与使用外部的自动平衡工具，这些外部工具要作的仅仅是修改replicas的值来实现Pod数量的变化，我们不会增加replication controller的调度策率，也不会让replication controller来验证受控的Pod是否符合特定的模版，因为这些都会阻碍自动调整和其它的自动的进程。类似的，完成时限，需求依赖，配置扩展，等等都属于其它的部分。

replication controller的目的是成为一个原始的积木，我们希望在replication controller上层的api或者工具来为用户提供方便，现在kubectl支持的宏观操作比如run,stop,scale,rolling-update就是这个概念的例子，举例来说，我们可以想象和“天庭”管理着replication controller，auto-scalers, services, scheduling policies, canaries, 等等