本文主要是介绍OpenShift 弹性伸缩 Replication Controller，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
RC（Replication Controller），复制控制器，其是Kubernetes的一个组件，主要是负责监控 容器 数量，当发现 容器 数量少于部署定义数量时，出发新的部署请求。
在OpenShift中，每个应用的Deployment Config 中都定义了部署 容器 数量（Replicas），当OpenShift在进行部署的时候同时会启动一个Replication Controller，并将Deployment Config中定义的 容器 部署数量（Replicas）传递给相关联的Replication Controller。
RC又是通过什么来判断某个容器需要被其进行监控的呢？
RC Config配置：
| spec: replicas: 1 selector: app: app-cli deployment: app-cli-1 deploymentconfig: app-cli |
Pod Config 配置：
| labels: app: app-cli deployment: app-cli-1 deploymentconfig: app-cli |
从上面的RC Config中部分配置可以看到：
- replicas：RC监控的应用需要部署的容器个数；
- selector：RC选择标签列表，只有同时满足所列标签的容器才会被此RC进行监控，上面的配置文件中，只有某个容器的labels同时满足 app:app-cli、deployment:app-cli-1、deploymentconfig:app-cli ，这三个标签的，才会被此RC进行监控。
测试：
1、打开某个 容器 的配置修改，将其中的deployment:app-cli-1的标签删除，然后保存，如下图：
2、立即找到Pods页面，如下图：
从图上可以看到，被修改的app-cli-1-xhbws的pod还在正在运行，由于测试时将app-cli-1-xhbws的deployment:app-cli-1的标签删除了，导致app-cli的RC找不到一个正常运行的 容器 ，此时RC就重新启动了一个名称为app-cli-1-gz26z的pod。
3、如果现在原来的app-cli-1-xhbws中删除的配置项，再添加来回，就会立即发现刚刚启动的 app-cli-1-gz26z 的pod被kill了，并且在Pods里面中已经查询不到了。
上面测试的过程，正好是对RC弹性伸缩功能的最好验证。
再次测试：
1、重新恢复上面的第二步的情况，此时，分别在app-cli应用的下面添加一个文件分别如下：
旧的 容器 ：
新的 容器 ：
2、此时通过如下shell脚本访问这个应用：
| [root@ocp ~]# for i in {1..10} ; do curl http://app-cli-default.apps.192.168.40.141.nip.io/test.php ; done app-cli-1-xhbws app-cli-p4b65 app-cli-1-xhbws app-cli-p4b65 app-cli-1-xhbws app-cli-p4b65 app-cli-1-xhbws app-cli-p4b65 app-cli-1-xhbws app-cli-p4b65 [root@ocp ~]# |
从上图可以看出，已经不受RC控制的 容器 还是能够接收到Service服务转发过来的请求。
此问题的原因也和上面所说的 标签与选择器 在关系，可以通过如下命令查看 app-cli 应用的选择器：
| [root@ocp ~]# oc describe svc app-cli | grep Selector Selector: app=app-cli,deploymentconfig=app-cli |
总结：
1、RC服务在监控容器的时候，使用的是 app 、deployment 和 deploymentconfig 这三个标签。
2、Service服务在选择容器进行请求转发的时候，使用的只是 app 和 deploymentconfig 这两个标签。
相关命令
1、oc scale dc <dc名称> --replicas=2：进行pod的增加或减少。
这篇关于OpenShift 弹性伸缩 Replication Controller的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
