kubernetes 入门实践-滚动发布

ㅤㅤㅤ
ㅤㅤㅤ
ㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤ（没有目的，就做不成任何事情；目的渺小，就做不成任何大事——狄德罗）
ㅤㅤㅤ
ㅤㅤㅤ
ㅤㅤㅤㅤㅤㅤㅤㅤㅤ
kubernetes 入门实践-操作k8s集群
在了解k8s的滚动发布之前，我们先了解以下其他的发布方式

蓝绿部署

说明：所谓蓝绿部署，是指同时运行两个版本的应用，如上图所示，蓝绿部署的时候，并不停止掉老版本，而是直接部署一套新版本，等新版本运行起来后，再将流量切换到新版本上。但是蓝绿部署要求在升级过程中，同时运行两套程序，对硬件的要求就是日常所需的二倍，比如日常运行时，需要10台服务器支撑业务，那么使用蓝绿部署，你就需要购置二十台服务器。

优点

• 同一时间对外服务的只有一个版本，容易定位问题
• 升级和回滚操作相对简单

缺点

• 需要部署两套机器，资源消耗大
• 如果新版本有问题 则对客户有较大影响
  

滚动发布

说明：所谓滚动升级，就是在升级过程中，并不一下子启动所有新版本，是先启动一台新版本，再停止一台老版本，然后再启动一台新版本，再停止一台老版本，直到升级完成，这样的话，如果日常需要10台服务器，那么升级过程中也就只需要11台就行了。

但是滚动升级有一个问题，在开始滚动升级后，流量会直接流向已经启动起来的新版本，但是这个时候，新版本是不一定可用的，比如需要进一步的测试才能确认。那么在滚动升级期间，整个系统就处于非常不稳定的状态，如果发现了问题，也比较难以确定是新版本还是老版本造成的问题。

为了解决这个问题，我们需要为滚动升级实现流量控制能力。

优点

• 不需要两套机器资源，成本较低
• 非全量发布，所以对客户影响较小

缺点

• 同时两个版本提供服务，定位问题困难，容易造成数据不一致的问题
• 系统自动扩容的，要考虑代码版本问题

灰度发布

说明：灰度发布也叫金丝雀发布，起源是，矿井工人发现，金丝雀对瓦斯气体很敏感，矿工会在下井之前，先放一只金丝雀到井中，如果金丝雀不叫了，就代表瓦斯浓度高。

在灰度发布开始后，先启动一个新版本应用，但是并不直接将流量切过来，而是测试人员对新版本进行线上测试，启动的这个新版本应用，就是我们的金丝雀。如果没有问题，那么可以将少量的用户流量导入到新版本上，然后再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比，就是所谓的A/B测试。

当确认新版本运行良好后，再逐步将更多的流量导入到新版本上，在此期间，还可以不断地调整新旧两个版本的运行的服务器副本数量，以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。

如果在灰度发布过程中（灰度期）发现了新版本有问题，就应该立即将流量切回老版本上，这样，就会将负面影响控制在最小范围内。

优点

• 保证整体系统稳定性，在初始灰度的时候就可以发现、调整问题，影响范围可控
• 新功能逐步评估性能，稳定性和健康状况，如果出问题影响范围很小，相对用户体验也少

缺点

• 自动化要求较高
• 新旧代码版本不一致 要考虑数据问题

分流策略

• 针对用户级别分流。比如先部署给内部用户，在逐渐根据外部用户的分类等级扩散。

• 地域、IP 级别分流。只部署新版本到某地理地域，慢慢扩大到全量发布。

• 应用程序中判断特性分流。比如通过什么渠道使用服务的、浏览器特征分析、某个使用触发才使用新版本。

目前v7 k8s部署方式

滚动发布

滚动升级是默认的更新策略,它在删除一部分旧版本Pod资源的同时,补充创建一部分 新版本的Pod对象进行应用升级,其优势是升级期间,容器中应用提供的服务不会中断，但要求应用程序能够应对新旧版本同时工作的情形,例如新旧版本兼容同一个 数据库方案等.不过更新操作期间,不同客户端得到的响应内容可能会来自不同版本的应用

Deployment控制器的滚动更新操作并非在同一个ReplicaSet控制器对象下删除并创建Pod资源,而是将它们分置于两个不同的控制器之下：旧控制器的Pod对象数量不断减少的同时,新控制器的Pod对象数量不断增加,直到旧控制器不再拥有Pod对象

详细的滚动发布流程

1. 更换deployment配置文件，比如更换镜像
2. k8s根据配置规则，在保证最大不可用数的情况下，先创建新的，再删除旧的pod
3. 一次轮替，完成pod的更新

k8s滚动发布的问题和解决方案

k8s中文社区解答