在RTL中镜像金丝雀部署？

如何解决在RTL中镜像金丝雀部署？

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

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

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

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

解决方法

镜像

如上所述here

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

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

流量镜像的工作原理

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

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

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

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

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

当应用程序处理实时流量时，它可以帮助团队发现在生产前环境中通常不会发现的问题。您可以使用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中流量镜像的其他资源：