05-使用Replication Controller、Replica Set 管理Pod

最新推荐文章于 2024-09-21 23:47:00 发布

玖丶C

最新推荐文章于 2024-09-21 23:47:00 发布

阅读量143

点赞数

分类专栏： k8s 文章标签： kubernetes

本文链接：https://blog.csdn.net/qq_47261578/article/details/119646904

版权

k8s 专栏收录该内容

12 篇文章 1 订阅

订阅专栏

本文介绍了Kubernetes中用于管理Pod的ReplicationController（RC）和ReplicaSet（RS）的概念及使用。RC保证Pod副本数，自动处理Pod的增删，而RS在功能上与RC类似，但支持更复杂的标签选择器。通过修改RC或RS的配置，可以实现Pod的动态扩缩容和滚动升级，简化运维工作。在实际生产环境中，推荐使用Deployment来管理Pod和RS。

摘要由CSDN通过智能技术生成

使用Replication Controller、Replica Set 管理Pod

前面我们学习了Pod的一些基本使用方法，而且前面我们都是直接来操作的Pod，假如现在有一个Pod正在提供线上的服
务，我们来想想一下我们可能会遇到的一些场景：

某次运营活动非常成功，网站访问量突然暴增
运行当前Pod的节点发生故障了，Pod不能正常提供服务了

第一种情况，可能比较好应对，一般活动之前我们会大概计算下会有多大的访问量，提前多启动几个Pod，活动结束后把多余的Pod杀掉，虽然有点麻烦，但是应该还是能够应对这种情况的。
第二种情况，可能某天夜里收到大量报警说服务挂了，然后起来打开电脑在另外的节点上重新启动一个新的Pod，问题也
很好的解决了。如果我们都人工的去解决遇到的这些问题，似乎又回到了以前刀耕火种的时代了，如果有一种工具能够来帮助我们管理Pod就好了，Pod不够了自动帮我新增一个，Pod挂了自动帮我在合适的节点上重新启动一个Pod，这样是不是遇到上面的问题我们都不需要手动去解决了。

Kubernetes就为我们提供了这样的资源对象：

Replication Controller：用来部署、升级Pod
Replica Set：下一代的Replication Controller
Deployment：可以更加方便的管理Pod和Replica Set

Replication Controller（RC）

Replication Controller简称RC，RC是Kubernetes系统中的核心概念之一，简单来说，RC可以保证在任意时间运行Pod的副本数量，能够保证Pod总是可用的。如果实际Pod数量比指定的多那就结束掉多余的，如果实际数量比指定的少就新启动一些Pod，当Pod失败、被删除或者挂掉后，RC都会去自动创建新的Pod来保证副本数量，所以即使只有一个Pod，我们也应该使用RC来管理我们的Pod。

在实际生产中，可能除了第一种情况不能做到完全自动化，其余的我们是不是都用担心了，运行Pod的节点挂了，RC检到Pod失败了，就会去合适的节点重新启动一个Pod就行，不需要我们手动去新建一个Pod了。如果是第一种情况的话在活动开始之前我们给Pod指定10个副本，活动结束后将副本数量改成2，这样是不是也远比我们手动去操作要好得多，而且面还会介绍另外一种资源对象**HPA（水平自动伸缩 [弹性伸缩]）**可以根据资源的使用情况来进行自动扩缩容，这样以后遇到这种情况，我们就真的可以安心的去睡觉了。

现在我们来使用RC来管理我们前面使用的Nginx的Pod。

编写 rc-demo.yaml

[root@k8s-master ~]# vim rc-demo.yaml
apiVersion: v1
kind: ReplicationController
metadata:
  name: rc-demo		#ReplicationController的名称
  labels:
    name: rc		#ReplicationController的标签
spec:
  replicas: 3		#副本数量3个
  selector:			#标签选择器
    name: rc		#匹配标签等于rc的进行绑定
  template:			#模板
    metadata:
      labels:
        name: rc		#这里的标签名称要与标签选择器要绑定的标签一致
    spec:
      containers:
      - name: nginx-demo	#容器名称
        image: nginx	
        ports:
        - containerPort: 80		#容器开放80端口

上面的YAML文件相对于我们之前的Pod的格式：

kind：ReplicationController
spec.replicas: 指定Pod副本数量，默认为1
spec.selector: RC通过该属性来筛选要控制的Pod
spec.template: 这里就是定义Pod的模块，但是不需要apiVersion和kind
spec.template.metadata.labels: 注意这里的Pod的 labels要和spec.selector相同，这样RC就可以来控制当前这个Pod。

