我是金丝雀部署的新手。我们将开始通过 Istio 进行金丝雀部署。
我假设这只是一种部署机制,可能会在预生产环境中进行一些 Istio 路由测试,但在早期的测试环境中,我们会像今天一样对正在测试的版本进行隔离。
有人建议将金丝雀概念应用于所有测试环境,因此我们可以在 Route To Live 中有效地运行我们希望在 prod 中进行金丝雀测试的所有版本。
想知道其他人正在采取什么方法?
我是金丝雀部署的新手。我们将开始通过 Istio 进行金丝雀部署。
我假设这只是一种部署机制,可能会在预生产环境中进行一些 Istio 路由测试,但在早期的测试环境中,我们会像今天一样对正在测试的版本进行隔离。
有人建议将金丝雀概念应用于所有测试环境,因此我们可以在 Route To Live 中有效地运行我们希望在 prod 中进行金丝雀测试的所有版本。
想知道其他人正在采取什么方法?
正如这里提到的
使用 Istio,您可以使用流量镜像将流量复制到另一个服务。您可以将流量镜像规则合并为 Canary 部署管道的一部分,允许您在向其发送实时流量之前分析服务的行为。
如果您正在寻找最佳实践,我建议您从本教程开始,因为它在这里得到了很好的解释。
流量镜像使用以下步骤工作:
您部署新版本的应用程序并打开流量镜像。
旧版本像以前一样响应请求,但也会向新版本发送异步副本。
新版本处理流量但不响应用户。
运营团队监控新版本并向开发团队报告任何问题。
当应用程序处理实时流量时,它可以帮助团队发现他们在预生产环境中通常不会发现的问题。您可以使用 Prometheus 和 Grafana 等监控工具来记录和监控您的测试结果。
此外,还有一个 nginx 示例完美地展示了它应该如何工作。
正如这里提到的
Istio 项目的好处之一是它提供了部署金丝雀服务所需的控制。金丝雀部署(或推出)背后的想法是通过首先使用一小部分用户流量对其进行测试来引入新版本的服务,然后如果一切顺利,可能会逐渐增加百分比,同时逐步淘汰旧版本。如果在此过程中出现任何问题,我们将中止并回滚到以前的版本。在最简单的形式中,发送到金丝雀版本的流量是随机选择的请求百分比,但在更复杂的方案中,它可以基于请求的区域、用户或其他属性。
根据您在该领域的专业水平,您可能想知道为什么甚至需要 Istio 对金丝雀部署的支持,因为像 Kubernetes 这样的平台已经提供了一种进行版本发布和金丝雀部署的方法。问题解决了,对吧?嗯,不完全是。尽管以这种方式进行部署在简单的情况下有效,但它非常有限,尤其是在接收大量(尤其是变化量)流量的大型云环境中,需要自动缩放。
k8s
例如,假设我们有一个已部署的服务 helloworld 版本 v1,我们想为其测试(或简单地推出)一个新版本 v2。使用 Kubernetes,您可以推出新版本的 helloworld 服务,只需更新服务相应 Deployment 中的映像并让推出自动进行。如果我们特别注意确保在启动时有足够的 v1 副本在运行,并在仅启动一两个 v2 副本后暂停 rollout,我们可以将金丝雀对系统的影响保持在非常小的范围内。然后,我们可以在决定继续进行或必要时回滚之前观察效果。最重要的是,我们甚至可以将水平 pod 自动缩放器附加到 Deployment,如果在推出过程中,它会保持副本比率一致,
虽然它的作用很好,但这种方法只有在我们想要部署一个经过适当测试的版本时才有用,也就是说,更多的是蓝/绿,也就是红/黑,一种升级,而不是“把你的脚浸入水”的金丝雀部署。事实上,对于后者(例如,测试一个甚至可能还没有准备好或打算进行更广泛曝光的金丝雀版本),Kubernetes 中的金丝雀部署将使用两个具有公共 pod 标签的部署来完成。在这种情况下,我们不能再使用自动缩放,因为它现在由两个独立的自动缩放器完成,每个部署一个,因此副本比率(百分比)可能与所需的比率不同,这完全取决于负载。
无论我们使用一个部署还是两个部署,使用 Docker、Mesos/Marathon 或 Kubernetes 等容器编排平台的部署特性进行金丝雀管理都有一个根本问题:使用实例扩展来管理流量;流量版本分发和副本部署在这些系统中并不独立。所有副本 pod,无论版本如何,在 kube-proxy 循环池中都被同等对待,因此管理特定版本接收的流量的唯一方法是控制副本比率。维持小百分比的金丝雀流量需要许多副本(例如,1% 将需要至少 100 个副本)。即使我们忽略这个问题,部署方法仍然非常有限,因为它只支持简单(随机百分比)金丝雀方法。如果相反,
istio
使用 Istio,流量路由和副本部署是两个完全独立的功能。实现服务的 Pod 数量可以根据流量负载自由伸缩,与版本流量路由的控制完全正交。这使得在存在自动缩放的情况下管理金丝雀版本成为一个更简单的问题。事实上,自动缩放器可能会响应流量路由变化导致的负载变化,但它们仍然独立运行,与负载因其他原因发生变化时没有什么不同。
Istio 的路由规则还提供其他重要优势;您可以轻松控制细粒度的流量百分比(例如,路由 1% 的流量而不需要 100 个 Pod),并且您可以使用其他标准控制流量(例如,将特定用户的流量路由到金丝雀版本)。为了说明这一点,让我们看一下部署 helloworld 服务,看看问题变得多么简单。
有一个例子。
您可能需要查看有关 istio 中流量镜像的其他资源: