K8S使用deployment 管理Pod以及滚动更新（6）

K8S使用deployment 管理Pod以及滚动更新（6）

前面有使用pod的举例，但是我们现在有一个Pod正在提供线上的服务，我们来想想一下我们可能会遇到的一些场景：

某次运营活动非常成功，网站访问量突然暴增可以使用【HPA】运行当前Pod的节点发生故障了，Pod不能正常提供服务了【高可用pod】后面是解决方法，但是如果没有或者我们不了解底层pod运行模式，需要手动去干预处理，将会非常的麻烦。第一种情况，可能比较好应对，一般活动之前我们会大概计算下会有多大的访问量，提前多启动几个Pod，活动结束后再把多余的Pod杀掉，虽然有点麻烦，但是应该还是能够应对这种情况的。

第二种情况，可能某天夜里收到大量报警说服务挂了，然后起来打开电脑在另外的节点上重新启动一个新的Pod，问题也很好的解决了。

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

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的功能

看一下yaml中有哪些修改

minReadySeconds:Kubernetes在等待设置的时间后才进行升级如果没有设置该值，Kubernetes会假设该容器启动起来后就提供服务了如果没有设置该值，在某些极端情况下可能会造成服务不正常运行

maxSurge:升级过程中最多可以比原先设置多出的POD数量例如：maxSurage=1，replicas=5,则表示Kubernetes会先启动1一个新的Pod后才删掉一个旧的POD，整个升级过程中最多会有5+1个POD。

比如要回滚

好了deployment，今天就讲到这里，后面有啥疑问可以私信我，欢迎评论区留言

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。