Replication Controller（RC）

应用托管在K8S后，K8S需要保证应用能够持续运行，这是RC的工作内容。

主要功能

确保pod数量：RC用来管理正常运行Pod数量，一个RC可以由一个或多个Pod组成，在RC被创建后，系统会 根据定义好的副本数来创建Pod数量。在运行过程中，如果Pod数量小于定义的，就会重启停止的或重新分配Pod，反之则杀死多余的。

确保pod健康：当pod不健康，运行出错或者无法提供服务时，RC也会杀死不健康的pod，重新创建新的。

弹性伸缩 ：在业务高峰或者低峰期的时候，可以通过RC动态的调整pod的数量来提高资源的利用率。同时，配置相应的监控功能（Hroizontal Pod Autoscaler），会定时自动从监控平台获取RC关联pod的整体资源使用情况，做到自动伸缩。

滚动升级：滚动升级为一种平滑的升级方式，通过逐步替换的策略，保证整体系统的稳定，在初始化升级的时候就可以及时发现和解决问题，避免问题不断扩大。

弹性伸缩

弹性伸缩是指适应负载变化，以弹性可伸缩的方式提供资源。反映到K8S中，指的是可根据负载的高低动态调整Pod的副本数量。调整Pod的副本数是通过修改RC中Pod的副本是来实现的，示例命令如下：

扩容Pod的副本数目到10 kubectl scale relicationcontroller lykops --replicas=10

缩容Pod的副本数目到1 kubectl scale relicationcontroller lykops --replicas=1

滚动升级

滚动升级是一种平滑过渡的升级方式，通过逐步替换的策略，保证整体系统的稳定，在初始升级的时候就可以及时发现、调整问题，以保证问题影响度不会扩大。

升级方式

使用配置文件升级

kubecl rolling-update lykops-rc-v1 -f lykops-rc.yaml --update-period=10s

直接使用images

kubectl rolling-update lykops-rc --image=webapache:v3 

升级过程

升级开始后，首先依据提供的定义文件创建v2版本的RC，然后每隔10s（--update-period=10s）逐步的增加v2版本的Pod副本数，逐步减少v1版本Pod的副本数。升级完成之后，删除v1版本的RC，保留v2版本的RC，及实现滚动升级。

升级回滚

升级过程中，发生了错误中途退出时，可以选择继续升级。K8S能够智能的判断升级中断之前的状态，然后紧接着继续执行升级。当然，也可以进行回退，命令如下：

kubectl rolling-update lykops-v1 -f lykops-v2-rc.yaml --update-period=10s -–rollback 

yaml文件例子

升级之前的yaml文件为

apiVersion: v1 kind: ReplicationController metadata:
 name: lykops-rc
 labels:
 app: apache
 version: v1
spec:
 replicas: 5
 selector:
 app: apache
 version: v1
 template:
 metadata:
 labels:
 app: apache
 version: v1
 spec:
 containers:
 - name: apache-rc
 image: web:apache
 command: [ "sh", "/etc/run.sh" ]
 ports:
 - containerPort: 80
 name: http
 protocol: TCP

升级用的yaml文件内容为

apiVersion: v1 kind: ReplicationController metadata:
 name: test-rc-v2
 labels:
 app: apache
 version: v1
spec:
 replicas: 5
 selector:
 app: apache
 version: v2
 template:
 metadata:
 labels:
 app: apache
 version: v2
 spec:
 containers:
 - name: apache-rc-v2
 image: web:apache
 command: [ "sh", "/etc/run.sh" ]
 ports:
 - containerPort: 80
 name: http
 protocol: TCP 

注意事项

要求新的RC需要使用旧的RC的Namespace。

RC的名字（name）不能与旧的RC的名字相同；

在selector中应至少有一个Label与旧的RC的Label不同，以标识其为新的RC。

metadata与之前相同，否则升级后service无法对应上。

replica set（RS）

被认为 是“升级版”的RC。RS也是用于保证与label selector匹配的pod数量维持在期望状态。

区别在于，

1、RC只支持基于等式的selector（env=dev或environment!=qa），但RS还支持新的，基于集合的selector（version in (v1.0, v2.0)或env notin (dev, qa)），这对复杂的运维管理很方便。

2、升级方式
 RS不能使用kubectlrolling-update进行升级
 kubectl rolling-update专用于rc
 RS升级使用deployment或者kubectl replace命令

社区引入这一API的初衷是用于取代vl中的RC，也就是说当v1版本被废弃时，RC就完成了它的历史使命，而由RS来接管其工作。

yaml文件例子

apiVersion: extensions/v1beta1 kind: ReplicaSet metadata:
 name: lykops-rs
 labels:
 software: apache
 project: lykops
 app: lykops-rs
 version: v1
spec:
 replicas: 2
 selector:
 matchLabels:
 name: lykops-rs
 software: apache
 project: lykops
 app: lykops-rs
 version: v1
 template:
 metadata:
 labels:
 name: lykops-rs
 software: apache
 project: lykops
 app: lykops-rs
 version: v1
 spec:
 containers:
 - name: lykops-rs
 image: web:apache
 command: [ "sh", "/etc/run.sh" ]
 ports:
 - containerPort: 80
 name: http
 proto