关于云原生:云原生下的灰度体系建设

作者 | 墨封
起源 | 阿里巴巴云原生公众号

一周前，咱们介绍了《面对大规模 K8s 集群，如何先于用户发现问题》。

本篇文章，咱们将持续为大家介绍 ASI SRE（ASI，Alibaba Serverless infrastructure，阿里巴巴针对云原生利用设计的对立基础设施）是如何摸索在 Kubernetes 体系下，建设 ASI 本身基础设施在大规模集群场景下的变更灰度能力的。

ASI 诞生于阿里巴巴团体全面上云之际，承载着团体大量基础设施全面云原生化的同时，本身的架构、状态也在一直地演进。

ASI 整体上次要采纳 Kube-on-Kube 的架构，底层保护了一个外围的 Kubernetes 元集群，并在该集群部署各个租户集群的 master 管控组件：apiserver、controller-manager、scheduler，以及 etcd。而在每个业务集群中，则部署着各类 controller、webhook 等 addon 组件，独特撑持 ASI 的各项能力。而在数据面组件层面，局部 ASI 组件以 DaemonSet 的模式部署在节点上，也有另一部分采纳 RPM 包的部署模式。

同时，ASI 承载了团体、售卖区场景下数百个集群，几十万的节点。即使在 ASI 建设初期，其管辖的节点也达到了数万的级别。在 ASI 本身架构疾速倒退的过程中，组件及线上变更相当频繁，晚期时单日 ASI 的组件变更能够达到数百次。而 ASI 的外围根底组件诸如 CNI 插件、CSI 插件、etcd、Pouch 等，无论任意之一的谬误变更都可能会引起整个集群级别的故障，造成下层业务不可挽回的损失。

简而言之，集群规模大、组件数量多，变更频繁以及业务状态简单是在 ASI，或其余 Kubernetes 基础设施层建设灰度能力和变更零碎的几大严厉挑战。过后在阿里巴巴外部，ASI/Sigma 已有数套现有的变更零碎，但都存在肯定的局限性。

天基：具备通用的节点公布的能力，但不包含集群、节点集等 ASI 的元数据信息。
UCP：晚期 sigma 2.0 的公布平台，年久失修。
sigma-deploy：sigma 3.x 的公布平台，以镜像 patch 的模式更新 deployment/daemonset。
asi-deploy：晚期 ASI 的公布平台，治理了 ASI 本身的组件，仅反对镜像 patch，只针对 Aone 的 CI/CD 流水线做适配，以及反对在多个不同环境间灰度，但灰度粒度较粗。

由此，咱们心愿借鉴后面几代 sigma/ASI 的公布平台历史，从变更时动手，以零碎能力为主，再辅以流程标准，逐渐构建 ASI 体系下的灰度体系，建设 Kubernetes 技术栈下的运维变更平台，保障数以千计的大规模集群的稳定性。

ASI 本身架构和状态的倒退会极大地影响其本身的灰度体系建设形式，因而在 ASI 倒退的晚期，咱们对 ASI 将来的状态做了如下大胆的预设：

以 ACK 为底座：ACK（阿里云容器服务）提供了云的各种能力，ASI 将基于复用这些云的能力，同时将阿里巴巴团体内积攒的先进经验反哺云。
集群规模大：为进步集群资源利用率，ASI 将会以大集群的形式存在，单个集群提供公共资源池来承载多个二方租户。
集群数量多：ASI 不仅按 Region 维度进行集群划分，还会依照业务方等维度划分独立的集群。
Addon 数量多：Kubernetes 体系是一个凋谢架构，会衍生出十分多 operator，而这些 operator 会和 ASI 外围组件一起独特对外提供各种能力。
变更场景简单：ASI 的组件变更场景将不止镜像公布模式，Kubernetes 申明式的对象生命周期治理注定了变更场景的复杂性。

基于以上几个假如，咱们可能总结在 ASI 建设初期，亟待解决的几个问题：

如何在单个大规模集群中建设变更的灰度能力？
如何在多个集群间建设规模化的变更灰度能力？
在组件数量、品种泛滥的状况下，如何保障进行组件治理并保障组件每次的公布不会影响线上环境？

