共计 11659 个字符，预计需要花费 30 分钟才能阅读完成。
本文是云原生凋谢协同技术摸索与实际一阶段的总结和综述。
蚂蚁根底技术在过来 3 年多以来继续、深刻推动全面的云原生化技术演进，咱们将在线、离线计算资源装进了一台计算机，将服务体系通过 mesh 的思路和技术手段进行了下沉解耦，能够说比拟充沛的拥抱了云原生技术，并获取了其带来的技术红利。
当实现了资源、服务的云原生化，咱们发现在云原生根底能力之上的运维体系与云原生技术凋谢、共享的思路有较大的间隔，在技术体系上也与云原生技术申明式、白盒化的思路相悖，同时因为短少匹配的技术撑持，历史包袱等问题也成为了云原生运维难以真正代际演进的阻碍。明天我要介绍的就是蚂蚁在这样的背景下在云原生运维方向进行的技术摸索和实际。
规模化云原生运维摸索
咱们先来回顾一下在蚂蚁实在的实际形式和面对的问题。首先，咱们来看看蚂蚁践行多年的经典运维中台，这类运维平台个别包含了控制器、业务模型、编排引擎、原子工作及管道，在蚂蚁这样的平台是一系列服务的汇合，他们较好的满足了集中式、标准化、低变更频率的利用公布及运维需要。但这种模式在实践中也存在着显著的有余。
首先对于非标准利用、利用个性化需要、高老本需要、非紧急需要、技改类需要，往往无奈较好的满足。在蚂蚁的实际中，非标运维需要、对外围利用模型及运维模型冲击较大的高老本革新需要、大量根底能力或运维性能的透出需要等长期无奈失去较好的满足，需要往往是正当的，是难以获得足够的优先级执行落地。在研发阶段，运维平台长期积攒了高复杂度的业务逻辑，批改测试波及跨零碎的长革新链路，同时根底能力的透出、运维能力的产品化依赖前端、服务端研发资源。这些问题使得运维平台研发日渐吃力，特地是在产品 GUI、业务模型、编排引擎等变更热点上，受限于扩大机制能力有余，外部实际中甚至呈现过线上一直批改代码、公布服务以满足需要的状况。平台上线后，对立的质保和线上全链路性能验证同样面对较大的压力。对于最终的使用者，命令式按钮背地的黑盒计算透明度低，审计难，后果难预测，同时激情操作、操作界面不相熟等问题也始终影响着线上的稳定性。这些问题长期存在，咱们寄希望于代际的技术演进来解决这些问题。
当云原生根底服务逐步稳固后，对于本身场景不在运维平台治理范畴内的利用，研发同学自发的借助云原生社区工具链解决问题。基于 Kubernetes 生态高度凋谢、高度可配置的特点，研发者能够自助、灵便、通明的申明式利用运行、运维需要，以利用粒度实现公布、运维操作。
用户通过 kustomize 等社区技术缩短了对接基础设施的门路，并通过如 velocity 等文本模板技术局部解决了动态 YAML 文件在较多变量时维度爆炸的问题，解决了默认值设定的问题，同时通过 code review 的形式进行多因子变更及评审。因为 Kubernetes 及其生态提供了面向资源、服务、运维、平安的横向能力，使得这种简略的形式可有很好的普遍性和适用性，通过对不同的 Kubernetes 集群“播放”这些数据即可实现对基础设施的变更，实质上是一种申明数据的流转。面向 git 仓库的研发形式和 gitops 流程反对对运维产品研发资源的诉求较低，往往能够比较简单的搭建起来，不强依赖产品研发资源投入。相比经典运维中台，这些益处清晰明确，但从工程视角毛病也非常明显。
首先 Kubernetes API 的设计较为简单，仅是 Kubernetes 原生提供的 low level API 就裸露了 500 多种模型，2000 多字段，场景上简直涵盖了基础设施应用层的方方面面，即便是业余同学也很难了解所有细节。其次这种形式的工程化水平很低，违反 DRY 准则，违反各团队职责能力高内聚低耦合的准则，即便在有肯定的工具反对的状况下，在外部的典型案例中一个多利用的 infra 我的项目依然保护了多达 5 万多行 YAML，同时因为团队边界造成的多个割裂的平台，用户需在多个平台间切换，每个平台的操作形式各异，加上跳板机黑屏命令，实现一次残缺的公布须要 2 天工夫。
因为低工程化水平的问题，各团队间协同依赖人肉拉群同步，最终 YAML 由多个团队定义的局部组合而成，其中一大部分属于 Kubernetes 及运维平台团队的定义，这些内容须要继续跟踪同步防止腐化，长期保护老本高。
KUSION: 云原生凋谢协同技术栈
以上两种模式各有利弊，劣势和问题都比拟清晰。那么能不能既要也要呢，能不能在继承经典运维平台劣势的状况下，充分利用云原生技术带来的红利，打造一个凋谢、通明、可协同的运维体系？
带着这样的问题，咱们进行了摸索和实际，并创立了基于基础设施代码化思路的云原生可编程技术栈 Kusion。
大家都晓得 Kubernetes 提供了申明式的 low level API，提倡其上生态能力通过 CRD 扩大的形式定义并提供服务，整个生态遵循对立的 API 标准束缚，复用 API 技术和工具。Kubernetes API 标准提倡 low level API 对象松耦合、可复用，以反对 high level API 由 low level API“组合”而成。Kubernetes 本身提供了利于开源流传的极简计划，并不包含 API 之上的技术和计划。
回到云原生技术的根源，咱们回看了 Kubernetes 前身 Borg 的利用技术生态。如下图示，在 BorgMaster 之上，Borg 团队研发了 Borg 接入三件套，即 BCL（Borg Configuration Language），Command-line tools，以及相应的 web service。用户能够通过 BCL 申明式编写需要，通过 Command-line tools 将 BCL 文件执行到 Borg 集群，并通过 web GUI 视图查看工作细节。通过大量的调研，咱们理解到 Google 外部的运维能力及产品生态、品质技术生态都依赖这三件套构建而成，在外部也进行了多年的迭代演进。
这给了咱们启发，明天咱们有了容器技术、服务体系，有了大量用户和差异化的需要，有了肯定数量的自动化运维平台，咱们心愿能通过云原生专用的语言和工具来链接 Kubernetes 生态、各个运维平台以及大量的用户，通过惟一事实定义打消运维平台孤岛，实现云原生基础设施在利用、运维层面的代际演进，达到“Fusion on Kubernetes”的指标。
带着这样的指标，咱们继续地进行做技术摸索和实际，目前曾经造成了 Kusion 技术栈，并在蚂蚁的生产实践中进行利用。
Kusion 技术栈基于这样的根底能力而工作，包含如下组成部分：
云原生配置策略专用语言 KCL (Kusion Configuration Language)
KCL 解释器及其 Plugin 扩大机制
KCL 研发工具集: Lint, Format, Doc-Gen，IDE Plugin(IDEA, VsCode)
Kusion Kubernetes 生态工具: OpenAPI-tool, KusionCtl(Srv)
Konfig 配置代码库，其中包含平台侧及用户侧代码
OCMP (Open CloudNative Management Practice) 实际说明书
Kusion 工作在基础设施之上，作为形象及管理层的技术撑持服务下层利用。不同角色的用户协同应用 Kubernetes 生态提供的横向能力，通过申明式、用意导向的定义形式应用基础设施，在场景上反对典型的云原生场景，也服务了一些经典运维场景，实现了一阶段的建设工作。目前接入 Kusion 的产品包含 IaC 公布、运维产品 InfraForm、建站产品 SiteBuilder、快恢平台等。通过将 Kusion 集成在自动化零碎中，咱们尽可能的和谐黑盒命令式自动化零碎与凋谢申明式配置零碎，使其施展各自的劣势。
集成 & 落地
新的技术体系首先面临着落地的问题，咱们先来看看 Kusion 在集成落地方面的思考和做法。
从整体思路上，咱们从经典运维零碎中的变更热点业务层、编排层着手，以 KCL 申明式配置块的形式外置编写对应逻辑，并被控制器自动化集成。
这种思路是有迹可循的，咱们来看看同行的教训，以雷神山医院的建设现场为例，咱们能够看到现场大量的组件是预制品，通过了测试、验证、交付后由现场的塔吊负责组装。这些组件须要良好的品控，须要内置水管、电线等“能力”，否则即便组装也无奈无效工作，同时须要给业务侧肯定的自定义配置空间，还要易于组装及自动化以晋升现场拆卸效率。实际上咱们面对的大规模运维流动与这样的现场有类似之处，古代基建的高效伎俩十分值得咱们学习借鉴。
对应咱们的理论场景，咱们基于 KCL 的工作形式须要满足以下要求：
可分工、可协同 ：组件制作、验收、交付、应用能够基于角色须要正当分工协同，满足软件供应链的需要
外置、预制的组件 ：组件独立于自动化零碎存在，预制的组件在交付前须要通过充沛的测试验证
内置资源、服务、身份等因素 ：组件仅向用户裸露无效的业务信息，同时内置云原生、可信的逻辑
易于业务定义 ：组件须要提供肯定的自定义配置能力
易于自动化 ：反对自动化组装，自动化对组件进行“增删改查”
接下来，咱们来看看基于 Kusion 工作的典型流程，此处有肯定的形象和简化。
前文提到 Kubernetes API 提供了基于 OpenAPI 的 low level API 及扩大机制，基于高内聚、低耦合、易复用、易组装的准则设计，以 Resource、Custome Resource 的形式存在。此外，Kubernetes API 提供了大量的命令以操作容器、Pod 等资源。对于 SDN、Mesh，或是其余的能力扩大都是基于这样的整体束缚和形式，大都提供了资源定义或命令操作。
基于这样的根底，在蚂蚁的实际中咱们将整体的工作流程分为 4 个步骤：
代码化 。对于资源定义，基于 OpenAPI Model/CRD 定义生成 KCL 构造体；对于命令操作，编写对应的申明式 KCL 构造体。这些构造体对应到平台侧原子能力定义。
抽象化 。平台侧 PaaS 平台同学基于这些原子申明式编写形象、组装，并定义出面向用户的前端构造体，从性能场景上涵盖了 AppConfiguration, Action / Ops, Locality / Topology, SA / RBAC, Node / Quota 等场景，并提供了简化编写的 Template 汇合。以 AppConfiguration 为例，咱们提供了 SigmaAppConfiguration、SigmaJobConfiguration 别离对应于服务型和工作型利用定义，此外针对 SOFA 利用的特色提供了 SofaAppConfiguration。这些前端构造体作为 Kusion Models 的“接口层”存在，受限于业务进度等起因各场景积攒的水位不同，仍须要长期的积攒打磨。
配置化 。利用侧研发或 SRE 同学基于这些前端构造体形容利用需要。用户能够通过构造体申明的形式为利用定义配置基线及不同环境的配置。在大部分状况下，用户仅须要进行构造体申明，即一些 key-value 对。对于有简单需要的场景，用户能够进行逻辑编写或通过继承构造体的形式组织代码逻辑
自动化 。当利用侧配置实现后，实际上曾经定义好了可用的“组件”，具备了自动化的条件。平台侧控制器能够通过 KCL CLI 或 GPL binding API 实现编译、执行、输入、代码批改、元素查问等自动化集成工作，用户则能够通过 KusionCtl 工具执行 KCL 代码映射执行到 Kubernetes 集群。
通过这样对立的工作流程，咱们轻量级地实现了对 Kubernetes 生态大量根底能力的透出，基于原子能力申明式地封装、形象出面向利用的配置、运维能力，并实现了肯定场景的落地利用。Kusion 提供了研发工具帮助使用者实现其工作。咱们能够对平台侧、用户侧分层协同模式下的实际做进一步的探讨。平台侧同学形象并定义出前端构造体，例如 SofaAppConfiguration，其中定义了业务镜像、所需资源、config、secrect、sidecar、LB、DNS、正本数、逻辑资源池、公布策略、是否超卖、是否拜访公网等等。
前端构造体无奈独立工作，实际上存在着与前端构造体对应的后端构造体，后端对前端通明，前 - 后端构造体拆散解耦。后端构造体在运行时将前端构造体产生的数据“翻译”成对应的 low level API，这种反向依赖的形式依赖于 KCL 语言能力。
从工程角度看平台侧同学实际上实现了一次轻量级、申明式的利用级 API 定义。这种前后端拆散的设计有诸多益处。首先利用侧应用的前端构造体能够放弃简略洁净、业务导向、实现细节无关；其次能够通过编译时指向不同的后端文件动静切换到不同的后端构造体实现，以实现平台版本切换、实现切换等目标；最初这样拆散的做法能够在对立模式的前提下保障充沛的灵活性，例如平台能够通过 kcl base.k prod.k backend.k 多文件编译实现一次蕴含基线、环境配置、后端构造体的组合编译。事实上，咱们能够将所有场景规约为 kcl user_0.k … user_n.k platform_0.k … platform_n.k 的范式，其中 user.k 代表用户侧代码，platform.k 代表平台侧代码。咱们从另一个角度来看多团队协同的形式。由各团队自下而上定义平台能力及束缚，并实现利用级的配置基线及配置环境特色，实现最初一公里的定义。
在理清工作流程后，咱们来看 KCL 通过 Konfig 大库落地的实际。咱们在 Konfig 代码仓库中定义了平台侧及用户侧的代码空间，通过对立配置代码库实现对代码的共享和复用，保障了对整体基础设施代码定义的可见性。在用户侧，通过 project、stack、component(对应蚂蚁外部利用) 三级目录的形式组织代码。以 cloudmesh 为例，在 tnt/middleware/cloudmesh 的 project 目录下含多个 stack，如 dev、prod，每个 stack 中含多个 component。代码在这三个维度得以隔离，并共享上下文。
在代码质保方面，咱们通过单元测试、集成测试等伎俩保障对平台侧、用户侧代码的品质，咱们正在引入代码扫描、配置回放、配置校验、dry-run 等验证伎俩保障代码变更的可靠性。在研发方面，咱们通过骨干开发、分支公布的形式保障不同利用并行研发的前提下尽可能不产生代码腐化的状况，并通过 tag 爱护稳固分支。
在 IaC 产品落地场景中，通过标准化的构造体、代码版本化、多环境代码隔离、CI pipeline 等伎俩治理基础设施形容代码，通过代码变更的动态、动静 diff、模仿、异样提醒、危险管控接入保障基础设施变更可控，通过代码 Pull Request 做变更审计及对变更人员的追踪。下图以业务公布场景为例展现了关键步骤，在业务代码通过质保流程并实现镜像构建后，CI 流程控制器通过 KCL API 对 Konfig 仓库中对应 KCL 文件中的 image 字段进行自动更新，并发动 Pull Request，由此触发公布流程。
IaC 提供了编译测试、live-diff、dry-run、危险管控接入等验证形式，并反对执行过程的可视化，产品基于 KCL 语言能力及工具建设，尽可能的缩小业务定制。整个流程以 Konfig 代码的主动批改为终点，平台方、利用方、SRE 基于代码协同，通过产品界面进行线上公布，反对分批分步、回滚等运维能力。Konfig 中的代码“组件”能够被多个场景集成应用，例如此处被公布控制器集成的组件还能够被建站控制器集成，控制器只需关注自动化逻辑，无需关怀被集成组件的外部细节。以文章结尾的典型建站场景为例，在接入 Kusion 后，用户侧配置代码缩小到 5.5%，用户面对的 4 个平台通过接入对立代码库而消减，在无其余异样的状况下交付工夫从 2 天下降到 2 小时。
咱们再来看更加动态性的大规模疾速复原场景。快恢平台在接到监控告警输出后决策产生异样容器 hostname 列表，并须要对容器进行重启等复原操作。
咱们通过 KCL 编写申明式的利用复原运维代码，其中通过 KCL Plugin 扩大实现对在线 CMDB 的查问，将 hostname 列表转换为多集群 Pod 列表，并申明式定义 Pod 复原操作。快恢平台执行 KusionCtl run AppRecovery.k 实现跨多集群的 Pod 复原操作。通过这样的形式，快恢控制器无需了解容器复原细节、Kubernetes 多集群映射执行细节等，能够更专一于本身异样判断及决策逻辑。
在我的项目落地过程中，咱们也发现到了不少因为进度等起因造成的平台侧设计问题。例如平台侧操作定义不够标准，利用依赖等共性定义过于扩散等问题，这须要咱们在后续的落地过程中继续去积淀进步。凋谢配置给了用户更大的灵活性和空间，但相比黑盒的形式须要更多的安全性保障。在凋谢协同推动的同时，可信原生技术部在并行推动云原生可信平台的建设，可信平台通过将身份与 Kubernetes 技术紧密结合提供相比社区计划能力更强的技术撑持。
举个例子，通过凋谢配置咱们是不是能够通过 mount 证书的形式使得不可信不平安的服务取得拜访指标服务的权限从而获取到要害数据？事实上在没有身份传递及高水位 Pod 平安保障的前提下这是齐全可能。通过可信平台对 PSP（Pod Security Policy）、服务验证、服务鉴权等场景的加固，使得咱们能够按需加强要害链路的安全策略。相比与社区计划，可信平台定义了更残缺的 spiffe 身份标识，并使得身份作用于资源、网络、服务的各个环节，能够说可信是凋谢的必要前提。同时可信提供的鉴权能力、隔离能力也须要被用户应用，将原子能力封装并在利用配置层面透出依赖于 Kusion 的推动，使得接入 Kusion 的利用能够更简略的应用可信能力。能够说凋谢协同技术栈与可信平台是能力正交，相辅相成的云原生应用层技术。
最初，咱们对集成落地做一个小结：
平台侧编写 80% 内容，通过面向利用的前端构造体提供标准的配置块，再通过后端构造体定义屏蔽 low level API 资源及操作，最终通过这样的形式形容利用对 workload、编排、运维等方面的需要，重点在于能够定义什么、默认有什么及束缚汇合，并通过 Konfig 仓库共享复用。平台侧趋势引擎化，专一自动化管制逻辑，由 KCL 代码作为扩大技术外置编写业务逻辑。咱们心愿面对简单的运维业务诉求，平台侧控制器逐渐演进到低频变更，甚至零变更。
利用侧输出 20% 内容，以平台侧前端构造体为界面申明利用侧诉求，重点在于要什么、要做什么，所写即所得。利用侧通过面向多我的项目、多租户、多环境、多利用的代码工程构造组织代码，通过 Pull Request 发动变更，通过 CICD pipeline 实现白盒化的线上变更。同时，利用侧有对单利用编译、测试、验证、模仿的自由度，在充沛验证后交付使用；对多利用可通过 KCL 语言能力按需灵便组合。将大规模的简单问题拆分放大到利用粒度，失去充沛验证后按需合并，实质上是一种分治思路的实际。针对蚂蚁的理论状况，咱们通过 KusionCtl 工具反对研发测试环境的执行及可视化，通过 InfraForm 产品、SiteBuilder 产品等推动线上的部署过程。
协同配置问题模型
了解了落地思路和场景实际形式，咱们将进一步下钻拆解具体的协同场景，同时剖析 KCL 语言在配置场景的设计和利用。
咱们先来看平台侧编写轻量级利用级 API 的一些要点。平台侧同学能够通过单继承的形式扩大构造体，通过 mixin 机制定义构造体内属性的依赖关系及值内容，通过构造体内程序无关的编写形式实现申明式的构造体定义，此外还反对如逻辑判断、默认值等罕用性能。
对于申明式与命令式的差别做简略的剖析，咱们以斐波那契数列为例，能够把一组申明式代码看作一个方程组，方程式的编写程序实质上不影响求解，而“求解”的过程由 KCL 解释器实现，这样能够防止大量命令式拼装过程及程序判断代码，对于存在简单依赖的构造体而言优化尤为显著。
对于简单构造，命令式拼装的写法多出一倍以上的代码量，补丁代码使得后果难以预测，同时须要思考执行程序问题，特地是在模块化过程中调整存在依赖的模块程序十分繁琐且易出错。对于各种配套能力，咱们通过 mixin 机制编写，并通过 mixin 申明的形式“混入”到不同的构造体中。
对于平台侧来说，稳定性保障尤为重要。
当配置数据量逐渐增大时，良构类型是保障编译时问题发现的无效伎俩，KCL spec 包含了齐备的类型零碎设计，咱们正在实际动态类型检查和推导，逐渐加强类型的齐备性。
同时 KCL 引入了多种不可变伎俩，反对用户按需定义构造体内属性的不可变性。通过这两种根底而重要的技术手段使得大量违反编写束缚的状况能够在编译时被查看发现。
对于业务向的内容，KCL 反对通过构造体内置的校验规定及单元测试的形式反对。以下图所示代码为例，咱们在 AppBase 中定义对 containerPort、services、volumes 的校验规定，同时在 MyProdApp 中定义叠加的环境相干的校验规定。目前校验规定在运行时执行判断，咱们正在尝试通过编译时的动态剖析对规定进行判断从而发现问题。
此外对于平台侧来说，降级推动是必须面对的问题。咱们首先须要思考最坏状况，即提供给用户的前端构造体须要做不兼容的调整，依照新增配置项并下线老配置项的思路，咱们须要看待下线字段进行禁用，并以正当的形式告知用户。
当平台本身呈现不兼容更新时问题类似，只是须要平台侧后端构造体进行调整，利用侧用户不间接感知。KCL 针对这类问题提供了字段禁用的性能，应用被禁用字段将在编译阶段通过正告或谬误的形式提醒，编译谬误将 block 编译，从而迫使用户在编译阶段进行批改，防止将问题带入运行时造成影响。
对于兼容的平台侧调整，通常在后端构造体批改导入的原子定义文件即可。对于 KCL 解释器本身的变动，咱们通过单元测试、集成测试、含糊测试等进行验证，对于 plugin 的变更通过 plugin 本身的测试验证。KCL 解释器及 plugin 的变动通过须要 Konfig 代码库的 UT、IT 进行测试验证，保障已有代码失常工作。在通过测试验证后，发动 Pull Request 通过 code review 评审。
咱们再来简略梳理利用侧协同的场景。假如存在基线配置及生产环境配置，在咱们的实际中存在三种典型场景。
第一种场景中，基线与生产配置中各定义了同名配置的一部分，由 KCL 主动合并生成最终配置块，这实用于对称配置的场景十分无效，如果呈现抵触则会进行抵触报错。
第二种场景中，咱们心愿在生产配置中笼罩基线配置中的一些配置项，相似 Kustomize 的 overlay 笼罩性能，事实上这是大多数相熟 Kubernetes 使用者的诉求。
对于第三种场景，编写者心愿配置块全局惟一，不能进行任何模式的批改，若呈现同名配置则会在编译阶段报错。在实在的场景中，基线与各环境配置可由研发与 SRE 配合实现，也能够由 Dev 独立实现，Kusion 自身不限度使用者职能。
通过场景剖析咱们对 KCL 有了初步的理解，咱们以编程语言的实践、技术，云原生利用场景三方面为输出设计 KCL，咱们心愿通过简略无效的技术手段撑持平台侧、利用侧实现基础设施形容，将问题尽可能裸露在 KCL 编译、测试阶段，以缩小线上运行时的问题频次。此外咱们提供了便当的语言能力和工具帮忙不同的应用群体更高效的实现其工作，并通过工程化的形式组织、共享代码，对接 Kubernetes API 生态。
形象模型
通过对 Kusion 落地集成、协同编程场景的剖析，咱们理解到 Kusion 技术的组成场景及应用形式。咱们再来看看 Kusion 要害形象模型。
咱们先来看 KCL 代码的形象模型。以下图为例，首先 KCL 代码在编译过程中造成两张有向无环图，别离对应构造体外部申明代码及构造体应用申明。编译过程能够简略分为开展、合并、代换三步。通过这样的计算过程，在编译时实现了大部分代换运算，最终运行时进行大量计算即可失去最终的解。在编译过程中，咱们同步进行类型检查和值的查看，他们的区别是类型查看是做泛化，取偏序上确界，值查看是做特化，取偏序下确界。
对于 KCLVM 的解释器，咱们采纳了规范的分层解耦的设计形式，由 parser、compiler、VM 三局部组成。咱们心愿尽可能的在编译时实现工作，例如图的开展、代换，类型的查看、推导等，这样能够放弃 VM 局部尽可能简略。后续咱们将在 KCLVM compiler 中反对对 WASM 两头示意的编译反对。此外咱们通过 plugin 机制反对对 VM 运行时能力的扩大，并思考了对 LSP Server 的反对以升高 IDE、编辑器反对老本。
在工程化方面，咱们通过 project、stack、component 三级形式组织 KCL 代码。当代码映射到 Kubernetes 集群时，Kusion 反对两种映射形式。
第一种形式反对将 stack 映射为 namespace，component 在 namespace 内存在，即 stack 内共享资源配额，component 间通过 SDN 及 Mesh 能力做隔离，这是社区比拟常见的一种实际形式。
第二种形式将 component 映射为 namespace，stack 通过 label 标识，通过 SA 管理权限，资源配额定义在 component 维度，component 间通过 namespace 的隔离能力做隔离，这是蚂蚁目前线上环境的实际形式。无论如何映射，用户无需感知物理集群对接及切换细节。此外，KCL 代码中资源定义都能够通过惟一的资源 ID 定位，这也是对代码进行“增删改查”的根底。
为了反对上述的隔离及映射逻辑，咱们提供了 KusionCtl 工具帮忙用户实现我的项目构造初始化、Kubernetes 集群映射、执行状态跟踪及展现、Identity 权限集成等罕用性能。用户能够通过 KusionCtl 实现研发、测试环境的执行和验证工作。
对于线上环境，咱们更举荐应用基于 Kusion 的运维产品进行变更操作。咱们心愿通过 KCL 代码凋谢、通明、申明式、用意导向、分层解耦的定义基础设施，实质上是面向数据及其束缚的一种协同工作，变更是一种数据的流动。咱们通过前置的预编译、计算、验证，最终将数据交付到各环境的运行时，相比于经典命令式零碎中计算逻辑流动的形式，能够最大水平防止简单命令式计算造成的运行时数据谬误，特地是当计算逻辑产生变更时，这种运行时计算错误的后果通常都是一次线上故障。
最初，咱们来看一种 Kusion 思路的技术架构，咱们依然以控制器、业务层、编排层、工作及管道的分层逻辑来看。自下而上的，由 Kubernetes API Server 收敛了管道并提供了原生资源定义，并通过 CRD & Operator 进行扩大提供稳固的原子工作定义。从我集体的角度看，Operator 如其名约“操作员”，反复着接管订单、执行操作的简略循环，订单未实现则继续操作。
Operator 应尽可能放弃简略，防止简单的业务逻辑拆解、管制逻辑、状态机，同时防止因为渺小的差别创立新的 Operator 或通过 Operator 做单纯的数据、YAML 转换。Operator 作为收敛基础设施原子能力的存在，应尽量内聚、稳固。在业务层、编排层，咱们通过 KCL 代码在 Konfig 仓库中编写，并联合 GitOps 反对利用粒度的变更、编译、测试、验证。控制器层高度引擎化，聚焦自动化逻辑，依据业务场景须要定制控制器及 GUI 产品界面。利用的配置代码“组件”由多个控制器共享复用，例如建站、公布、局部运维都将依赖利用 AppConfiguration 配置代码块。
总结 & 瞻望
最初，咱们对凋谢协同技术工作做一个总结。
咱们常说 Kubernetes 是云计算的 Linux/Unix，相比于 Unix 丰盛的外围配套生态，Kubernetes 在配套技术能力上还有很长的门路。比照于应用便当的 Shell、Tools，咱们还短少一种合乎 Kubernetes 申明式、凋谢、共享设计理念的语言及工具，Kusion 心愿能在这一畛域有所帮忙，晋升基础设施的凋谢水平及应用效率，易于共享、协同，晋升稳定性，简化云原生技术设施的接入形式。
咱们的摸索和实际依然在一个初级阶段，咱们心愿通过 Kusion 的技术和服务能力在运维、可信、云原生架构演进方面起到踊跃的作用。
咱们心愿推动真正的基础设施代码化，促成跨团队的 DevOps，成为继续部署与运维的技术撑持。在可信方面，策略及代码、可信集成、标准化的撑持是咱们后续的工作重点之一，特地是与策略引擎的联合，是凋谢可信技术能力的关键步骤。
在云原生架构方面，咱们将继续推动架构现代化的演进，通过技术手段反对更多下层自动化产品业务的疾速翻新，同时通过对立的流程、企业级的技术能力反对服务好基础设施利用场景。
纵观历史，技术总是朝着进步整体社会合作效力演进。
Kusion 带来的云原生凋谢协同无疑是这条奢侈法则再次施展效劳的注脚。
本周举荐浏览
- 稳定性大幅度晋升：SOFARegistry v6 新个性介绍
- 积跬步至千里：QUIC 协定在蚂蚁团体落地之综述
- 金融级能力成外围竞争力，服务网格驱动企业翻新
- Rust 大展拳脚的新兴畛域：秘密计算
更多文章请扫码关注“金融级分布式架构”公众号
