云原生下的灰度体系建设

• 方案 TechReview

• 组件上线变更会审

• 组件研发阶段

• 标准化组件研发流程

• 组件发布变更阶段

• 提供组件工作台能力进行组件的规模化管理

• 建设 ASI 元数据，细化灰度单元

• 建设 ASI 单集群、跨集群的灰度能力

灰度体系建设

===========================================================================

1. 研发流程标准化

---

ASI 核心组件的研发流程可以总结为以下几个流程：

针对 ASI 自身的核心组件，我们与质量技术团队的同学共同建设了 ASI 组件的 e2e 测试流程。除了组件自身的单元测试、集成测试外，我们单独搭建了单独的 e2e 集群，用作常态化进行的 ASI 整体的功能性验证和 e2e 测试。

从单个组件视角入手，每个组件的新功能经过研发后，进行 Code Review 通过并合入 develop 分支，则立即触发进行 e2e 流程，通过 chorus（云原生测试平台） 系统构建镜像后，由 ASIOps（ASI 运维管控平台） 部署到对应的 e2e 集群，执行标准的 Kubernetes Conformance 套件测试任务，验证 Kubernetes 范围内的功能是否正常。仅当所有测试 case 通过，该组件的版本才可标记为可推平版本，否则后续的发布将会受到管控限制。

然而正如上文提到，Kubernetes 开放的架构意味着它不仅仅包含管控、调度等核心组件，集群的功能还很大程度依赖于上层的 operator 来共同实现。因此 Kubernetes 范围内的白盒测试并不能覆盖所有的 ASI 的适用场景。底层组件功能的改变很有大程度会影响到上层 operator 的使用，因此我们在白盒 Conformance 的基础上增加了黑盒测试用例，它包含对各类 operator 自身的功能验证，例如从上层 paas 发起的扩缩容，校验发布链路的 quota 验证等能力，常态化运行在集群中。

2. 组件规模化管理

---

针对 ASI 组件多、集群多的特点，我们在原有 asi-deploy 功能之上进行拓展，以组件为切入点，增强组件在多集群间的管理能力，从镜像管理演进成了YAML 管理。

基于 Helm Template 的能力，我们将一个组件的 YAML 抽离成模板、镜像和配置三部分，分别表示以下几部分信息：

• 模板：YAML 中在所有环境固定不变的信息，例如 apiVersion，kind 等；

• 镜像：YAML 中与组件镜像相关的信息，期望在单一环境或者所有集群中保持一致的信息；

• 配置：YAML 中与单环境、单集群绑定的信息，允许存在多样化的内容，不同集群中的配置可能不同；

因此，一个完整的 YAML 则由模板、镜像和配置共同渲染而成。而 ASIOps 则再会对镜像信息和配置信息这部分 YAML 分别进行集群维度和时间维度（多版本）进行管理，计算组件当前版本信息在众多集群众多分布状况以及组件在单集群中版本的一致性状况。

针对镜像版本，我们从系统上促使其版本统一，以保证不会因版本过低而导致线上问题；而针对配置版本，我们则从管理上简化它的复杂性，防止配置错误发入集群。