kubernetes中Istio实现金丝雀发布原理是什么

这期内容当中小编将会给大家带来有关kubernetes中Istio实现金丝雀发布原理是什么，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。

目前创新互联已为上千的企业提供了网站建设、域名、虚拟空间、绵阳服务器托管、企业网站设计、凉城网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。

一：简介

    互联网产品用户数量庞大，如果采用全量发布的话不论对于开发运维团队有着未知的风险，而且产品以及运营团队也同样面临的用户体验的巨大挑战。

二：藍綠发布

   在发布的过程中用户无感知服务的重启，通常情况下是通过新旧版本并存的方式实现，也就是说在发布的流程中，新的版本和旧的版本是相互热备的，通过切换路由权重的方式（非0即100）实现不同的应用的上线或者下线.

  发布流程：

(1) 部署版本1的应用（一开始的状态），所有外部请求的流量都打到这个版本上。

(2) 部署版本2的应用，版本2的代码与版本1不同(新功能、Bug修复等)。

(3) 将流量从版本1切换到版本2。

(4) 如版本2测试正常，就删除版本1正在使用的资源（例如实例），从此正式用版本2。

三：滚动发布

滚动发布，一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。这种部署方式相对于蓝绿部署，更加节约资源——它不需要运行两个集群、两倍的实例数。我们可以部分部署，例如每次只取出集群的百分之二十进行升级。

这种方式也有很多缺点，例如：

(1) 没有一个确定OK的环境。使用藍綠部署，我们能够清晰地知道老版本是OK的，而使用滚动发布，我们无法确定。

(2) 修改了现有的环境。

(3) 如果需要回滚，很困难。举个例子，在某一次发布中，我们需要更新100个实例，每次更新10个实例，每次部署需要5分钟。当滚动发布到第80个实例时，发现了问题，需要回滚。

(4) 有的时候，我们还可能对系统进行动态伸缩，如果部署期间，系统自动扩容/缩容了，我们还需判断到底哪个节点使用的是哪个代码。尽管有一些自动化的运维工具，但是依然令人心惊胆战。

并不是说滚动发布不好，滚动发布也有它非常合适的场景。

四：金丝雀发布

金絲雀发布是指在黑与白之间，能够平滑过渡的一种发布方式。金絲雀发布是增量发布的一种类型，金絲雀发布是在原有版本可用的情况下，同时部署一个新版本应用作为“金丝雀”，测试新版本的性能和表现，以保障整体系统稳定的情况下，尽早发现、调整问题。

  金丝雀发布由以下几个步骤组成：

(1)准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。

(2)从负载均衡列表中移除掉“金丝雀”服务器。

(3)升级“金丝雀”应用（排掉原有流量并进行部署）。

(4)对应用进行自动化测试。

(5)将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。

(6)如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）

金絲雀可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

金丝雀部署适用的场景：

(1)不停止老版本，额外搞一套新版本，不同版本应用共存。

(2)灰度发布中，常常按照用户设置路由权重，例如百分之九十的用户维持使用老版本，百分之十的用户尝鲜新版本。

(3)经常与A/B测试一起使用，用于测试选择多种方案。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来

五：Istio实现金丝雀发布原理

金丝雀发布的流程如下：

(1)准备和生产环境隔离的“金丝雀”服务器。

(2)将新版本的服务部署到“金丝雀”服务器上。

(3)对“金丝雀”服务器上的服务进行自动化和人工测试。

(4)测试通过后，将“金丝雀”服务器连接到生产环境，将少量生产流量导入到“金丝雀”服务器中。

(5)如果在线测试出现问题，则通过把生产流量从“金丝雀”服务器中重新路由到老版本的服务的方式进行回退，修复问题后重新进行发布。

(6)如果在线测试顺利，则逐渐把生产流量按一定策略逐渐导入到新版本服务器中。

(7)待新版本服务稳定运行后，删除老版本服务。

从上面的流程可以看到，如果要实现一套金絲雀發佈的流程，需要应用程序和运维流程对该发布过程进行支持，工作量和难度的挑战是非常大的。虽然面对的问题类似，但每个企业或组织一般采用不同的私有化实现方案来进行灰度发布,为解决该问题导致研发和运维花费了大量的成本。

Istio通过高度的抽象和良好的设计采用一致的方式解决了该问题，采用sidecar对应用流量进行了转发，通过Pilot下发路由规则，可以在不修改应用程序的前提下实现应用的灰度发布。

备注：采用kubernetes的滚动升级(rolling UPDATE)功能也可以实现不中断业务的应用升级,但滚动升级是通过逐渐使用新版本的服务来替换老版本服务的方式对应用进行升级，在滚动升级不能对应用的流量分发进行控制，因此无法采用受控地把生产流量逐渐导流到新版本服务中，也就无法控制服务升级对用户造成的影响。

采用Istio后，可以通过定制路由规则将特定的流量（如指定特征的用户）导入新版本服务中，在生产环境下进行测试，同时通过渐进受控地导入生产流量，可以最小化升级中出现的故障对用户的影响。并且在同时存在新老版本服务时，还可根据应用压力对不同版本的服务进行独立的缩扩容，非常灵活。

采用Istio进行金絲雀发布的流程如下图所示：

1.部署Reviews-V1,所有的流量指向V1

2.部署Reviews-V2

3.通过采用Istio的路由规则，将部分流量导入V2 (如百分之十)

4.逐步增加流量配置

5.流量全部切换到V2,删除V1

上述就是小编为大家分享的kubernetes中Istio实现金丝雀发布原理是什么了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注创新互联行业资讯频道。