ReplicaSet
ReplicaSet

目录
[toc]
1、ReplicaSet

假如我们现在有一个 Pod 正在提供线上的服务,我们来想想一下我们可能会遇到的一些场景:
某次运营活动非常成功,网站访问量突然暴增
运行当前 Pod 的节点发生故障了,Pod 不能正常提供服务了
第一种情况,可能比较好应对,活动之前我们可以大概计算下会有多大的访问量,提前多启动几个 Pod 副本,活动结束后再把多余的 Pod 杀掉,虽然有点麻烦,但是还是能够应对这种情况的。
第二种情况,可能某天夜里收到大量报警说服务挂了,然后起来打开电脑在另外的节点上重新启动一个新的 Pod,问题可以解决。
但是如果我们都人工的去解决遇到的这些问题,似乎又回到了以前刀耕火种的时代了是吧?如果有一种工具能够来帮助我们自动管理 Pod 就好了,Pod 挂了自动帮我在合适的节点上重新启动一个 Pod,这样是不是遇到上面的问题我们都不需要手动去解决了。
而 ReplicaSet 这种资源对象就可以来帮助我们实现这个功能,**ReplicaSet(RS)** 的主要作用就是维持一组 Pod 副本的运行,保证一定数量的 Pod 在集群中正常运行,ReplicaSet 控制器会持续监听它所控制的这些 Pod 的运行状态,在 Pod 发送故障数量减少或者增加时会触发调谐过程,始终保持副本数量一致。
💘 实战:ReplicaSet测试-2022.12.14(成功测试)
- 实验环境
11、win10,vmwrokstation虚机;
22、k8s集群:3台centos7.6 1810虚机,2个master节点,1个node节点
3 k8s version:v1.20
4 CONTAINER-RUNTIME:containerd:v1.6.10
实验软件(无)
编写资源清单
和 Pod 一样我们仍然还是通过 YAML 文件来描述我们的 ReplicaSet 资源对象,如下 YAML 文件是一个常见的 ReplicaSet 定义:
1# nginx-rs.yaml
2apiVersion: apps/v1
3kind: ReplicaSet
4metadata:
5 name: nginx-rs
6 namespace: default
7spec:
8 replicas: 3 # 期望的 Pod 副本数量,默认值为1
9 selector: # Label Selector,必须匹配Pod模板中的标签。
10 matchLabels:
11 app: nginx
12 template: # Pod 模板
13 metadata: #Pod名称会根据rs的name自动生成
14 labels:
15 app: nginx #一定要包含上面的 matchLabels里面的标签。
16 spec:
17 containers:
18 - name: nginx
19 image: nginx:latest # latest标签最好别用在线上
20 ports:
21 - containerPort: 80
上面的 YAML 文件结构和我们之前定义的 Pod 看上去没太大两样,有常见的 apiVersion、kind、metadata,在 spec 下面描述 ReplicaSet 的基本信息,其中包含3个重要内容:
replias:表示期望的 Pod 的副本数量
selector:Label Selector,用来匹配要控制的 Pod 标签,需要和下面的 Pod 模板中的标签一致
template:Pod 模板,实际上就是以前我们定义的 Pod 内容,相当于把一个 Pod 的描述以模板的形式嵌入到了 ReplicaSet 中来。
Pod 模板这个概念非常重要,因为后面我们讲解到的大多数控制器,都会使用 Pod 模板来统一定义它所要管理的 Pod。更有意思的是,我们还会看到其他类型的对象模板,比如Volume 的模板等。
上面就是我们定义的一个普通的 ReplicaSet 资源清单文件,ReplicaSet 控制器会通过定义的 Label Selector 标签去查找集群中的 Pod 对象:

