本文分享自华为云社区《Kurator V0.6.0：实现应用全流程生命周期管理》，作者：云容器大未来。
Kurator 是华为云开源的面向分布式云原生环境的一站式解决方案。它利用 Karmada 作为多集群编排基础，内置集成了Istio、Prometheus、Thanos、Volcano、KubeEdge、Argo 等主流云原生技术。基于此，Kurator 构建了包括集群舰队管理、集群生命周期管理、统一应用分发、流量治理、监控和策略管理在内的分布式云平台管理能力。
**在最新 0.6.0 版本中，Kurator 为云原生应用增加了 CI/CD 流水线设置与管理功能，简化流水线创建。此外，强化了 0.4.0 版本发布的统一应用分发功能，可以在部署新应用时设置金丝雀（灰度）发布、A/B 测试、蓝绿发布三种渐进式发布策略。**新增的流水线特性和渐进式发布功能与统一分发能力结合，实现基于代码仓库的 GitOps 工作流。这有助于快速构建分布式云原生平台，简化应用开发与发布流程。Kurator CI/CD 的结构图如下所示：
用户更新代码仓库后，触发 Kurator 流水线，完成代码拉取、检查、编译并构建镜像。其后，用户更新应用部署模板，例如更改应用配置中的镜像信息。Kurator Application Controller 侦测到配置更新，将自动触发已应用的渐进式发布策略，实现应用的自动发布。如此一来，整个软件研发生命周期以代码为中心，实现开发至发布完整流程的自动化，简化运维、部署工作。
流水线
CI/CD 流水线实现源码到发布的自动化过程，包括源码管理、检查、测试等阶段。但由于每个阶段技术需求不同，导致流水线配置和管理难度大。Kurator 参考开源项目 Tekton，通过预定义常用任务模版的方式简化流水线创建操作。用户只需指定任务名称和代码仓库访问凭证即可创建流水线，使用门槛低。对熟悉流水线的高级用户，Kurator 也支持自定义任务。用户可以根据自己需求定制任务内容，满足个性化场景。通过预置任务模板和自定义任务的能力，Kurator 大幅简化了流水线配置和管理的难度。
从图中可以看出，在使用流水线时，Kurator 完成了大部分工作。用户只需配置运行环境，选择任务模板即可完成流水线创建，大大减少学习成本。特别是与传统Tekton 相比，Kurator 提供了预定义任务模板，用户只关注任务内容而不再处理具体实现，实现了流水线使用的极致简化。
除了简化流水线的创建操作外，Kurator 还考虑到了软件供应链安全，可以在流水线构建镜像时自动为其添加数字签名和源头证明，以防范假冒镜像，保证镜像源头可靠，保证在镜像制作方面的安全性。软件供应链安全指的是保护软件从开发到部署的整个生命周期过程中的安全性。软件供应链安全可以提高软件安全性能和用户信任度，预防恶意代码渗透。签名和证明添加后，镜像将自动上传至仓库。在镜像仓库中可以直接查看镜像签名和证明的详细情况，如图所示。
用户可以用签名过程生成的公钥验证镜像签名和源头。这样在生产中,生产者仅需公布签名公钥，就能让用户验证数字签名和来源证明。接下来将展示一个在 Kurator 中创建一个流水线的示例：
在流水线定义 spec.tasks 中指定任务名称，即可选择 Kurator 内置的常用任务模板。目前内置的常用任务模板包括:
此外，通过 customTask 定义可以发布自定义任务。通过指定 image、command 和 args,实现定制任务需求，如上述示例中自定义任务完成的工作就是打印README.md。
更多的示例和细节，请参考: kurator.dev/docs/pipeli...
渐进式发布
金丝雀发布、A/B 测试和蓝绿发布都是主流的应用发布策略，可有效减少上线风险。Kurator 0.6.0 在原统一应用分发基础上，增加渐进式发布功能。现在应用可以指定三种渐进式发布策略中的一种策略。同时，可以将具备发布能力的统一分发，与 CI/CD 流水线结合起来，实现基于代码仓库的 GitOps 工作流。
金丝雀发布
金丝雀部署是一种渐进式发布策略。先向少数用户发布新的软件版本进行测试，根据测试结果，决定是否向更多用户推出新版本。旨在最大限度地减少新版本上线后对用户的影响，是一种更安全、更可靠的软件发布策略。参阅以下的操作示例，了解如何使用 Kurator 配置金丝雀发布。
通过配置 rollout 中的 workload 字段，可以将金丝雀发布的目标设置为 webapp 命名空间下名为 backend 的应用。发布目标除了支持 deployment 应用之外，还支持 daemonSet应用。流量分析使用 Kurator 内置的请求成功率（request-sueccess-rate）和平均访问时延（request-duration）两个指标作为衡量新版本是否健康的标准。其中通过 thresholdRange 指定阈值。示例中要求请求成功率达99% ，平均访问时延小于 500ms，新版本的服务才会被认定为健康。rolloutPolicy.canaryStrategy 配置了每次测试成功后，下次流量递增的比例和最终允许测试版本流量占比的最大值，从而实现渐进式发布新版本。示例中每次递增 10% 的流量流向新版本，最多为 50%。也可以设置 maxWeight 为 55，这样在最后一次测试的时候，只会新增 5% 的流量流向新版本。除了这些配置之外，Kurator 还可以设定完成验证之后，流量以什么样的比例逐步流向新版本。
更多细节请参考: kurator.dev/docs/fleet-...
A/B测试
A/B 测试为效果测试，是验证应用两版本表现的测试方法。它通过将用户分到不同组，每个组体验不同版本，然后分析每个组用户在使用过程中的各项指标，选择效果较好的版本。A/B 测试也可以先让部分用户试用新版本，收集真实环境下的用户反馈，再决定是否上线新版本。了解如何在 Kurator 配置应用的 A/B 测试，请参考下方操作示例。
和金丝雀发布类似，由 workload 指定 A/B 测试的目标。通过 metric 指定测试的指标。A/B 测试和金丝雀发布不同的点在于需要配置 match 中的匹配规则，实现流量分组。上述 match 配置是只有 http 请求头满足使用 FireFox 浏览器或请求的 cookie 中包含 "type=insider" 的情况下，请求才会被转发到新版本。通过对不同请求头的处理达到对用户分组的效果，对不同的版本进行效果测试。除了匹配请求头之外，还能匹配 URI、端口号等。
更多细节请参考: kurator.dev/docs/fleet-...
蓝绿发布
蓝绿发布是一种渐进零停机发布方法。它将生产环境分为两个独立运行的蓝绿环境,蓝环境承载当前实际流量，绿环境预部署新版本。新版本通过测试后,只需切换流量到绿环境，就能实现零停机升级。蓝环境备用支持回滚。通过实时扩容，可近乎零停机完成迭代交付，提高发布效率和用户体验。了解如何在 Kurator 配置蓝绿发布的操作示例，请参考下方。
蓝绿发布需要配置目标应用、测试指标、迭代次数和容许测试失败的次数，其中测试的迭代次数由 analysisTimes 指定，容许测试失败的次数由 checkFailedTimes指定，除此之外无需配置别的规则。因为蓝绿发布在测试新版本的时候是将全局流量转发到绿环境中进行测试，没有金丝雀发布的渐进式流量递增和 A/B 测试的对用户分组的需求。
更多细节请参: kurator.dev/docs/fleet-...
未来展望
综上所述，通过 CI/CD 流水线和渐进式发布功能，Kurator 实现了从源码到发布的完整流水线自动化，真正提升了开发效率和运维能力，实现开发、配置和发布的应用全流程生命周期管理。此外还大幅简化了采用 CI/CD 流水线和渐进式发布的门槛。随着 Kurator 的不断迭代升级，我们还将继续为流水线添加更多的预定义任务模板，为渐进式发布提供更多的测试指标。欢迎大家试用 Kurator 并提出宝贵的意见与需求。Kurator的门户为：github.com/kurator-dev...
随着功能的逐渐完善，Kurator 将成为用户快速立体掌握云原生技术体系、高效运行分布式应用的强大工具。
参考链接
Kurator项目地址：github.com/kurator-dev...
CI/CD流水线：kurator.dev/docs/pipeli...
软件供应链安全：kurator.dev/docs/pipeli...
渐进式发布：kurator.dev/docs/fleet-...
金丝雀发布：kurator.dev/docs/fleet-...
A/B测试：kurator.dev/docs/fleet-...