这个YAML文件中的意思就是定义了一个RC资源对象，它的名字叫rc-demo，保证一直会有3个Pod运行，Pod的镜像是nginx镜像。

**注意：**spec.selector和 spec.template.metadata.labels这两个字段必须相同，否则会创建失败的，当然我们也可以不写spec.selector，这样就默认与Pod模板中的metadata.labels相同了。所以为了避免不必要的错误的话，不写为好。

然后我们来创建上面的RC对象(保存为 rc-demo.yaml):

创建yaml文件

[root@k8s-master ~]# kubectl create -f rc-demo.yaml
replicationcontroller/rc-demo created
#创建后进行查看
[root@k8s-master ~]# kubectl get rc			#rc=replicationcontrollers的缩写
NAME      DESIRED   CURRENT   READY   AGE
rc-demo   3         3         3       11m
# DESIRED 期望有3个副本， CURRENT 当前有三个副本, READY当前可用的3个副本  ，AGE运行时长
[root@k8s-master ~]# kubectl get po | grep rc	
rc-demo-krgv5   1/1     Running   0          9m8s
rc-demo-r6sbr   1/1     Running   0          9m8s
rc-demo-s65mr   1/1     Running   0          9m8s
#此时已经创建3个副本，并且都为running
[root@k8s-master ~]# kubectl describe rc rc-demo
#查看该rc的详细信息

通过修改配置文件更改副本数量

[root@k8s-master ~]# sed -i  's/replicas:\ 3/replicas:\ 2/' rc-demo.yaml
#修改副本数量为2个
[root@k8s-master ~]# kubectl apply -f rc-demo.yaml	#生效配置信息
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
replicationcontroller/rc-demo configured
[root@k8s-master ~]# kubectl get rc
NAME      DESIRED   CURRENT   READY   AGE
rc-demo   2         2         2       21m
#此时的副本数量已经更改为2台了
[root@k8s-master ~]# kubectl get po | grep rc
rc-demo-krgv5   1/1     Running   0          22m
rc-demo-s65mr   1/1     Running   0          22m
[root@k8s-master ~]# kubectl describe rc rc-demo

可以使用apply进行更新生效配置文件

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

或者使用edit (vim编辑器模式：编辑完成后立即生效)

[root@k8s-master ~]# kubectl edit rc rc-demo

进入后可以在末行模式搜索

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JLbsRXpv-1628755610965)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20210301164120910.png)]

找到对应的副本数量进行更改[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-blKKAP3S-1628755610969)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20210301164154381.png)]

     82 spec:
     83   replicas: 3		#更改副本数量为3
     84   selector:
：wq			#末行模式保存退出

保存退出后配置立即生效

[root@k8s-master ~]# kubectl edit rc rc-demo
replicationcontroller/rc-demo edited
[root@k8s-master ~]# kubectl get pod | grep rc
rc-demo-krgv5   1/1     Running   0          33m
rc-demo-qgztx   1/1     Running   0          50s
rc-demo-s65mr   1/1     Running   0          33m

而且我们还可以通过修改YAML文件来进行滚动升级，比如我

们将镜像地址更改为nginx:1.7.9 :

kubectl apply -f rc-demo.yaml

如果升级完成后出现了新的问题，想要一键回滚到上一个版本的话，使用RC只能用同样的方法把镜像地址替换成之前的，然后重新滚动升级

Replication Set（RS）

Replication Set简称RS，随着Kubernetes的高速发展，官方已经推荐我们使用RS和Deployment来代替RC了，实际上RS和RC的功能基本一致，目前唯一的一个区别就是RC只支持基于等式的selector（env=dev或environment!=qa），但RS还支持基于集合的selector(标签)（version in (v1.0, v2.0)），这对复杂的运维管理就非常方便。

kubectl命令行工具中关于RC的大部分命令同样适用于我们的RS资源对象。不过很少会去单独使用RS，它主要被Deployment这个更加高层的资源对象使用，除非用户需要自定义升级功能或根本不需要升级Pod，在一般情况下，推荐使用Deployment而不直接使用Replica Set。

最后我们总结下关于RC / RS的一些特性和作用吧：

大部分情况下，我们可以通过定义一个RC实现的Pod的创建和副本数量的控制
RC中包含一个完整的Pod定义模块（不包含apiversion 和kind）
RC是通过label selector机制来实现对Pod副本的控制的
通过改变RC里面的Pod副本数量，可以实现Pod的扩缩容功能通过改变RC里面的Pod模板中镜像版本，可以实现Pod的滚动升级功能（但是不支持一键回滚，需要用相同的方法去修改镜像地址）