【云原生】ReplicationController控制器详解

ReplicationController

说明

• 现在推荐使用ReplicaSet和Deployment控制器来管理副本管理机制。

一、ReplicationControllere介绍

• ReplicationController确保在任何时候都有特定数量的Pod副本处于运行状态。换句话说，ReplicationController确保一个Pod或一组同类的Pod总是可用的。

二、ReplicationController如何工作

• 当Pod数量过多时，ReplicationController会终止多余的Pod。当Pod数量太少时，ReplicationController将会启动新的Pod。与手动创建的Pod不同，由ReplicationController创建的Pod在失败、被删除或被终止时会被自动替换。例如，在中断性维护（如内核升级）之后，你的Pod会在节点上重新创建。因此，即使你的应用程序只需要一个POd，你也应该使用ReplicationController创建Pod。ReplicationController类似于进程管理器，但是ReplicationController不是监控单个节点上的单个进程，而是监控多个节点的多个Pod。

• 在讨论中，ReplicationController通常缩写为rc，并作为kubectl命令的快捷方式（意思就是如果使用kubectl可以把ReplicationConroller简写为rc）

• 一个简单的示例是创建一个ReplicationController对象来可靠地无限期地运行Pod的一个实例。更复杂的用例是运行一个多副本服务（如Web服务器）的若干相同副本。

三、运行一个ReplicationController

• 这个示例ReplicationController运行NginxPod，一共会创建出三个副本，分别分配到Node节点上

[root@master ~]# cat rc-nginx.yaml 
# 指定使用Kubernetes API的版本
apiVersion: "v1"
# 定义资源类型为RC
kind: ReplicationController
# 定义Pod的元数据
metadata:
# Pod名字为nginxname: nginx
# 定义Pod的规格
spec:
# 期望Pod的副本数量，这次为3replicas: 3
# 标签选择器：用于定义选择哪些现有Pod应该被这个RC管理selector:app: nginx
# 定义了创建Pod的模板，也可以理解为容器模板，这个模板将用于创建新的Pod副本template:metadata:name: nginx
# 定义容器模板，可以理解为，如果是使用这个模板创建出的Pod副本会自动打上一个标签为app=nginxlabels:app: nginx
# 定义容器规格spec:# 定义Pod中要运行的容器列表，这个例子中有多个containers:# 定义容器名称- name: nginx# 定义容器使用的镜像image: nginx# 定义容器内部监听的端口列表ports:- containerPort: 80

• 通过以下命令运行示例任务

[root@master ~]# kubectl apply -f rc-nginx.yaml

• 输出类似于

replicationcontroller/nginx created

• 使用以下命令查看ReplicationController的状态：

# 方法一
[root@master ~]# kubectl describe replicationcontroller nginx# 方法二
[root@master ~]# kubectl describe rc nginx

• 输出类似于

Name:         nginx
Namespace:    default
Selector:     app=nginx
Labels:       app=nginx
Annotations:  <none>
Replicas:     3 current / 3 desired
Pods Status:  2 Running / 1 Waiting / 0 Succeeded / 0 Failed
Pod Template:Labels:  app=nginxContainers:nginx:Image:        nginxPort:         80/TCPHost Port:    0/TCPEnvironment:  <none>Mounts:       <none>Volumes:        <none>
Events:Type    Reason            Age   From                    Message----    ------            ----  ----                    -------Normal  SuccessfulCreate  11m   replication-controller  Created pod: nginx-8jzh2Normal  SuccessfulCreate  11m   replication-controller  Created pod: nginx-gfksdNormal  SuccessfulCreate  11m   replication-controller  Created pod: nginx-ll8lh

• 查看Pod运行状态

[root@master ~]# kubectl get pod 
NAME          READY   STATUS    RESTARTS   AGE
nginx-792pv   1/1     Running   0          90s
nginx-8jzh2   1/1     Running   0          19m
nginx-ll8lh   1/1     Running   0          19m

四、编写一个ReplicationController清单注意事项

• 与所有其他Kubernetes配置一样，ReplicationController需要apiVersion、Kind和metadata字段
• 当控制平面为ReplicationController创建新的Pod时，ReplicationController的.metadata.name是命名这些Pod的部分基础。ReplicationController的名称必须是一个合法的DNS子域值，但这可能对Pod的主机名产生意外的结果。为获得最佳兼容性，名称应遵循更严格的DNS标签规则。

4.1、Pod模板

• .spec.template是.spec的唯一必须字段。

• .spec.template是一个Pod模板。它的模式与Pod完全相同，只是它是嵌套的，没有apiVersion或Kind属性。

• 除了Pod所需的字段外，ReplicationController中的Pod模板必须指定适当的标签和适当的重启策略。对于标签，请确保不与其他控制器重叠。

• 只允许.spec.template.spec.restartPolicy等于Always，如果没有指定Pod的重启策略默认使用Always

4.2、ReplicationController上的标签

• ReplicationController本身可以有标签（.metadata.labels）。通常，你可以将这些设置为.spec.template.metadata.lables；如果没有指定.metadata.labels那么它默认为.spec.template.metadata.lable。但是Kubernetes允许他们不同的，.metadata.labels不会影响ReplicationController的行为。

4.3、Pod选择算符

• .spec.selector字段是一个标签选择器。ReplicationController管理标签与标签选择器匹配的Pod（意思：如果定义的标签选择器为.spec.selector.app:nginx那么就意味着这个控制器将会管理带有标签为app=nginx的Pod）。它不区分它创建或删除的Pod和其他人或进程创建或删除的Pod。这允许在不影响正在运行的Pod的情况下替换ReplicationController。

• 如果指定了.spec.template.metadata.lables，它必须和.spec.selector相同，否则它将被API拒绝。如果没有指定.spec.selector,它将默认为.spec.template.metadata.labels。

spec:replicas: 3selector:app: nginxtemplate:metadata:name: nginxlabels:app: ginx

• 模板的标签和标签选择器不同的话，将会报错如下内容

[root@master ~]# kubectl apply -f rc-nginx.yaml 
The ReplicationController "nginx" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"app":"ginx"}: `selector` does not match template `labels`

• 另外，通常不应该直接使用另一个ReplicationController或另一个控制器（例如Job）来创建其标签与该选择算符匹配的任何Pod。如果这样做，ReplicationScontroller会认为它创建了这些Pod。Kubernetes并没有阻止你这样做。

4.4、多个Pod副本

• 你可以通过设置.spec.replicas来指定应该同时运行多个Pod。在任何时候，处于运行状态的Pod个数可能高于或者低于设定值。例如，副本个数刚刚被增加或减少时，或者一个Pod处于优雅终止过程中而其替代副本已经提前开始创建时。
• 如果你没有指定.spec.replicas，那么它默认是1也就是默认运行一个Pod

# 将replicas设置为10也就意味着将会运行10个Pod副本，
[root@master ~]# cat rc-nginx.yaml 
apiVersion: "v1"
kind: ReplicationController
metadata:name: nginx
spec:replicas: 10selector:app: nginxtemplate:metadata:name: nginxlabels:app: nginxspec:containers:- name: nginximage: nginxports:- containerPort: 80

• 通过以下命令运行示例任务

[root@master ~]# kubectl apply -f rc-nginx.yaml

• 查看ReplicationController个数
• 仔细观察以下Pod的数量，和状态一栏，可得知，Pod的状态不止Running，如果状态为ContainerCreating表示Pod正在创建中。

[root@master ~]# kubectl get pod 
NAME          READY   STATUS              RESTARTS   AGE
nginx-2pjqd   1/1     Running             0          39s
nginx-689qk   1/1     Running             0          39s
nginx-792pv   1/1     Running             0          30m
nginx-8jzh2   1/1     Running             0          47m
nginx-fz5ln   1/1     Running             0          39s
nginx-ll8lh   1/1     Running             0          47m
nginx-lpztd   0/1     ContainerCreating   0          39s
nginx-q4hdn   1/1     Running             0          39s
nginx-qmzsw   0/1     ContainerCreating   0          39s
nginx-zctgv   0/1     ContainerCreating   0          39s

• 等待一小会再次查看Pod个数

[root@master ~]# kubectl get pod 
NAME          READY   STATUS    RESTARTS   AGE
nginx-2pjqd   1/1     Running   0          2m2s
nginx-689qk   1/1     Running   0          2m2s
nginx-792pv   1/1     Running   0          31m
nginx-8jzh2   1/1     Running   0          49m
nginx-fz5ln   1/1     Running   0          2m2s
nginx-ll8lh   1/1     Running   0          49m
nginx-lpztd   1/1     Running   0          2m2s
nginx-q4hdn   1/1     Running   0          2m2s
nginx-qmzsw   1/1     Running   0          2m2s
nginx-zctgv   1/1     Running   0          2m2s

