K8S的灰度发布、滚动更新、蓝绿发布

K8S灰度发布、蓝绿发布、滚动更新

一、简介

1.1灰度发布（金丝雀发布）

金丝雀发布一般是先发1台机器，或者一个小比例，例如2%的服务器，主要做流量验证用，也称为金丝雀 (Canary) 测试，国内常称灰度测试。以前矿工下矿前，会先放一只金丝雀进去用于探测洞里是否有有毒气体，看金丝雀能否活下来，金丝雀发布由此得名。

简单的金丝雀测试一般通过手工测试验证，复杂的金丝雀测试需要比较完善的监控基础设施配合，通过监控指标反馈，观察金丝雀的健康状况，作为后续发布或回退的依据。如果测试通过，则把剩余的 V1 版本全部升级为 V2 版本。如果金丝雀测试失败，则直接回退金丝雀，发布失败。

缺点： 自动化流程不够，发布期间需要人为去操作，可能会引起服务中断等。

1.2滚动更新

在金丝雀发布基础上的进一步优化改进，是一种自动化程度较高的发布方式，用户体验比较平滑，是目前成熟型技术组织所采用的主流发布方式。

一次滚动式发布一般由若干个发布批次组成，每批的数量一般是可以配置的（可以通过发布模板定义）。例如，第一批1台（金丝雀），第二批10%，第三批 50%，第四批100%。每个批次之间留观察间隔，通过手工验证或监控反馈确保没有问题再发下一批次，所以总体上滚动式发布过程是比较缓慢的 (其中金丝雀的时间一般会比后续批次更长，比如金丝雀10 分钟，后续间隔 2分钟)。

1.3蓝绿发布

一些应用程序只需要部署一个新版本，并需要立即切到这个版本。因此，我们需要执行蓝/绿部署。在进行蓝/绿部署时，应用程序的一个新副本（绿）将与现有版本（蓝）一起部署。然后更新应用程序的入口/路由器以切换到新版本（绿）。然后，您需要等待旧（蓝）版本来完成所有发送给它的请求，但是大多数情况下，应用程序的流量将一次更改为新版本；Kubernetes不支持内置的蓝/绿部署。

目前最好的方式是创建新的部署，然后更新应用程序的服务（如service）以指向新的部署；蓝绿部署是不停老版本，部署新版本然后进行测试，确认OK后将流量逐步切到新版本。蓝绿部署无需停机，并且风险较小。需要路由或者ingress的配合。

缺点: 切换是全量的，如果新版本有问题，则对用户体验有直接影响, 需要双倍机器资源。

二、思路原理

2.1.1名词解释

总体思路在于使用deployment的滚动更新控制。首先是要学会查看K8S提供的接口以及相应的接口解释。

 

如上图就是使用以下两个命令达到效果：
kubectl api-resources #展示K8S提供的接口资源

kubectl explain deployments.spec.strategy.rollingUpdate #查看K8S提供的接口资源的详细解释

具体解释如下：

type : Can be “Recreate” or “RollingUpdate”. Default is RollingUpdate.滚动发布

rollingUpdate: 仅在type为RollingUpdate时有效

rollingUpdate.maxSurge 最大可超期望的节点数，百分比 10% 或者绝对数值 5

rollingUpdate.maxUnavailable 最大不可用节点数，百分比或者绝对数值

这些接口实际上都是在yaml中可以实现调用，举例yaml如下：

apiVersion: apps/v1

kind: Deployment

metadata:

  name: rollingupdate

spec:

  strategy:

    rollingUpdate:

      maxSurge: 25%         #滚动升级时先启动的pod数量

      maxUnavailable: 25%   #滚动升级时允许的最大unavailable的pod数量

    type: RollingUpdate

  selector:

    matchLabels:

      app: rollingupdate