前面有使用pod的举例,但是我们现在有一个Pod正在提供线上的服务,我们来想想一下我们可能会遇到的一些场景:
某次运营活动非常成功,网站访问量突然暴增可以使用【HPA】
运行当前Pod的节点发生故障了,Pod不能正常提供服务了【高可用pod】
后面是解决方法,但是如果没有或者我们不了解底层pod运行模式,需要手动去干预处理,将会非常的麻烦。
第一种情况,可能比较好应对,一般活动之前我们会大概计算下会有多大的访问量,提前多启动几个Pod,活动结束后再把多余的Pod杀掉,虽然有点麻烦,但是应该还是能够应对这种情况的。
第二种情况,可能某天夜里收到大量报警说服务挂了,然后起来打开电脑在另外的节点上重新启动一个新的Pod,问题也很好的解决了。
k8s中已经想到了这些问题所以为我们提供了相对应的机制
Replication Controller(RC)
RC可以保证在任意时间运行Pod的副本数量,能够保证Pod总是可用的。
比如运行2个Pod的节点挂了,RC检测到Pod失败了,就会去合适的节点重新启动一个Pod就行,不需要我们手动去新建一个Pod。
还有就是在之前我们定义了20个pod,一旦流量上来之后,自动扩容,这样可以减少我们人工干预,另外也自动化特别方便。
现在我们来使用RC来管理我们前面使用的Nginx的Pod,YAML文件如下:
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了。
意思就是定义了一个RC资源对象,它的名字叫rc-demo,保证一直会有3个Pod运行,Pod的镜像是nginx镜像。
【注意】:注意spec.selector和spec.template.metadata.labels这两个字段必须相同,否则会创建失败的,当然我们也可以不写spec.selector,这样就默认与Pod模板中的metadata.labels相同了
查看一下是否启动:
我们通过RC来修改下Pod的副本数量为2
kubectl edit rc rc-demo
再次查看
我们还可以用RC来进行滚动升级,比如我们将镜像地址更改为nginx:1.7.9
咱们看一下效果
看到了吧,比如我们有2个pod,如果要升级,是先启动一个,然后在删掉原来旧的一个,在启动一个新的,在删掉原来的旧的,一个一个替换,不会直接都删掉的,这样保证了业务对外的不间断性,提高了业务的访问良好
看一下效果
效果非常的好
Replication Set简称RS,随着Kubernetes的高速发展,官方已经推荐我们使用RS和Deployment来代替RC了,实际上RS和RC的功能基本一致
最后我们总结下关于RC/RS的一些特性和作用吧:
大部分情况下,我们可以通过定义一个RC实现的Pod的创建和副本数量的控制
RC中包含一个完整的Pod定义模块(不包含apiversion和kind)
RC是通过label selector机制来实现对Pod副本的控制的
通过改变RC里面的Pod副本数量,可以实现Pod的扩缩容功能
通过改变RC里面的Pod模板中镜像版本,可以实现Pod的滚动升级功能(但是不支持一键回滚,需要用相同的方法去修改镜像地址)
总结:
Replication Controller和Replica Set两种资源对象,RC和RS的功能基本上是差不多的,唯一的区别就是RS支持集合的selector。我们也学习到了用RC/RS来控制Pod副本的数量,也实现了滚动升级Pod的功能
------------------------------===========================------------------------
接下来开始控制器:
Deployment的使用
概念总结
RC的全部功能:Deployment具备上面描述的RC的全部功能
事件和状态查看:可以查看Deployment的升级详细进度和状态
回滚:当升级Pod的时候如果出现问题,可以使用回滚操作回滚到之前的任一版本
版本记录:每一次对Deployment的操作,都能够保存下来,这也是保证可以回滚到任一版本的基础
暂停和启动:对于每一次升级都能够随时暂停和启动
启动一下,然后查看
我们这里重点给大家演示下Deployment的滚动升级和回滚功能。
看一下yaml中有哪些修改
minReadySeconds:
Kubernetes在等待设置的时间后才进行升级
如果没有设置该值,Kubernetes会假设该容器启动起来后就提供服务了
如果没有设置该值,在某些极端情况下可能会造成服务不正常运行
maxSurge:
升级过程中最多可以比原先设置多出的POD数量
例如:maxSurage=1,replicas=5,则表示Kubernetes会先启动1一个新的Pod后才删掉一个旧的POD,整个升级过程中最多会有5+1个POD。
maxUnavaible:
升级过程中最多有多少个POD处于无法提供服务的状态
当maxSurge不为0时,该值也不能为0
例如:maxUnavaible=1,则表示Kubernetes整个升级过程中最多会有1个POD处于无法服务的状态。
看一下升级后的RS
暂停和继续 升级:
比如要回滚
查看有多少个版本
kubectl rollout history deployment nginx-deploy
kubectl rollout history deployment nginx-deploy --revision=1
上面是查看信息的
包括每个版本镜像和labels
接下来回滚,最好指定版本,不容易混乱
kubectl rollout undo deployment nginx-deploy --to-revision=1
逐个在替换
这个指定版本比较推荐,当然也可以直接使用
kubectl rollout undo deployment nginx-deploy
直接回滚到上个版本,
好了deployment,今天就讲到这里,后面有啥疑问可以私信我,欢迎评论区留言
原文地址:https://blog.51cto.com/xiaorenwutest/2482636