4.5、删除Pod

• 使用资源清单运行的Pod使用kubectl delete pod <Pod名字>是不会完全删除的，因为ReplicationController有个特性就是它会一直维持指定Pod的状态数量

• 为了更好的理解现在进行相关测试

• 使用kubectl delete命令删除Pod查看效果

• 先查看Pod的数量

[root@master ~]# kubectl get pod 
NAME          READY   STATUS    RESTARTS   AGE
nginx-2pjqd   1/1     Running   0          5m35s
nginx-689qk   1/1     Running   0          5m35s
nginx-792pv   1/1     Running   0          34m
nginx-8jzh2   1/1     Running   0          52m
nginx-fz5ln   1/1     Running   0          5m35s
nginx-ll8lh   1/1     Running   0          52m
nginx-lpztd   1/1     Running   0          5m35s
nginx-q4hdn   1/1     Running   0          5m35s
nginx-qmzsw   1/1     Running   0          5m35s
nginx-zctgv   1/1     Running   0          5m35s

• 使用kubectl delete命令删除一个Pod查看效果

[root@master ~]# kubectl delete pod nginx-2pjqd
pod "nginx-2pjqd" deleted

• 再次查看Pod的数量，依旧还是运行了10个Pod副本

[root@master ~]# kubectl get rc
NAME    DESIRED   CURRENT   READY   AGE
nginx   10        10        10      3m58s

• 如果想彻底删除所有资源清单部署的Pod副本，请使用以下命令
• 请小心使用以下命令，因为它将会把这个资源清单中的内容全部删除

[root@master ~]# kubectl delete -f rc-nginx.yaml

• 再次查看Pod，将查看不到任何内容

[root@master ~]# kubectl get pod 
No resources found in default namespace.

• 再次部署Pod，后面会再次用到

[root@master ~]# kubectl apply -f rc-nginx.yaml

4.6、只删除ReplicationController

• 你可以删除一个ReplicationController而不影响它的任何Pod。
• 使用kubectl，为kubectl delete指定--cascade=orphan选项。
• 当使用REST API或客户端库时，只需删除ReplicationController来替换它。只要新的和旧的.spec.selector相同，那么新的控制器将领养旧的Pod。但是，它不会做出任何努力使现有的Pod匹配新的、不同的Pod模板。如果希望以受控制方式更新Pod以使用新的spec，请执行滚动更新操作。

演示

• 你需要提前apply一个资源清单，并查看Pod

[root@master ~]# kubectl get pod 
NAME          READY   STATUS    RESTARTS   AGE
nginx-68zl5   1/1     Running   0          4m48s
nginx-7m4dz   1/1     Running   0          4m48s
nginx-bnzpt   1/1     Running   0          4m48s
nginx-f2ptt   1/1     Running   0          4m48s
nginx-n8ndg   1/1     Running   0          4m48s
nginx-p94qb   1/1     Running   0          4m48s
nginx-pgxvn   1/1     Running   0          4m48s
nginx-t5xhs   1/1     Running   0          4m48s
nginx-wr67c   1/1     Running   0          4m48s
nginx-xszcf   1/1     Running   0          4m48s

• 不加--cascade=orphan删除RC资源对象

[root@master ~]# kubectl delete rc nginx

• 再次查看Pod，可以看到Pod一个也不存在了，

[root@master ~]# kubectl get pod
No resources found in default namespace.

• 使用--cascade=orphan删除RC，在此之前你需要apply一个RC的资源清单

[root@master ~]# kubectl delete rc nginx --cascade=orphan

• 查看Pod是否跟随着RC被一起删除
• 通过下面的命令回显可知，当加了--cascade=orphan参数时，创建资源对象并不会删除对象对象的数据比如Pod

[root@master ~]# kubectl get pod
NAME          READY   STATUS    RESTARTS   AGE
nginx-2t8zx   1/1     Running   0          103s
nginx-66ssk   1/1     Running   0          103s
nginx-92mvt   1/1     Running   0          103s
nginx-9m6zz   1/1     Running   0          103s
nginx-9zgbd   1/1     Running   0          103s
nginx-b4d65   1/1     Running   0          103s
nginx-dfktn   1/1     Running   0          103s
nginx-gxcgj   1/1     Running   0          103s
nginx-j74xn   1/1     Running   0          103s
nginx-vcfjq   1/1     Running   0          103s