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的滚动升级功能（但是不支持一键回滚，需要用相同的方法去修改镜像地址）

好，这节课我们就给大家介绍了使用RC或者RS来管理我们的Pod，我们下节课来给大家介绍另外一种更加高级也是现在推荐使用的一个资源对象Deployment。