- 我们直接来创建上面的资源对象:
1[root@master1 ~]#kubectl apply -f nginx-rs.yaml
2replicaset.apps/nginx-rs created
3[root@master1 ~]#kubectl get rs
4NAME DESIRED CURRENT READY AGE
5nginx-rs 3 3 3 46s
通过查看 RS 可以看到当前资源对象的描述信息,包括DESIRED、CURRENT、READY的状态值。
- 创建完成后,可以利用如下命令查看下 Pod 列表:
1[root@master1 ~]#kubectl get po -l app=nginx
2NAME READY STATUS RESTARTS AGE
3nginx-rs-7btxg 1/1 Running 0 82s
4nginx-rs-gfhzx 1/1 Running 0 82s
5nginx-rs-v8rrb 1/1 Running 0 82s
- 可以看到现在有 3 个 Pod,这 3 个 Pod 就是我们在 RS 中声明的 3 个副本,比如我们删除其中一个 Pod:
1[root@master1 ~]#kubectl delete pod nginx-rs-v8rrb
2pod "nginx-rs-v8rrb" deleted
然后再查看 Pod 列表:
1[root@master1 ~]#kubectl get po -l app=nginx
2NAME READY STATUS RESTARTS AGE
3nginx-rs-7btxg 1/1 Running 0 2m28s
4nginx-rs-gfhzx 1/1 Running 0 2m28s
5nginx-rs-xxplf 1/1 Running 0 28s
可以看到又重新出现了一个 Pod,这个就是上面我们所说的 ReplicaSet 控制器为我们做的工作,我们在 YAML 文件中声明了 3 个副本,然后现在我们删除了一个副本,就变成了两个,这个时候 ReplicaSet 控制器监控到控制的 Pod 数量和期望的 3 不一致,所以就需要启动一个新的 Pod 来保持 3 个副本,这个过程上面我们说了就是调谐的过程。
- 同样可以查看 RS 的描述信息来查看到相关的事件信息:
1[root@master1 ~]#kubectl describe rs nginx-rs
2Name: nginx-rs
3Namespace: default
4Selector: app=nginx
5Labels: <none>
6Annotations: <none>
7Replicas: 3 current / 3 desired
8Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
9Pod Template:
10 Labels: app=nginx
11 Containers:
12 nginx:
13 Image: nginx
14 Port: 80/TCP
15 Host Port: 0/TCP
16 Environment: <none>
17 Mounts: <none>
18 Volumes: <none>
19Events:
20 Type Reason Age From Message
21 ---- ------ ---- ---- -------
22 Normal SuccessfulCreate 3m31s replicaset-controller Created pod: nginx-rs-v8rrb
23 Normal SuccessfulCreate 3m31s replicaset-controller Created pod: nginx-rs-7btxg
24 Normal SuccessfulCreate 3m31s replicaset-controller Created pod: nginx-rs-gfhzx
25 Normal SuccessfulCreate 91s replicaset-controller Created pod: nginx-rs-xxplf
26[root@master1 ~]#
可以发现最开始通过 ReplicaSet 控制器创建了 3 个 Pod,后面我们删除了 Pod 后, ReplicaSet 控制器又为我们创建了一个 Pod,和上面我们的描述是一致的。
- 如果这个时候我们把 RS 资源对象的 Pod 副本更改为 2
spec.replicas=2,这个时候我们来更新下资源对象:
1[root@master1 ~]#vim nginx-rs.yaml
2……
3spec:
4 8 replicas: 2 #修改pod副本数为2
5 9 selector:
6 10 matchLabels:
7 11 app: nginx
8……
9[root@master1 ~]#kubectl apply -f nginx-rs.yaml
10replicaset.apps/nginx-rs configured
11[root@master1 ~]#
12
13[root@master1 ~]#kubectl get rs
14NAME DESIRED CURRENT READY AGE
15nginx-rs 2 2 2 5m38s
16[root@master1 ~]#kubectl describe rs nginx-rs
17Name: nginx-rs
18Namespace: default
19Selector: app=nginx
20Labels: <none>
21Annotations: <none>
22Replicas: 2 current / 2 desired
23Pods Status: 2 Running / 0 Waiting / 0 Succeeded / 0 Failed
24Pod Template:
25 Labels: app=nginx
26 Containers:
27 nginx:
28 Image: nginx
29 Port: 80/TCP
30 Host Port: 0/TCP
31 Environment: <none>
32 Mounts: <none>
33 Volumes: <none>
34Events:
35 Type Reason Age From Message
36 ---- ------ ---- ---- -------
37 Normal SuccessfulCreate 5m43s replicaset-controller Created pod: nginx-rs-v8rrb
38 Normal SuccessfulCreate 5m43s replicaset-controller Created pod: nginx-rs-7btxg
39 Normal SuccessfulCreate 5m43s replicaset-controller Created pod: nginx-rs-gfhzx
40 Normal SuccessfulCreate 3m43s replicaset-controller Created pod: nginx-rs-xxplf
41 Normal SuccessfulDelete 19s replicaset-controller Deleted pod: nginx-rs-xxplf
42[root@master1 ~]#
可以看到 Replicaset 控制器在发现我们的资源声明中副本数变更为 2 后,就主动去删除了一个 Pod,这样副本数就和期望的始终保持一致了:
1[root@master1 ~]#kubectl get po -l app=nginx
2NAME READY STATUS RESTARTS AGE
3nginx-rs-7btxg 1/1 Running 0 6m12s
4nginx-rs-gfhzx 1/1 Running 0 6m12s
- 我们可以随便查看一个 Pod 的描述信息可以看到这个 Pod 的所属控制器信息:
1[root@master1 ~]#kubectl get po -l app=nginx
2NAME READY STATUS RESTARTS AGE
3nginx-rs-7btxg 1/1 Running 0 6m50s
4nginx-rs-gfhzx 1/1 Running 0 6m50s
5[root@master1 ~]#kubectl describe pod nginx-rs-gfhzx
6Name: nginx-rs-gfhzx
7Namespace: default
8Priority: 0
9Node: node2/172.29.9.53
10Start Time: Mon, 08 Nov 2021 21:30:03 +0800
11Labels: app=nginx
12Annotations: <none>
13Status: Running
14IP: 10.244.2.13
15IPs:
16 IP: 10.244.2.13
17Controlled By: ReplicaSet/nginx-rs #从这里可以看到,这个pod是被ReplicaSet/nginx-rs控制;
18……
19[root@master1 ~]#
- 另外被 ReplicaSet 持有的 Pod 有一个
**metadata.ownerReferences****指针指向当前的 ReplicaSet,表示当前 Pod 的所有者,这个引用主要会被集群中的垃圾收集器使用以清理失去所有者的 Pod 对象。**这个ownerReferences和数据库中的外键是不是非常类似。可以通过将 Pod 资源描述信息导出查看:
1[root@master1 ~]#kubectl get po -l app=nginx
2NAME READY STATUS RESTARTS AGE
3nginx-rs-7btxg 1/1 Running 0 8m48s
4nginx-rs-gfhzx 1/1 Running 0 8m48s
5
6[root@master1 ~]#kubectl edit pod nginx-rs-gfhzx
7或者
8[root@master1 ~]#kubectl get po nginx-rs-gfhzx -oyaml
9 ownerReferences:
10 - apiVersion: apps/v1
11 blockOwnerDeletion: true
12 controller: true
13 kind: ReplicaSet
14 name: nginx-rs
15 uid: e1b9d63b-6be5-4a9f-b565-1d8eea92c727
我们可以看到 Pod 中有一个 metadata.ownerReferences 的字段指向了 ReplicaSet 资源对象。如果要彻底删除 Pod,我们就只能删除 RS 对象:
1[root@master1 ~]#kubectl delete rs nginx-rs
2replicaset.apps "nginx-rs" deleted
3[root@master1 ~]#kubectl get rs,pod
4No resources found in default namespace.
5[root@master1 ~]#
6
7或者:执行 kubectl delete -f nginx-rs.yaml
8
9或者:你如果想彻底删除pod,就需要把rs给删除掉或者把rs里的副本数改为0;
这就是 ReplicaSet 对象的基本使用。
- 注意,我们直接修改
nginx-rs.yaml里的镜像版本后,是没办法改变pod里的镜像版本的,即:RS不支持应用的更新操作。
1# 查看当前应用镜像版本
2[root@master1 ~]#kubectl get po -l app=nginx
3NAME READY STATUS RESTARTS AGE
4nginx-rs-dfkqr 1/1 Running 0 38s
5nginx-rs-ml7gc 1/1 Running 0 38s
6nginx-rs-p2p6q 1/1 Running 0 38s
7[root@master1 ~]#kubectl get po ginx-rs-dfkqr -oyaml
8……
9 spec:
10 containers:
11 - image: nginx:latest
12……
13[root@master1 ~]#kubectl get rs nginx-rs -oyaml
14……
15 spec:
16 containers:
17 - image: nginx:latest
18……
19
20
21#来执行一次更新应用操作
22[root@master1 ~]#vim nginx-rs.yaml
23……
24 spec:
25 containers:
26 - name: nginx
27 image: nginx:1.7.9 # 修改为1.7.9
28……
29然后执行apply操作:
30[root@master1 ~]#kubectl apply -f nginx-rs.yaml
31replicaset.apps/nginx-rs configured
32
33
34#观察效果
35#可以看到,pod并没有被重建,且其nginx镜像版本未发生变化
36[root@master1 ~]#kubectl get po -l app=nginx
37NAME READY STATUS RESTARTS AGE
38nginx-rs-dfkqr 1/1 Running 0 4m55s
39nginx-rs-ml7gc 1/1 Running 0 4m55s
40nginx-rs-p2p6q 1/1 Running 0 4m55s
41[root@master1 ~]#kubectl get po nginx-rs-dfkqr -oyaml
42……
43spec:
44 containers:
45 - image: nginx:latest
46……
47[root@master1 ~]#kubectl get rs
48NAME DESIRED CURRENT READY AGE
49nginx-rs 3 3 3 5m52s
50#rs导出的资源清单里pod模板里的惊险版本发生了变化。
51[root@master1 ~]#kubectl get rs -oyaml
52……
53spec:
54 containers:
55 - image: nginx:1.7.9
56……
实验到此结束。😘
Replication Controller(了解即可)
Replication Controller 简称 RC,实际上 RC 和 RS 的功能几乎一致,RS 算是对 RC 的改进,目前唯一的一个区别就是 RC 只支持基于等式的 selector(env=dev或environment!=qa),但 RS 还支持基于集合的 selector(version in (v1.0, v2.0)),这对复杂的运维管理就非常方便了。
比如上面资源对象如果我们要使用 RC 的话,对应的 selector 是这样的:
1selector:
2 app: nginx
RC 只支持单个 Label 的等式,而 RS 中的 Label Selector 支持 matchLabels 和 matchExpressions 两种形式:
1selector:
2 matchLabels:
3 app: nginx
4
5---
6selector:
7 matchExpressions: # 该选择器要求 Pod 包含名为 app 的标签
8 - key: app
9 operator: In
10 values: # 并且标签的值必须是 nginx
11 - nginx

总的来说 RS 是新一代的 RC,所以以后我们不使用 RC,直接使用 RS 即可,他们的功能都是一致的,**但是实际上在实际使用中我们也不会直接使用 RS,而是使用更上层的类似于 Deployment 这样的资源对象。**注意,一般,还是matchLabels用的多一些。
关于我
我的博客主旨:
- 排版美观,语言精炼;
- 文档即手册,步骤明细,拒绝埋坑,提供源码;
- 本人实战文档都是亲测成功的,各位小伙伴在实际操作过程中如有什么疑问,可随时联系本人帮您解决问题,让我们一起进步!
🍀 微信二维码
x2675263825 (舍得), qq:2675263825。

🍀 微信公众号
《云原生架构师实战》

🍀 语雀
https://www.yuque.com/xyy-onlyone
https://www.yuque.com/xyy-onlyone/exkgza?# 《语雀博客》

🍀 博客


🍀 csdn
https://blog.csdn.net/weixin_39246554?spm=1010.2135.3001.5421

🍀 知乎
https://www.zhihu.com/people/foryouone

最后
好了,关于本次就到这里了,感谢大家阅读,最后祝大家生活快乐,每天都过的有意义哦,我们下期见!

1

