kubernetes资源--RC和RS
Replication Controller（RC）
RC是K8S中的另一个核心概念，应用托管在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 scalerelicationcontroller yourRcName --replicas=10
缩容Pod的副本数目到1
kubectl scalerelicationcontroller yourRcName --replicas=1
滚动升级
滚动升级是一种平滑过渡的升级方式，通过逐步替换的策略，保证整体系统的稳定，在初始升级的时候就可以及时发现、调整问题，以保证问题影响度不会扩大。
升级方式
使用配置文件升级
kubectlrolling-update test-rc-v1 -f test-rc.yaml --update-period=10s
直接使用images
kubectlrolling-update test-rc --image=webapache:v3
升级过程
升级开始后，首先依据提供的定义文件创建v2版本的RC，然后每隔10s（--update-period=10s）逐步的增加v2版本的Pod副本数，逐步减少v1版本Pod的副本数。升级完成之后，删除v1版本的RC，保留v2版本的RC，及实现滚动升级。
升级回滚
升级过程中，发生了错误中途退出时，可以选择继续升级。K8S能够智能的判断升级中断之前的状态，然后紧接着继续执行升级。当然，也可以进行回退，命令如下：
kubectlrolling-update my-rcName-v1 -f my-rcName-v2-rc.yaml --update-period=10s–rollback
yaml文件例子
升级之前的yaml文件为
apiVersion: v1
kind: ReplicationController
metadata:
name: test-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: 50
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: test-rs
labels:
software: apache
project: test
app: test-rs
version: v1
spec:
replicas: 2
selector:
matchLabels:
name: test-rs
software: apache
project: test
app: test-rs
version: v1
template:
metadata:
labels:
name: test-rs
software: apache
project: test
app: test-rs
version: v1
spec:
containers:
- name: test-rs
image: web:apache
command: [ "sh", "/etc/run.sh" ]
ports:
- containerPort: 80
name: http
protocol: TCP
