写在前面
云原生浪潮浩浩荡荡不可阻挡，业务上云也是企业的必经之路。但上云从来都不是一片坦途，在此过程中我们总会遇到一些困难和挑战。得益于云原生技术的日益成熟，这些问题一定会有相应的解法。
概念引入
前⾯我们学习了 Pod 的⼀些基本使⽤⽅法，⽽且前⾯我们都是直接来操作的 Pod ，假如我们现在有⼀个 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，这样是不是也远⽐我们⼿动去启动、⼿动去关闭要好得多。
现在我们来使⽤ 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 的滚动升级功能（但是不⽀持⼀键回滚，需要⽤相同的⽅法去修改镜像地址）