咱们转换一下视角，脱离集群的维度，尝试从组件的角度来解决变更的复杂性。对于每个组件，它的生命周期能够大体划分为需要和设计阶段，研发阶段和公布阶段。对于每个阶段咱们都心愿进行规范化，并解决 Kubernetes 自身的特点，将固定的标准落到零碎中，以零碎能力去保障灰度过程。

联合 ASI 的状态和变更场景的特殊性，咱们从以下几点思路登程去系统化建设 ASI 的灰度体系：

需要和设计阶段
- 计划 TechReview
- 组件上线变更会审
组件研发阶段
- 标准化组件研发流程
组件公布变更阶段
- 提供组件工作台能力进行组件的规模化治理
- 建设 ASI 元数据，细化灰度单元
- 建设 ASI 单集群、跨集群的灰度能力

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 验证等能力，常态化运行在集群中。

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

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

模板：YAML 中在所有环境固定不变的信息，例如 apiVersion，kind 等；
镜像：YAML 中与组件镜像相干的信息，冀望在繁多环境或者所有集群中保持一致的信息；
配置：YAML 中与单环境、单集群绑定的信息，容许存在多样化的内容，不同集群中的配置可能不同；

因而，一个残缺的 YAML 则由模板、镜像和配置独特渲染而成。而 ASIOps 则再会对镜像信息和配置信息这部分 YAML 别离进行集群维度和工夫维度（多版本）进行治理，计算组件以后版本信息在泛滥集群泛滥散布情况以及组件在单集群中版本的一致性情况。

针对镜像版本，咱们从零碎上促使其版本对立，以保障不会因版本过低而导致线上问题；而针对配置版本，咱们则从治理上简化它的复杂性，避免配置谬误发入集群。

有了组件的根底原型后，咱们心愿公布不仅仅是“替换 workload 里的 image 字段”这样简略的一件事。咱们以后保护了整个 YAML 信息，蕴含了除了镜像之外的其余配置内容，须要反对除了镜像变动外的变更内容。因而咱们尝试以尽可能靠近 kubectl apply 的形式去进行 YAML 下发。

咱们会记录三局部的 YAML Specification 信息：

Cluster Spec：以后集群中指定资源的情况；
Target Spec：当初要公布进集群的 YAML 信息；
DB Spec：上一次部署胜利的 YAML 信息，与 kubectl apply 保留在 annotation 中的 last-applied-configuration 性能雷同。

对于一个由镜像、配置和模板独特构建的 YAML，咱们会采集上述三种 Spec 信息，并进行一次 diff，从而取得到资源 diff patch，再进行一次 filter out，筛去不容许变更的危险的字段，最初将整体的 patch 以 strategic merge patch 或者 merge patch 的模式发送给 APIServer，触发使得 workload 从新进入 reconcile 过程，以扭转集群中该 workload 的理论情况。

除此之外，因为 ASI 组件之间具备较强的相关性，存在许多场景须要同时一次性公布多个组件。例如当咱们初始化一个集群，或者对集群做一次整体的 release 时。因而咱们在单个组件部署的根底上减少了 Addon Release 的概念，以组件的汇合来表明整个 ASI 的 release 版本，并且依据每个组件的依赖关系主动生成部署流，保障整体公布的过程中不会呈现循环依赖。

在云原生的环境下，咱们以终态的模式去形容利用的部署状态，而 Kubernetes 提供了保护各类 Workload 终态的能力，Operator 比照 workload 以后状态与终态的差距并进行状态协调。这个协调的过程，换言之 workload 公布或者回滚的过程，能够由 Operator 定义的公布策略来解决这个“面向终态场景内的面向过程的流程”。

相比 Kubernetes 下层的利用负载，底层的基础设施组件在公布的过程中更关怀组件本身的灰度公布策略和灰度暂停能力，_即不管任何类型的组件，都须要能在公布过程中具备及时进行公布的能力，以提供更多的工夫进行性能检测、决策以及回滚_。具体而言，这些能力能够演绎为如下几类：

updateStrategy：流式降级 / 滚动降级
pause/resume：暂停 / 恢复能力
maxUnavailable：不可用正本数达到肯定时可能疾速进行降级
partition：降级暂停能力，单次仅降级固定数量正本数，保留肯定数量的老版本正本

ASI 中针对 Kubernetes 原生 workload 能力、节点能力都进行了加强。依靠于集群中 Kruise 和 KubeNode 这类 operator 的能力以及下层管控平台 ASIOps 的独特合作，咱们对 Kubernetes 基础设施组件实现了上述灰度能力的反对。对于 Deployment / StatefulSet / DaemonSet / Dataplane 类型的组件，在单集群中公布时反对的能力如下：

后文将简要介绍咱们针对不同 Workload 类型的组件进行灰度的实现，具体的实现细节能够关注咱们开源的我的项目 OpenKruise 以及后续筹备开源的 KubeNode。

大多数 Kubernetes 的 operator 以 Deployment 或者 StatefulSet 的形式部署，在 Operator 公布的过程中，一旦镜像字段变动，所有 Operator 正本均会被降级。这个过程一旦新版本存在问题，则会造成不可挽回的问题。

针对此类 operator，咱们将 controller-runtime 从 operator 中剥离进去，构建一个中心化的组件 operator-manager（OpenKruise 开源实现中为 controller-mesh）。同时每个 operator pod 中会减少一个 operator-runtime 的 sidecar 容器，通过 gRPC 接口为组件的主容器提供 operator 的外围能力。

operator 向 APIServer 建设 Watch 连贯后，监听到事件并被转化为待 operator 协调解决的工作流（即 operator 的流量），operator-manager 负责中心化管控所有 operator 的流量，并依据规定进行流量分片，散发到不同的 operator-runtime，runtime 中的 workerqueue 再触发理论 operator 的协调工作。

在灰度过程中，operator-manager 反对依照 namespace 级别，哈希分片形式，将 operator 的流量摊派给新旧版本的两个正本，从而能够从两个正本解决的负载 workload 来验证这次灰度公布是否存在问题。

社区原生的 DaemonSet 反对了 RollingUpdate，然而其滚动降级的能力上仅反对 maxUnavailable 一种，这对于单集群数千上万节点的 ASI 而言是无奈承受的，一旦更新镜像后所有 DaemonSet Pod 将会被降级，并且无奈暂停，仅能通过 maxUnavailable 策略进行爱护。一旦 DaemonSet 公布了一个 Bug 版本，并且过程可能失常启动，那么 maxUnavailable 也无奈失效。

此外社区提供 onDelete 形式，能够在手动删除 Pod 创立新 Pod，由公布平台核心端管制公布程序和灰度，这种模式无奈做到单集群中的自闭环，所有的压力都回升到公布平台上。让下层公布平台来进行 Pod 驱赶，危险比拟大。最好的形式就是 Workload 能自闭环提供组件更新的能力。因而咱们在 Kruise 中增强了 DaemonSet 的能力使其反对上述几种重要的灰度能力。

如下是一个根本的 Kruise Advanced DaemonSet 的例子：

apiVersion: apps.kruise.io/v1alpha1
kind: DaemonSet
spec:
  # ...
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 5
      partition: 100
      paused: false

其中 partition 意为保留老版本镜像的 Pod 正本数，滚降级过程中一旦指定正本数 Pod 降级实现，将不再对新的 Pod 进行镜像降级。咱们在下层 ASIOps 中管制 partition 的数值来滚动降级 DaemonSet，并配合其余 UpdateStrategy 参数来保障灰度进度，同时在新创建的 Pod 上进行一些定向验证。

MachineComponentSet 是 KubeNode 体系内的 Workload，ASI 中在 Kubernetes 之外的节点组件（无奈用 Kubernetes 本身的 Workload 公布的组件），例如 Pouch，Containerd，Kubelet 等均是通过该 Workload 进行公布。

