Fork me on GitHub

kubernetes系列之《构建企业级CICD平台(一)》

前言:本文是构建CICD的开篇文章,主要介绍常用的几种发布方案以及k8s采用的发布方案,为构建CICD平台做知识铺垫。

一、项目发布方案

1.1、蓝绿发布

蓝绿发布又称蓝绿部署,英文名Vlue Green Deployment,是一种可以保证在“不间断提供服务”的情况下上线的部署方法。

如何保证系统不间断提供服务呢?

蓝绿部署的模型中包含两个集群:

在没有上线的正常情况下,集群A和集群B的代码版本是一致的,并且同事对外提供服务。

在系统升级的时候,我们首先把一个集群(比如集群A)从负载列表中摘除,进行新版本的部署,集群B任然继续提供服务。

当集群A升级完毕,我们把负载均衡重新指向集群A,再把集群B从集群列表中摘除,进行新版本的部署,集群A重新提供服务。

最后,当集群B也升级完成,吧集群B也恢复到负载列表当中。这时两个集群的版本都已经升级完成,并且对外的服务几乎没有间断过。

优点:

  • 同一时间对外提供的服务只有一个版本,容易定位问题。
  • 升级和回滚以集群为粒度,操作相对简单。

缺点:

  • 需要维护两个集群,成本较高

1.2、灰度发布

灰度发布又称金丝雀发布,有一个典故:以前旷工开矿下矿洞前先会放一只金丝雀进去探是否有有毒气体,看金丝雀能否活下来,金丝雀发布由此得名。
金丝雀发布一般先发布1台,或者一个小比例,例如20%的服务器,主要做流量验证用。

发布前:

先发布一台金丝雀:

全部发完:

如果金丝雀测试通过,则把剩余的V1版本全部升级为V2版本。如果金丝雀测试失败,则直接退回金丝雀,发布失败。

优点:

  • 用户体验影响小,金丝雀发布过程出现问题只影响少量用户

缺点:

  • 发布自动化程度不够,发布期间可引发服务中断

1.3、滚动发布

滚动发布又称滚动部署,英文名Rolling Update,同样是一种可以保证系统在“不间断提供服务”的情况下上线的部署方式。

和蓝绿部署不同的是,滚动部署对外提供服务的版本并不是非此即彼,而是在“更细的粒度下平滑完成版本的升级”

如何做到细粒度平滑升级版本呢?

滚动部署只需要一个集群,集群下的不同节点可以独立进行版本升级。比如在一个16节点的集群中,选择每次升级4个节点:

滚动升级中:

滚动升级中:

以此类推,最终所有的节点都升级到新版,并且保证不间断服务。

优点:

  • 只需要维护一个集群,成本较低

缺点:

  • 上线过程中,两个版本同时对外提供服务,不容易定位问题,且容易造成数据错乱。
  • 升级和回滚以节点为粒度,操作相对复杂。

1.4、K8s中的滚动更新

蓝绿发布和灰度发布两种方案在k8s里本身不支持,但也可以另寻他法来实现。

Kubernetes使用Rolling Update解决了不停服务正常更新部署的困境,简单到只要一条语句就解决了这个问题。简单来说,kubernetes会滚动更新,一个一个的替换,从全部是旧的replica到新旧共存再到全部是新的。接下来我们看一下这个过程:

更新之前:
Service A在3个Node上启动了4个Pod,每个Pod中存放的都是相同的容器应用

滚动更新:
更新的时候,使用新的容器替换旧的

滚动更新所有Pod:


经过上面步骤后,滚动更新就完成了,而且全程是可以访问的状态。

开篇文章结束,请关注下一篇文章。

-------------本文结束感谢您的阅读-------------