Kubernetes 中的渐进式交付：分析

每日分享最新，最流行的软件开发知识与最新行业趋势，希望大家能够一键三连，多多支持，跪求关注，点赞，留言。
将对云原生环境中的渐进式交付选项进行分析，以探索如何在 Kubernetes 环境中添加此增强功能。

原生的 Kubernetes Deployment Objects 支持 Rolling Update 策略，在更新时提供了基本的保证，同时也有限制：

1. 对推出速度的控制很少。
2. 无法控制流向新版本的流量。
3. 就绪探测不适用于更深入、压力大或一次性的检查。
4. 无法检查外部指标来验证更新。
5. 无法自动中止和回滚更新。

由于上述原因，在复杂的生产环境中，此滚动更新可能存在风险，因为它不提供对爆炸半径的控制，可能过于激进地推出，并且在出现故障时没有回滚自动化。

要求

尽管有多种工具可以提供多种部署功能，但最低要求是：

1. GitOps 方法：选择的工具应该在 GitOps 方法下工作；无需手动更改。
2. NGINX Ingress Controller 兼容性：目标是添加更多部署选择，而不是研究不同的 Kubernetes Ingress Controller。
3. Prometheus分析兼容性：指标保存在Prometheus上；该工具应该允许使用 Prometheus 查询来执行测量。
4. 与多个服务网格选项兼容：所选工具不应绑定到特定服务网格。这将使我们能够在未来试验多个服务网格。
5. GUI：拥有它会很有价值，但至少需要某种与替代部署中幕后发生的事情相关的部署跟踪。

1. Kubernetes 部署方法。
2. 来自 Teams 的应用程序交付策略。

本机 Kubernetes 部署对象：

1. 滚动更新：滚动更新慢慢地用新版本替换旧版本。这是 Deployment 对象的默认策略。
2. 重新创建：在启动新版本之前删除旧版本的应用程序。这确保了应用程序的两个版本永远不会同时运行，但在部署期间会出现停机时间。

理想的目标是为当前的 Kubernetes 集群添加额外的部署功能，从而通过降低部署新版本时出现中断的风险来提高应用程序团队的敏捷性和信心。

主要好处是：

1. 更安全的发布：通过逐渐将流量转移到新版本，同时测量请求成功率和延迟等指标，降低在生产中引入新软件版本的风险。
2. 灵活的流量路由：在应用程序版本之间转移和路由流量，可以使用服务网格（Linkerd、Istio、Kuma...）或不使用（Contour、NGINX、Traefik...）。
3. 可扩展验证：使用自定义指标和 webhook 扩展应用程序分析以进行验收测试、负载测试或任何其他自定义验证。
4. 渐进式交付：替代部署策略：
5. 金丝雀（渐进式流量转移）
6. A/B 测试（HTTP 标头和 cookie 流量路由）：Argo Rollouts 称为实验，尽管 Canaries 也可以有特定的标头。
7. 蓝/绿（流量切换和镜像）

它同时部署了应用程序的新旧版本。在此期间，只有旧版本的应用程序会收到生产流量。这允许开发人员在将实时流量切换到新版本之前针对新版本运行测试。

金丝雀部署将一部分用户暴露给新版本的应用程序，同时将其余流量提供给旧版本。新版本验证无误后，可以逐步替代旧版本。入口控制器和服务网格，例如 NGINX 和 Istio，为金丝雀发布提供了比原生可用的更复杂的流量整形模式（例如，实现非常细粒度的流量拆分或基于 HTTP 标头的拆分）。

上图显示了一个有两个阶段的金丝雀（25% 和 75% 的流量流向新版本），但这只是一个例子。Argo Rollouts 允许为每个用例定义多个阶段和流量百分比。

工具

这两个伟大的项目是 Argo Rollouts 和 Flagger。这两个项目都很成熟并被广泛使用。

Argo 推出

Argo Rollouts 是一个 Kubernetes 控制器和一组 CRD，它为 Kubernetes 提供高级部署功能，例如蓝/绿、金丝雀、金丝雀分析、实验和渐进式交付功能。部署了一个 UI 以查看不同的 Rollout。

两种推出方式：

1. 金丝雀
2. 蓝绿色

Argo Rollouts 提供的实验允许用户临时运行一个或多个 ReplicaSets 并沿着这些 ReplicaSets 运行 AnalysisRuns 以确认一切都按预期运行。实验的一些用例可能是：

1. 在特定持续时间内部署应用程序的两个版本以启用对应用程序的分析。
2. 通过长时间使用不同版本的应用程序启动多个实验，使用实验来启用 A/B/C 测试。
3. 启动具有不同标签的现有应用程序的新版本以避免从 Kubernetes 服务接收流量。用户可以在继续推出之前针对新版本运行测试。

A/B 测试可以使用 Argo Rollouts 实验进行。

有多种方法可以执行分析以推动渐进式交付。

1. AnalysisRuns 就像作业一样，它们最终都会完成；运行结果会影响 Rollout 的更新是继续、中止还是暂停。AnalysisRuns 接受模板化，使参数化分析变得容易。
2. AnalysisRuns 接受多个数据源，例如：
3. Prometheus，查询应用程序的指标以预测服务在部署期间是否性能下降。
4. Cloudwatch，查询 AWS 指标以检查部署期间是否一切正常
5. Web，执行 HTTP 请求并将其与 JSON 响应的结果进行比较。
6. 作业，执行自定义脚本以便成功/失败。

交通管理

1. NGINX 入口控制器
2. 服务网格接口（SMI）

可观察性

1. 格拉法纳仪表板

移民

1. Argo Rollouts 允许从 Rollout 引用 Deployment，而不是从头开始修改和创建新的 rollout 。这将减少迁移时的工作量。

