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

本文转自开源中国- kubernetes资源--RC和RS