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的增加或减少。