Replication Controller、Replica Set

假如我们现在有一个Pod正在提供线上的服务，我们来想想一下我们可能会遇到的一些场景：

• 某次运营活动非常成功，网站访问量突然暴增
• 运行当前Pod的节点发生故障了，Pod不能正常提供服务了

第一种情况，可能比较好应对，一般活动之前我们会大概计算下会有多大的访问量，提前多启动几个Pod，活动结束后再把多余的Pod杀掉，虽然有点麻烦，但是应该还是能够应对这种情况的。

第二种情况，可能某天夜里收到大量报警说服务挂了，然后起来打开电脑在另外的节点上重新启动一个新的Pod，问题也很好的解决了。

如果我们都人工的去解决遇到的这些问题，似乎又回到了以前刀耕火种的时代了是吧，如果有一种工具能够来帮助我们管理Pod就好了，Pod不够了自动帮我新增一个，Pod挂了自动帮我在合适的节点上重新启动一个Pod，这样是不是遇到上面的问题我们都不需要手动去解决了。

幸运的是，Kubernetes就为我们提供了这样的资源对象：

• Replication Controller：用来部署、升级Pod
• Replica Set：下一代的Replication Controller
• Deployment：可以更加方便的管理Pod和Replica Set

Replication Controller（RC）

Replication Controller简称RC，RC是Kubernetes系统中的核心概念之一，简单来说，RC可以保证在任意时间运行Pod的副本数量，能够保证Pod总是可用的。如果实际Pod数量比指定的多那就结束掉多余的，如果实际数量比指定的少就新启动一些Pod，当Pod失败、被删除或者挂掉后，RC都会去自动创建新的Pod来保证副本数量，所以即使只有一个Pod，我们也应该使用RC来管理我们的Pod。

我们想想如果现在我们遇到上面的问题的话，可能除了第一个不能做到完全自动化，其余的我们是不是都不用担心了，运行Pod的节点挂了，RC检测到Pod失败了，就会去合适的节点重新启动一个Pod就行，不需要我们手动去新建一个Pod了。如果是第一种情况的话在活动开始之前我们给Pod指定10个副本，结束后将副本数量改成2，这样是不是也远比我们手动去启动、手动去关闭要好得多，而且我们后面还会给大家介绍另外一种资源对象HPA可以根据资源的使用情况来进行自动扩缩容，这样以后遇到这种情况，我们就真的可以安心的去睡觉了。

现在我们来使用RC来管理我们前面使用的Nginx的Pod，YAML文件如下：

apiVersion: v1
kind: ReplicationController
metadata:
  name: rc-demo
  labels:
    name: rc
spec:
  replicas: 3
  selector:
    name: rc
  template:
    metadata:
     labels:
       name: rc
    spec:
     containers:
     - name: nginx-demo
       image: nginx
       ports:
       - containerPort: 80

上面的YAML文件相对于我们之前的Pod的格式：

• kind：ReplicationController
• spec.replicas: 指定Pod副本数量，默认为1
• spec.selector: RC通过该属性来筛选要控制的Pod
• spec.template: 这里就是我们之前的Pod的定义的模块，但是不需要apiVersion和kind了
• spec.template.metadata.labels: 注意这里的Pod的labels要和spec.selector相同，这样RC就可以来控制当前这个Pod了。

这个YAML文件中的意思就是定义了一个RC资源对象，它的名字叫rc-demo，保证一直会有3个Pod运行，Pod的镜像是nginx镜像。

注意spec.selector和spec.template.metadata.labels这两个字段必须相同，否则会创建失败的，当然我们也可以不写spec.selector，这样就默认与Pod模板中的metadata.labels相同了。所以为了避免不必要的错误的话，不写为好。

然后我们来创建上面的RC对象(保存为 rc-demo.yaml):
$ kubectl create -f rc-demo.yaml

查看RC：

$ kubectl get rc

查看具体信息：
$ kubectl describe rc rc-demo

然后我们通过RC来修改下Pod的副本数量为2：
$ kubectl apply -f rc-demo.yaml

或者
$ kubectl edit rc rc-demo

而且我们还可以用RC来进行滚动升级，比如我们将镜像地址更改为nginx:1.7.9:
$ kubectl rolling-update rc-demo --image=nginx:1.7.9

但是如果我们的Pod中多个容器的话，就需要通过修改YAML文件来进行修改了:
$ kubectl rolling-update rc-demo -f rc-demo.yaml

如果升级完成后出现了新的问题，想要一键回滚到上一个版本的话，使用RC只能用同样的方法把镜像地址替换成之前的，然后重新滚动升级。

Replication Set（RS）

Replication Set简称RS，随着Kubernetes的高速发展，官方已经推荐我们使用RS和Deployment来代替RC了，实际上RS和RC的功能基本一致，目前唯一的一个区别就是RC只支持基于等式的selector（env=dev或environment!=qa），但RS还支持基于集合的selector（version in (v1.0, v2.0)），这对复杂的运维管理就非常方便了。

kubectl命令行工具中关于RC的大部分命令同样适用于我们的RS资源对象。不过我们也很少会去单独使用RS，它主要被Deployment这个更加高层的资源对象使用，除非用户需要自定义升级功能或根本不需要升级Pod，在一般情况下，我们推荐使用Deployment而不直接使用Replica Set。

最后我们总结下关于RC/RS的一些特性和作用吧：

• 大部分情况下，我们可以通过定义一个RC实现的Pod的创建和副本数量的控制
• RC中包含一个完整的Pod定义模块（不包含apiversion和kind）
• RC是通过label selector机制来实现对Pod副本的控制的
• 通过改变RC里面的Pod副本数量，可以实现Pod的扩缩容功能
• 通过改变RC里面的Pod模板中镜像版本，可以实现Pod的滚动升级功能（但是不支持一键回滚，需要用相同的方法去修改镜像地址）