在RTL中镜像金丝雀部署?

时间:2020-10-14 13:55:33

标签: testing istio canary-deployment

我是不熟悉Canary部署的。我们将开始通过Istio进行金丝雀部署。

我以为这只是一种部署机制,可能是在pro-prod环境中进行了一些Istio路由测试,但是在较早的测试环境中,我们会像今天一样对要测试的版本进行隔离。

建议将canary概念应用于所有测试环境,以便我们有效地运行我们希望在Route to Live中进行产品中的canary测试的所有版本。

想知道别人正在采取什么方法?

1 个答案:

答案 0 :(得分:1)

镜像

如上所述here

使用Istio,您可以使用流量镜像将流量复制到另一个服务。您可以将流量镜像规则纳入金丝雀部署管道的一部分,从而可以在向其发送实时流量之前分析服务的行为。

如果您正在寻找最佳实践,我建议从中等水平开始使用此tutorial,因为这里对此有很好的解释。

流量镜像的工作原理

流量镜像按以下步骤工作:

  • 您部署该应用程序的新版本并打开流量 镜像。

  • 旧版本像以前一样响应请求,但还会向新版本发送异步副本。

  • 新版本处理流量,但不响应用户。

  • 操作团队将监视新版本,并向开发团队报告所有问题。

enter image description here

当应用程序处理实时流量时,它可以帮助团队发现在生产前环境中通常不会发现的问题。您可以使用Prometheus和Grafana等监视工具来记录和监视测试结果。

此外,还有一个有关nginx的示例,完美地展示了它应该如何工作。


金丝雀部署

如上所述here

Istio项目的好处之一是,它提供了部署金丝雀服务所需的控制。金丝雀部署(或推出)背后的想法是引入一种新版本的服务,方法是首先使用一小部分用户流量对其进行测试,然后,如果一切顺利,则在逐步淘汰该百分比的同时逐步增加(可能会逐步增加)旧版本。如果在此过程中出现任何问题,我们将中止并回滚到以前的版本。以最简单的形式,发送到canary版本的流量是随机选择的请求百分比,但在更复杂的方案中,流量可以基于请求的区域,用户或其他属性。

根据您在该领域的专业水平,您可能想知道为什么还需要Istio对Canary部署的支持,因为Kubernetes等平台已经提供了进行版本发布和Canary部署的方法。问题解决了吧?好吧,不完全是。尽管以这种方式进行推广在简单的情况下是可行的,但它非常有限,尤其是在需要大量(特别是数量不同)流量且需要自动扩展的大规模云环境中。

There是k8s金丝雀部署和istio canary部署之间的区别。

k8s

举个例子,假设我们有一个已部署的服务helloworld版本v1,我们想测试(或简单地推出)新版本v2。使用Kubernetes,您可以通过简单地更新服务对应的Deployment中的映像并自动进行部署来推出helloworld服务的新版本。如果我们特别注意确保启动时有足够多的v1副本正在运行,并且在仅启动一个或两个v2副本之后暂停发布,则可以使Canary对系统的影响很小。然后,我们可以在决定继续进行之前进行观察,或者在必要时进行回滚。最好的是,我们甚至可以在Deployment上附加一个水平Pod自动缩放器,如果在发布过程中还需要放大或缩小副本以处理流量负载,它可以使副本比率保持一致。

尽管可以做到这一点,但这种方法仅在我们具有要部署的经过适当测试的版本时才有用,例如,更多的是蓝色/绿色,又名红色/黑色的升级,而不是“浸入”脚在水中”的金丝雀部署。实际上,对于后者(例如,测试可能甚至还没有准备好或无法用于更广泛曝光的Canary版本),将使用两个带有公共Pod标签的部署来完成Kubernetes中的Canary部署。在这种情况下,我们不能再使用自动缩放,因为它现在是由两个独立的自动缩放器完成的,每个部署一个。因此,复制比率(百分比)可能与所需比率有所不同,完全取决于负载。

我们是使用一两个部署,还是使用容器编排平台(例如Docker,Mesos / Marathon或Kubernetes)的部署功能进行金丝雀管理,这是一个根本性的问题:使用实例扩展来管理流量;流量版本分发和副本部署在这些系统中不是独立的。在kube-proxy循环池中,所有副本Pod(无论版本如何)都被视为相同,因此,管理特定版本接收的流量的唯一方法是控制副本比率。将金丝雀流量保持在很小的百分比就需要许多副本(例如,如果1%至少需要100个副本)。即使我们忽略了这个问题,部署方法仍然非常有限,因为它仅支持简单(随机百分比)canary方法。相反,如果我们希望基于某些特定条件将金丝雀的可见性限制为请求,我们仍然需要另一种解决方案。

istio

使用Istio,流量路由和副本部署是两个完全独立的功能。实施服务的Pod数量可以根据流量负载自由扩展和缩小,完全与版本流量路由的控制正交。这使得在存在自动缩放比例的情况下管理金丝雀版本变得简单得多。实际上,自动定标器可以响应因流量路由更改而导致的负载变化,但是它们仍独立运行,与负载因其他原因而变化时没有什么不同。

Istio的路由规则还具有其他重要优势;您可以轻松控制细粒度的流量百分比(例如,将流量的1%路由而不需要100个Pod),并且可以使用其他条件控制流量(例如,将特定用户的流量路由到canary版本)。为了说明这一点,让我们看一下部署helloworld服务,看看问题变得多么简单。

There是一个示例。


您可能还需要检查有关istio中流量镜像的其他资源: