正文

Argo Rollouts 通过整合 Analysis 功能，实现了基于实时数据分析的渐进式发布，从而显著提升了部署过程的稳定性和可控性，这是现代云原生交付方法的一个重要进步。

为什么需要 Analysis 驱动的发布？

传统的部署方式，比如一次性替换所有旧版本，风险很高。如果新版本有问题，会影响所有用户。渐进式发布，比如先给一小部分用户使用新版本，慢慢扩大范围，可以降低风险。但问题是怎么判断新版本是否健康？手动检查很慢，也容易出错。Argo Rollouts 的 Analysis 功能就是为了解决这个问题。它允许你在发布过程中自动收集和分析指标，比如应用的错误率、响应时间等。如果指标正常，就继续发布；如果指标变差，就自动回滚到旧版本。这样发布就变得更安全、更自动化。

如何设置一个简单的 Analysis 步骤？

假设你已经在使用 Kubernetes 和 Argo Rollouts 来管理应用。你想要在发布新版本时检查错误率。首先，你需要在 Rollout 的配置文件中添加一个分析步骤。下面是一个简化的例子，展示了如何定义一个分析模板，该模板会查询 Prometheus（一个常用的监控工具）来获取错误率。

你创建一个 AnalysisTemplate 资源，定义要查询的指标。例如，你可以设置一个查询，计算 HTTP 请求的错误率。然后，在 Rollout 配置中，你添加一个步骤，在发布过程中暂停，并运行这个分析。你可以设置条件，比如错误率超过 1% 就认为失败。这样，在发布时，Argo Rollouts 会自动执行这个分析。如果分析通过（错误率低于 1%），就继续下一步；如果失败，就自动回滚。这不需要你手动干预，整个过程是自动的。

实际应用中的经验分享

在实际使用中，有几点经验可以参考。首先，开始时要选择关键的指标。不要一开始就分析太多指标，那样可能会让分析变得复杂，容易误报。可以从一两个核心指标开始，比如错误率或延迟。其次，设置合理的阈值。阈值太严格，可能导致正常的发布也失败；太宽松，又起不到保护作用。你可以根据历史数据来设定。例如，观察旧版本的平均错误率，然后设置新版本允许的稍微高一点的阈值。另外，分析步骤可以放在发布的不同阶段。比如，在最初给 10% 流量时运行一次分析，如果通过，再提升到 50% 流量时再运行一次。这样可以在不同负载下检查应用的稳定性。

FAQ

问：Argo Rollouts 的 Analysis 功能支持哪些数据源？
答：它支持多种数据源，包括常见的监控系统如 Prometheus、Datadog、New Relic，也支持通过 HTTP 请求获取自定义指标。这让你可以根据自己的监控环境灵活配置。

问：如果分析失败，发布一定会自动回滚吗？
答：不一定，这取决于你的配置。你可以在分析步骤中设置失败策略。通常，你可以配置为自动回滚，也可以设置为手动干预，或者仅仅是暂停发布等待检查。建议在生产环境中设置为自动回滚，以快速响应问题。

问：Analysis 会影响发布速度吗？
答：会，因为分析需要时间收集数据。但它提升了安全性。你可以在速度和安全性之间平衡。例如，设置较短的分析间隔，或者只在关键阶段进行分析。对于不重要的更新，可以跳过分析；对于核心服务，则推荐使用。

引用来源

本文内容基于 Argo Rollouts 官方文档（https://argoproj.github.io/argo-rollouts/）中的概念和示例，特别是关于 Analysis 和渐进式交付的部分，并结合了实际使用经验进行阐述。