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

常见的使用模式

Rescheduling（重新规划）

正如我们之前提到的，无论你是有1个或者有1000个pod需要运行，Replication Controller 会确保该数量的pod在运行，甚至在节点（node）失败或者节点（node）终止的情况下

Scaling（缩放）

Replication Controller让我们更容易的控制pod的副本的数量，不管我们是手动控制还是通过其它的自动管理的工具，最简单的：修改replicas的值

Rolling updates（动态更新）

Replication Controller 可以支持动态更新，当我们更新一个服务的时候，它可以允许我们一个一个的替换pod

正如我们在#1353中解释的，推荐的方法是创建一个新的只有1个pod副本的Replication Controller,然后新的每次+1，旧的每次-1，直到旧的Replication Controller 的值变成0，然后我们就可以删除旧的了，这样就可以规避省级过程中出现的未知错误了

理论上，动态更新控制器应考虑应用的可用性，并确保足够的pod制成服务在任何时间都能正常提供服务

两个 Replication Controller创建的pod至少要由一个不同的标签，可以是镜像的标签，因为一般镜像的更新都会带来一个新的更新

kubectl是实现动态更新的客户端

Multiple release tracks多个发布版本追踪
除了在程序更新过程中同时运行多个版本的程序外，在更新完成之后的一段时间内或者持续的同时运行多个版本（新旧），通过多国版本的追踪（版本的追踪是通过label来实现的）

举个例子来说：一个服务可能绑定的Pod为tier in (frontend), environment in (prod)，现在我们旧假设我们由10个副本来组成这个tier,现在我们要发布一个新的版本canary，这个时候，我们就应该设置一个Replication Controller，并且设置replcas的值为9，并且标签为tier=frontend, environment=prod, track=stable，然后再设置另外一个Replication Controller，并且把replacas的值设置为1标签为：tier=frontend, environment=prod, track=canary.现在这个服务就同时使用了新版和旧版两个版本了，这个时候我们旧可以通过不同的Replication Controller进行一些测试，监控…