痛点：

1. RBAC 和身份验证
2. 非原生集成：Argo Rollouts 使用自己的 CRD Rollout，而不是 Kubernetes 原生。

Flagger是 GitOps 工具的 Flux 系列的一部分。Flagger 与 Argo Rollouts 非常相似，其主要亮点是：

1. 本机集成：它监视部署资源，不需要使用 CRD 来处理它们。
2. 高度可扩展并附带电池：它提供了一个负载测试器来运行基本或复杂的场景。

创建部署时，Flagger 会生成应用程序的重复资源（包括配置映射和机密）。它使用 -primary 和主要部署的服务端点创建 Kubernetes 对象。

它采用与Argo Rollouts相同的关于 Canary、 Blue/Green和 A/B 测试的概念。

可观察性

1. 格拉法纳仪表板

痛点：

1. 没有 UI，因此不需要 RBAC 和身份验证，但要从推出的当前状态获得快速反馈很复杂。检查日志或检查金丝雀资源的状态是唯一的方法。
2. 没有 kubectl 插件来检查部署的进展情况；需要处理`kubectl logs -f flagger-controller`看kubectl如何描述Canary，以便查看进度。
3. 文档可能会更好。
4. Blue/Green 是经过改编的 Canary（与 Canary 相同，但权重为 100%）

Argo 推出

1. 如果在 Argo Rollouts Controller 关闭时有 Rollout 更改，控制器将接收最新的更改；它不会从推出的地方开始。
2. 如果在 Controller 关闭时没有新的提交，Controller 会自动协调状态。如果 Rollout 是在第三步中，而 Controller 已关闭，当它重新启动时，它将从同一位置拾取。

旗帜

1. 与 Argo Rollouts 一样，它协调得很好。
2. 不同的是，它是按照步骤来的，而不是先改后改，再改最新的。
3. 新的推出/部署将被阻止，但 pod 和 HPA 将保持正常运行，即使它在推出/部署的中间中断。两个控制器将在恢复后自动协调。

Argo 推出

1. 尽管我们没有 Deployment 资源，但来自 deployments 的指标不会消失。

旗帜

1. 部署资源在那里，因此预计不会发生任何变化。

Argo 推出

1. 它可以从 GUI 和 kubectl 命令行轻松完成；ArgoCD 将通知 RolloutAbort。
2. 可以从 GUI 或 kubectl 命令轻松重试；ArgoCD 将标记 Rollout 正在进行中。

旗帜

1. 似乎无法使用命令行暂停部署。需要部署 Flagger Tester API。

1. Argo Rollouts 与 ArgoCD 集成，从 ArgoCD UI 可以看到 Rollout 的进度。
2. Flagger 没有像 Argo Rollouts 那样与 ArgoCD 无缝集成，因此创建了一堆资源并在 ArgoCD UI 中可见，但没有反馈。

Argo 推出

1. Argo Rollouts 目前没有直接进行负载测试的方法，但作为一种解决方法，它可以与 webhooks 一起使用来启动 k6 负载测试，如他们项目中的本期所示。
2. 负载测试必须开箱即用；当 Canary 达到所需的步骤时，它会专门停止负载测试。

旗帜

1. 它通过 webhook 与 k6 loadtests 集成，并提供 flagger-loadtest 工具；可以在此处找到有关 webhook 的更多信息。

1. 在没有流量路由提供商的情况下，这两个选项都可以使用 NGINX 功能处理 Canary 权重。此外，这两个选项都可以处理 SMI 并提供与服务网格相关的广泛选择。然后，无论哪种工具最适合并且不是阻碍，都可以用来选择一个或另一个服务网格。

Argo 推出

1. Argo Rollouts 对此不提供支持，但 在他们的 Project 中有一个未解决的问题。
2. 应该采取一些解决方法，以便在仅 configMap 更改时能够进行推出和回滚。解决方法包括：
3. configMap 名称中的随机后缀。
4. ConfigMap 和 Deployment 定义在同一个.yaml中以避免创建多个随机后缀。

旗帜

1. 当 configMap 更改在部署事件中运行良好时，使用 Helm 注释技巧自动部署部署。但是，对于rollout后的回滚，可能会出现与Deployments和ConfigMaps一样的问题，因为只有一个configMap，而不是多个。这意味着回滚的解决方法必须以与 Argo Rollouts 相同的方式完成

这两种工具都将帮助我们获得替代部署，但每种工具都有一些权衡：

Argo 推出

优点

1. 很棒的用户界面，快速的反馈。
2. 与 ArgoCD 的良好集成和反馈，指示 Rollout 是否在进行中。
3. 与当前部署资源轻松集成。
4. 文档

缺点

1. 没有 RBAC 或 auth 的 UI。
2. 负载测试未集成；它必须使用 webhook 临时添加。
3. 非 Kubernetes 原生，由 CRD 添加的 Rollout 资源。

优点

1. Kubernetes native 没有引入新的 Kubernetes 资源。
2. 负载测试集成。

缺点

1. 没有用户界面；需要通过 K8s API 收集反馈。
2. 来自 ArgoCD 的零反馈；根据他们的文档，Flagger 与 Flux 集成得更好。
3. 文档可能会更好。
4. 与 Argo Rollouts 的主要区别。
5. 使用 kubectl 命令进行反馈。
6. Blue/Green 是经过改编的 Canary（与 Canary 相同，但经过一些测试后权重为 100%）。

1. 选择您的fighter，并根据您的应用调整策略。可能有些应用程序更适合蓝/绿方法，而其他应用程序更适合Canary方法。
2. 较低环境中的演示会话。
3. 使用 Teams 计划迁移。
4. 如果/当将服务网格添加到平台时，将来可以改进功能。