本文主要是介绍kubernetes如何利用ReplicationController、Replica Set、Deployment管理Pod,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
Pod直译是豆荚,我们可以把容器想像成豆荚里的豆子,把一个或多个关系紧密的豆子包在一起就是豆荚(一个Pod)。在k8s中我们不会直接操作容器,而是把容器包装成Pod,而对于Pod,我们该如何管理?先看下面这个场景:
应用场景:
假设有一个Pod正在提供线上服务,我们想想如何应对以下几个场景:
1.节日活动,网站访问量突增
2.遭到攻击,网站访问量突增
3.运行Pod的节点发生故障
第1种情况,活动前预先多启动几个Pod,活动结束后再结束掉多余的,虽然要启动和结束的Pod有点多,但也能有条不紊按计划进行。
第2种情况,正在睡觉突然手机响了说网站反应特慢卡得要死,赶紧爬起来边扩容边查找攻击模式、封IP等等……
第3种情况,正在休假突然手机又响了说网站上不去,赶紧打开电脑查看原因,启动新的Pod。
Pod需要手动管理,好累……
因此,我们需要一种方式,来自动管理Pod的伸缩。本文将介绍如何利用ReplicationController、Replica Set、Deploymen来管理Pod,分为以下三部分:
-
使用ReplicationController来部署、升级Pod
-
Replica Set—下一代的ReplicationController
-
Deployment — 更加方便的管理Pod和Replica Set
一、使用ReplicationController(rc)部署、升级Pod
RC保证在同一时间能够运行指定数量的Pod副本,保证Pod总是可用。如果实际Pod数量比指定的多就结束掉多余的,如果实际数量比指定的少就启动缺少的。当Pod失败、被删除或被终结时,RC会自动创建新的Pod来保证副本数量,所以即使只有一个Pod,也应该使用RC来进行管理。我们先看以下这个rc.yaml文件
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
-
yaml字段的含义:
spec.replicas:副本数量3
spec.selector:RC通过spec.selector来筛选要控制的Pod
spec.template:这里写Pod的定义(但不需要apiVersion和kind)
spec.template.metadata.labels:Pod的label,可以看到这个label与spec.selector相同 -
这个文件的意思:
定义一个RC对象,它的名字是frontend(metadata.name:frontend),保证有3个Pod运行(spec.replicas:3),Pod的镜像是kubeguide/guestbook-PHP-frontend:latest(spec.template.spec.containers.image:kubeguide/guestbook-php-frontend:latest) -
关键在于spec.selector与spec.template.metadata.labels,这两个字段必须相同,否则下一步创建RC会失败。(也可以不写spec.selector,这样默认与spec.template.metadata.labels相同)
接着我们来看操作RC的常用命令:
- 通过kubectl创建RC
- 1
- 1
- 查看RC具体信息
- 1
- 1
- 通过RC修改Pod副本数量(需要修改yaml文件的spec.replicas字段到目标值,然后替换旧的yaml文件)
- 1
- 2
- 3
- 4
- 5
- 1
- 2
- 3
- 4
- 5
- 对RC使用滚动升级,来发布新功能或修复BUG
- 1
- 1
- 当Pod中只有一个容器时,通过–image参数指定新的Tag,如果有多个容器或其他字段修改时,需要指定yaml文件
- 1
- 1
如果在升级过程中出现问题(如发现配置错误、长时间无响应),可以使用CTRL+C退出,再进行回滚
- 1
- 1
但如果升级完成后出现问题(比如新版本程序出core),此命令无能为力,需要使用同样方法“升级”为旧版本。
二、Deployment—更加方便的管理Pod和Replica Set
k8s是一个高速发展的项目,在新的版本中,官方推荐使用Replica Set和Deployment来代替RC。那么它们优势在哪里,我们来看一看:
-
RC只支持基于等式的selector(env=dev或environment!=qa)但Replica Set还支持新的、基于集合的selector(version in (v1.0, v2.0)或env notin (dev, qa)),这对复杂的运维管理带来很大方便。
-
使用Deployment升级Pod,只需要定义Pod的最终状态,k8s会为你执行必要的操作,虽然能够使用命令 # kubectl rolling-update 完成升级,但它是在客户端与服务端多次交互控制RC完成的,所以REST API中并没有rolling-update的接口,这为定制自己的管理系统带来了一些麻烦。
-
Deployment拥有更加灵活强大的升级、回滚功能。
目前,Replica Set与RC的区别只是支持的selector不同,后续肯定会加入更多功能。Deployment使用了Replica Set,是更高一层的概念。除非需要自定义升级功能或根本不需要升级Pod,一般情况下,我们推荐使用Deployment而不直接使用Replica Set。
- 使用子命令create,创建Deployment
- 1
- 1
注意–record参数,使用此参数将记录后续创建对象的操作,方便管理与问题追溯
- 使用子命令edit,编辑spec.replicas/spec.template.spec.container.image字段,完成deployment的扩缩容与滚动升级(这要比子命令rolling-update速度快很多)
- 1
- 1
- 使用rollout history命令,查看Deployment的历史信息
- 1
- 1
- 上面提到RC在rolling-update升级成功后不能直接回滚,而使用Deployment却可以回滚到上一版本,但要加上–revision参数,指定版本号
- 1
- 1
使用rollout undo回滚到上一版本
- 1
- 1
使用–to-revision可以回滚到指定版本
- 1
- 1
三、总结
通过对比,我们发现新的Replica Set、Deployment,比RC要强大易用很多。
这篇关于kubernetes如何利用ReplicationController、Replica Set、Deployment管理Pod的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!