【云原生】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
运行Nginx
Pod,一共会创建出三个副本,分别分配到Node
节点上
[root@master ~]# cat rc-nginx.yaml
# 指定使用Kubernetes API的版本
apiVersion: "v1"
# 定义资源类型为RC
kind: ReplicationController
# 定义Pod的元数据
metadata:
# Pod名字为nginx
name: nginx
# 定义Pod的规格
spec:
# 期望Pod的副本数量,这次为3
replicas: 3
# 标签选择器:用于定义选择哪些现有Pod应该被这个RC管理
selector:
app: nginx
# 定义了创建Pod的模板,也可以理解为容器模板,这个模板将用于创建新的Pod副本
template:
metadata:
name: nginx
# 定义容器模板,可以理解为,如果是使用这个模板创建出的Pod副本会自动打上一个标签为app=nginx
labels:
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=nginx
Containers:
nginx:
Image: nginx
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 11m replication-controller Created pod: nginx-8jzh2
Normal SuccessfulCreate 11m replication-controller Created pod: nginx-gfksd
Normal 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: 3
selector:
app: nginx
template:
metadata:
name: nginx
labels:
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: 10
selector:
app: nginx
template:
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- 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
原文地址:https://blog.csdn.net/weixin_73059729/article/details/140662393
免责声明:本站文章内容转载自网络资源,如本站内容侵犯了原著者的合法权益,可联系本站删除。更多内容请关注自学内容网(zxcms.com)!