节点组件以 Kubernetes 外部的自定义资源 MachineComponent 进行示意，蕴含一个指定版本的节点组件（例如 pouch-1.0.0.81）的装置脚本，装置环境变量等信息；而 MachineComponentSet 则是节点组件与节点汇合的映射，表明该批机器须要装置该版本的节点组件。而核心端的 Machine-Operator 则会去协调这个映射关系，以终态的模式，比对节点上的组件版本以及指标版本的差别，并尝试去装置指定版本的节点组件。

在灰度公布这一部分，MachineComponentSet 的设计与 Advanced DaemonSet 相似，提供了包含 partition，maxUnavailable 的 RollingUpdate 个性，例如以下是一个 MachineComponentSet 的示例：

apiVersion: kubenode.alibabacloud.com/v1
kind: MachineComponentSet
metadata:
  labels:
    alibabacloud.com/akubelet-component-version: 1.18.6.238-20201116190105-cluster-202011241059-d380368.conf
    component: akubelet
  name: akubelet-machine-component-set
spec:
  componentName: akubelet
  selector: {}
  updateStrategy:
    maxUnavailable: 20%
    partition: 55
    pause: false

同样下层 ASIOps 在管制灰度降级节点组件时，与集群侧的 Machine-Operator 进行交互，批改指定 MachineComponentSet 的 partition 等字段进行滚动降级。

相比于传统的节点组件公布模式，KubeNode 体系将节点组件的生命周期也闭环至 Kubernetes 集群内，并将灰度公布的管制下沉到集群侧，缩小核心侧对节点元数据管理的压力。

阿里巴巴外部针对云产品、根底产品制订了变更红线 3.0，对管控面组件、数据面组件的变更操作的分批灰度、管制距离、可观测、可暂停、可回滚进行了要求。但变更对象以 region 的单元进行灰度不满足 ASI 的简单场景，因而咱们尝试去细化 ASI 上管控面、数据面的变更所属的变更单元的类型。

咱们围绕集群这一根底单元向上，向下别离进行形象，失去以下几个根本单元：

集群组：具备独特业务方（ASI 承接的二方用户）、网络域（售卖区 /OXS/ 团体）、环境（e2e/ 测试 / 预发 / 金丝雀 / 小流量 / 生产）信息，因而在监控、告警、巡检、公布等方面的配置具备共同性。
集群：ASI 集群概念，对应一个 Kubernetes 集群预案。
节点集：一组具备独特特色的节点汇合，包含资源池、子业务池等信息。
Namespace：单个集群中的单个 Namespace，通常 ASI 中一个下层业务对应一个 Namespace。
节点：单台宿主机节点，对应一个 Kubernetes Node。

针对每种公布模式（管控组件、节点组件），咱们以最小爆炸半径为准则，将他们所对应的灰度单元编排串联在一起，以使得灰度流程可能固化到零碎中，组件开发在公布中必须恪守流程，一一单元进行部署。编排过程中，咱们次要思考以下几个因素：

业务属性
环境（测试、预发、小流量、生产）
网络域（团体 V、售卖区、OXS）
集群规模（Pod/Node 数）
用户属性（承载用户的 GC 等级）
单元 / 核心
组件个性

同时咱们对每个单元进行权重打分，并对单元间的依赖关系进行编排。例如以下是一条 ASI 监控组件的公布流水线，因为该监控组件在所有 ASI 场景都会应用同一套计划，它将推平至所有 ASI 集群。并且在推平过程中，它首先会通过泛电商交易集群的验证，再进行团体 VPC 内二方的公布，最初进行售卖区集群的公布。
而在每个集群中，该组件则会依照上一节中咱们探讨的单集群内的灰度形式进行 1/5/10 批次的分批，逐批进行公布。

进行了灰度单元编排之后，咱们则能够取得到一次组件推平流水线的根底骨架。而对于骨架上的每个灰度单元，咱们尝试去丰盛它的前置检查和后置校验，从而可能在每次公布后确认灰度的胜利性，并进行无效的变更阻断。同时对于单个批次咱们设置肯定的静默期去使得后置校验可能有足够的工夫运行完，并且提供给组件开发足够的工夫进行验证。目前单批次前置后置校验内容包含：

