argo airflow_Kubernetes中的实际金丝雀发布以及Argo推出

argo airflow

At Soluto, our microservices-based infrastructure, combined with all the CI/CD tools, allow us to move fast with multiple releases a day to deliver features and fixes to our customers.

在Soluto，我们基于微服务的基础架构与所有CI / CD工具相结合，使我们每天可以快速移动多个版本，以向客户提供功能和修复。

In this storm of releases, sometimes issues are found in production, after the release. When this happens, we want to protect our customers from being exposed to these issues and at the same time, we want to know about them early on. This is where Argo Rollouts comes into the picture, with its support for canary release strategies.

在这种发行风暴中，发行后有时会在生产中发现问题。 发生这种情况时，我们希望保护我们的客户免受这些问题的困扰，同时，我们希望尽早了解这些问题。 这是Argo Rollouts出现的地方，它支持金丝雀释放策略。

免责声明 (Disclaimer)

There are a lot of guides out there for setting up a canary release process in your K8s cluster, and this post is not a “how to” — it assumes you know how Argo Rollouts works, it’s about choices, issues you might face, and optimizations you will need in order to make your canary release process efficient. You can read the whole thing for better understanding or you can skip to the summary and lessons learned sections for a quick read.

有很多指南可以在您的K8s集群中设置金丝雀释放过程，而这篇文章不是“如何”的，它假设您知道Argo Rollouts的工作原理，它涉及选择，您可能面临的问题以及为了使金丝雀释放过程高效，您将需要进行优化。 您可以阅读全文以更好地理解，也可以跳到摘要和经验教训部分以快速阅读。

我们想从金丝雀发布中得到什么？ (What did we want from canary releases?)

Our mission when we decided to implement canary was:

当我们决定实施金丝雀时，我们的任务是：

“On each new deployment, keep the old version running and give time for the new version to prove it works in production with minimum exposure to customers”

“在每个新的部署中，保持旧版本运行，并留出时间让新版本证明它可以在生产中工作，并且对客户的影响最小”

This means that we have to:

这意味着我们必须：

• Run two versions of the service at the same time in the production K8s cluster
  在生产K8s集群中同时运行两个版本的服务
• Split production traffic between the two versions in a controlled manner
  以受控方式在两个版本之间分配生产流量
• Automatically analyse how well the new version is performing
  自动分析新版本的执行情况
• Automatically replace versions or rollback based on the result of the analysis
  根据分析结果自动替换版本或回滚

Argo推广 (Argo Rollouts)

There are solutions out there for doing canary releases like flagger (which is planned to merge with Argo rollouts, yay!) but our choice was Argo because:

有一些解决方案可以进行诸如canner的金丝雀发布( 计划与Argo推出合并 ，是的！)，但是我们选择Argo是因为：

• Traffic splitting support without using a mesh provider for internal traffic that doesn’t go through Ingress
  流量拆分支持，无需使用网状网络提供程序来处理不通过Ingress的内部流量
• We had Argo CD and it easily integrates with it (more on that later)
  我们有Argo CD，它很容易与它集成(稍后会详细介绍)

Meaning if you don’t have a mesh provider (Istio), Argo Rollouts splits traffic between versions by creating a new replica set that uses the same service object, and the service will still split the traffic evenly across pods (new and old). In other words, controlling t