改善十年应用的部署体验( 二 ) 在2018年

虽然Kubernetes的架构和灵活的扩展意味着金丝雀发布是一个非常流行的部署解决方案，但是Etsy的搜索系统的设计意味着我们不能使用任何现成的金丝雀发布解决方案。我们必须为自己建造一些新的东西，一种金丝雀精简版。
在考虑重新构建整合金丝雀组件的部署流程时，存在两个关键的限制。
第一个限制是，我们不能使用单一的负载均衡器活API断电来控制流入流量的数量。这样，我们就不能使用Kubernetes标签在单个Kubernetes部署上为任何搜索服务做基本的金丝雀发布，因为Search是由许多不同的Kubernetes部署组成的。我们没有地方来设置路由逻辑来检查标签，以及相应的路由到金丝雀Pod 。
但是， Etsy的PHPWeb应用是搜索应用的唯一客户端。对于Etsy ，这是一种常见模式，因此，配置负载平衡通常是直接在Web应用本身中进行管理。任何新的部署解决方案或者必须对Web应用管理流量到web应用内部的Search ，或者实现某种全新的网状网络（比如Istio），捕获并引导Web应用到Search的所有流量。这两个方案在分配给该项目的时间范围内都不可行。
第二个限制是，搜索应用假定请求路径中所有搜索服务的相同版本都会为任何单一Web请求服务。所以，任何新解决方案的部署都需要确保所有搜索服务的旧版本都能满足正在进行的搜索请求。甚至像Istio这样复杂的金丝雀发布解决方案，也要求你的应用处理不同服务之间的版本不匹配，这是我们无法保证的。
那么，我们如何为所有新版本的搜索服务创建一个逐步推出的过程，同时管理从Web应用到滚动发布的所有部分的负载平衡，并保证搜索服务只能和其他搜索服务的相同版本对话？对于这种Etsy特定问题，没有现成的解决方案。因此我们开发了一种全新的工具，叫做Switchboard 。
走入Switchboard
Switchboard的主要功能是管理流量：它通过逐步增加提供给新的活动端的百分比，并按比例减少进入旧的活动端的数量，将一个部署滚动发布到生产。
具有预先定义的流量比例的部署阶段被硬编码到系统中，当在当前滚动发布阶段中添加的所有Pod都完全创建并正常运行时， Switchboard就会过渡到下一个阶段。这是通过编辑和提交新的流量比例到Web应用中的配置文件来实现这一目标的。 Web应用对每一个心情求都重新检查这个文件，并使用这些信息在两个不同的生产Kubernetes命名空间之间进行负载均衡搜索流量，这两个命名空间仍然被称为flip和flop 。

文章图片
使用Switchboard的一端开关的例子。 Smoke测试在16:57和17:07进行。
Switchboard在部署过程中很大程度上实现了流量从一个搜索端到另一个搜索端的自动迁移。 Smoke测试在部署的不同阶段运行，向新的一端发送人工创建的和真实的历史搜索查询请求。开发人员只需监控图表，以确保滚动发布的工作顺利进行。

文章图片
推动部署的工程师通过显示当前滚动发布状态的用户界面来管理Switchboard ，它还可以选择暂停或者回滚部署。
在Switchboard中，我们主要依靠Kubernetes内置的自动伸缩功能来扩展部署期间的新集群。在开始向集群发送生产流量之前，我们已经发现，我们只需要先将集群的规模扩大到我们当前容量的25% 。
Kubernetes内置的自动伸缩是被动的，因此与我们强制Search在需要额外容量之前进行伸缩相比，速度肯定要慢。这样，它可以帮助提前扩展新的活动端，从而在该端上线并开始接收流量时更快地响应初始转换。通过Switchboard ， Kubernetes可以管理自己的自动伸缩功能，只需监控Kubernetes的滚动发布，可以确保所有服务在当前阶段是健康的，然后再决定升级。