全局危险规定（封网、熔断等）
公布工夫窗口（ASI 试行周末禁止公布的规定）
KubeProbe 集群黑盒探测
金丝雀工作（由诺曼底发动的 ASI 全链路的扩缩容工作）
外围监控指标大盘
组件日志（组件 panic 告警等）
被动诊断工作（被动查问对应的监控信息是否在公布过程中有大幅变动）

将整个多集群公布的流程串联在一起，咱们能够失去一个组件从研发，测试至上线公布，整个流程经验的事件如下图：

在流水线编排的实现方面，咱们对社区已有的 tekton 和 argo 进行了选型调研，但思考到咱们在公布流程中较多的逻辑不适宜独自放在容器中执行，同时咱们在公布过程中的需要不仅仅是 CI/CD，以及在设计初期这两个我的项目在社区中并不稳固。因此咱们参考了 tekton 的根底设计（task / taskrun / pipeline / pipelinerun）进行了实现，并且放弃着和社区独特的设计方向，在将来会调整与社区更靠近，更云原生的形式。

通过近一年半的建设，ASIOps 目前承载了近百个管控集群，近千个业务集群（包含 ASI 集群、Virtual Cluster 多租虚构集群，Sigma 2.0 虚构集群等），400 多个组件（包含 ASI 外围组件、二方组件等）。同时 ASIOps 上蕴含了近 30 余条推平流水线，实用于 ASI 本身以及 ASI 承载的业务方的不同公布场景。

同时每天有近 400 次的组件变更（包含镜像变更和配置变更），通过流水线推平的此时达 7900+。同时为了进步公布效率，咱们在前后置查看欠缺的条件下开启了单集群内主动灰度的能力，目前该能力被大多数 ASI 数据面的组件所应用。

如下是一个组件通过 ASIOps 进行版本推平的示例：

同时咱们在 ASIOps 上的分批灰度以及后置查看变更阻断，也帮忙咱们拦住了肯定因为组件变更引起的故障。例如 Pouch 组件在进行灰度时，因为版本不兼容导致了集群不可用，通过公布后触发的后置巡检发现了这一景象，并阻断了灰度过程。

ASIOps 上的组件大多数都是 ASI/Kubernetes 底层的基础设施组件，近一年半以来没有因为由组件变更所引起的故障。咱们致力将指定的标准通过零碎能力固化下来，以缩小和杜绝违反变更红线的变更，从而将故障的产生逐渐右移，从变更引发的低级故障逐渐转变至代码 Bug 本身引起的简单故障。

随着 ASI 的笼罩的场景逐渐扩充，ASIOps 作为其中的管控平台须要迎接更简单的场景，规模更大的集群数、组件数的挑战。

首先咱们亟待解决稳定性和效率这一衡量问题，当 ASIOps 纳管的集群数量达到一定量级后，进行一次组件推平的耗时将相当大。咱们心愿在建设了足够的前后置校验能力后，提供变更全托管的能力，由平台主动进行公布范畴内的组件推平，并执行无效的变更阻断，在 Kubernetes 基础设施这一层真正做到 CI/CD 自动化。

同时目前咱们须要手动对灰度单元进行编排，确定灰度程序，在将来咱们心愿建设齐全整个 ASI 的元数据，并主动对每次公布范畴内的所有单元进行过滤、打分和编排。

最初，目前 ASIOps 临时只做到针对组件相干的变更进行灰度的能力，而 ASI 范畴内的变更远不止组件这一点。灰度体系应该是一个通用的领域，灰度流水线须要被赋能到注入资源运维、预案执行的其余的场景中。
此外，整个管控平台的灰度能力没有与阿里巴巴有任何紧耦合，齐全基于 Kruise / KubeNode 等 Workload 进行打造，将来咱们会摸索开源整套能力输入到社区中。

关于云原生:云原生下的灰度体系建设

咱们面临着什么

预设和思路

灰度体系建设

1. 研发流程标准化

2. 组件规模化治理

3. 单集群灰度能力建设

1）Operator Platform

2）Advanced DaemonSet

3）MachineComponentSet

4. 跨集群灰度能力建设

成绩

瞻望