K8S使用deployment 管理Pod以及滚动更新(6)

前面有使用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

时间: 2024-11-03 20:50:22

K8S使用deployment 管理Pod以及滚动更新(6)的相关文章

[转帖] Kubernetes如何使用ReplicationController、Replica Set、Deployment管理Pod ----文章很好 但是还没具体操作实践 也还没记住.

Kubernetes如何使用ReplicationController.Replica Set.Deployment管理Pod https://blog.csdn.net/yjk13703623757/article/details/53746273 Pod直译是豆荚,我们可以把容器想像成豆荚里的豆子,把一个或多个关系紧密的豆子包在一起就是豆荚(一个Pod).在k8s中我们不会直接操作容器,而是把容器包装成Pod,而对于Pod,我们该如何管理?先看下面这个场景: 1. 应用场景 假设有一个Pod

k8s如何管理Pod(rc、rs、deployment)

是豆荚,可以把容器想像成豆荚里的豆子,把一个或多个关系紧密的豆子包在一起就是豆荚(一个Pod).在k8s中我们不会直接操作容器,而是把容器包装成Pod再进行管理(关于Pod,大家可以参考第十期的分享"谈谈Pod在微服务中的运用").Pod是运行服务的基础,那我们如何来管理Pod呢,下面我们就来聊一聊.分为这三个部分: 使用Replication Controller 来部署.升级Pod Replica Set – 下一代Replication Controller Deployment

详细聊聊k8s deployment的滚动更新(二)

一.知识准备 ● 本文详细探索deployment在滚动更新时候的行为 ● 相关的参数介绍: ??livenessProbe:存活性探测.判断pod是否已经停止 ??readinessProbe:就绪性探测.判断pod是否能够提供正常服务 ??maxSurge:在滚动更新过程中最多可以存在的pod数 ??maxUnavailable:在滚动更新过程中最多不可用的pod数 二.环境准备 组件 版本 OS Ubuntu 18.04.1 LTS docker 18.06.0-ce 三.准备镜像.yam

K8S使用Statefulset管理集群pod模式(7)

上次我们说到了deployment来管理pod容器的副本数量,如果挂掉之后容器再次启动就可以了,但是如果要是启动的是mysql集群.zookeeper集群.etcd这种集群,里面都有id号,这种有关联的,如果一旦挂掉之后,在启动之后呢,集群id是否会变化呢?答案是肯定会变的.那有没有另外的一种控制器模式吗?当然k8s会给我吗提供的.[statefulset]那什么场景需要使用StatefulSet呢?官方给出的建议是,如果你部署的应用满足以下一个或多个部署需求,则建议使用StatefulSet

Kubernetes Pod应用的滚动更新(八)

一.环境准备 我们紧接上一节的环境,进行下面的操作,如果不清楚的,可以先查看上一篇博文. 滚动更新是一次只更新一小部分副本,成功后,再更新更多的副本,最终完成所有副本的更新.滚动更新的最大的好处是零停机,整个更新过程始终有副本在运行,从而保证了业务的连续性. 二.更新 我们查看一下上一节的配置文件mytest-deploy.yaml. apiVersion: extensions/v1beta1 kind: Deployment metadata: name: mytest spec: repl

深入玩转K8S之智能化的业务弹性伸缩和滚动更新操作

在上篇我们讲到了较为傻瓜初级的弹性伸缩和滚动更新,那么接下来我们来看看较为高级的智能的滚动更新.本节的知识点呢是K8S的liveness和readiness探测,也就是说利用健康检查来做更为智能化的弹性扩容和滚动更新. 那为什么说是比较智能化呢,因为在实际生产环境中会遇到这样那样的问题,比如:容器里面应用挂了或者说新启动的容器里面应用还没有就绪等等,所以说就需要进行探测来检验容器是否满足需求. 那么一般的检测分为几种,比如:进程检测.业务检测. 进程检测呢很好理解,也就是说通过检测容器进程来验证

linux运维、架构之路-K8s滚动更新及回滚

一.滚动更新        应用程序一次只更新一小部分副本,更新成功后,再更新更多的副本,最终完成所有副本的更新. 滚动更新的优点:零停机,整个更新过程始终有副本在运行,从而保证了业务的连续性. 1.创建三个副本Httpd服务,初始镜像为httpd:2.2.31,然后滚动更新至httpd:2.2.32 ###cat httpd.yaml### apiVersion: apps/v1beta2 kind: Deployment metadata: name: httpd spec: replica

kubernetes云平台管理实战:deployment通过标签管理pod(十)

一.kubectl run命令拓展 1.RC创建 [root@k8s-master ~]# kubectl run web --generator=run/v1 --image=10.0.128.0:5000/nginx:1.13 --replicas=3 replicationcontroller "web" created 2.deployment创建 [root@k8s-master ~]# kubectl run web --image=10.0.128.0:5000/ngin

k8s运行DaemonSet控制器管理pod(8)

前面介绍了k8s的deployment和statefulset这两种控制器.deployment是属于无状态的服务,nginx,Tomcat,没有关联的podstatefulset是属于有状态的服务.mysql,zk.etcd,集群形式的pod 下面我们来介绍一下第三种方式DaemonSet这种控制器模式DaemonSet 的典型应用场景:在集群的每个节点上运行存储 Daemon,比如:glusterd 或 ceph.在每个节点上运行日志收集 Daemon,比如:flunentd 或 logst