共计 5883 个字符，预计需要花费 15 分钟才能阅读完成。
作者：阿里云大数据根底工程技术团队——郭耀星
大家上午好！我是来自阿里云大数据根底工程技术团队的郭耀星，花名雪尧。明天我很快乐可能来到 QCon，与大家分享我的教训和心得。 在以后的多云环境中，作为运维撑持团队，如何在决裂重大、存在多个不同环境的异构 Kubernetes 底座状况下，高效率地治理与交付业务利用，是一个值得探讨的话题。
在开始正式分享之前，先做一个简略的自我介绍，我是 17 年武汉大学毕业，之后始终在阿里云的计算平台大数据根底工程技术团队，从事大数据运维平台的研发工作，也算是见证了大数据运维平台继续迭代演进的过程。
在我刚入职之后，我负责过多个运维中台服务的开发和建设。起初随着大数据架构从物理机向云化转变，我逐渐开始从事容器化相干的革新，再到当初齐全是云原生的天下。在这个过程中，我主导了咱们这边的 ABM，也就是大数据运维平台，在专有云及公共云上，几十个利用从物理机到 on K8S 的转型，这个过程很苦楚，但也以此为契机，积淀出了一套多云环境下的云原生下利用治理与交付的服务以及绝对应的实践经验，冀望在接下来的工夫里与大家分享。
明天我分享的内容次要有四个局部：
- 多云环境利用治理与交付痛点
- 实践后行：OAM
- 多云环境交付实际 – 微服务 / 大数据产品 / SREWorks 开源社区
- 要害能力实现与解析：AppManager (OAM Runtime)
首先来介绍多云环境下利用治理与交付的痛点，而后看在这些痛点之上，咱们为什么抉择了 OAM 作为咱们的实践模型，以及基于这套实践模型，咱们在多个业务场景下的实践经验，最初是咱们本人研发的这套 AppManager 服务要害能力的实现计划与解析。
多云环境利用治理与交付痛点
痛点 1 – 多云环境下的 K8s 底座适配问题
首先是第一局部，多云环境下，利用治理与交付的痛点是什么？
因为在对立底层基础架构细节方面的杰出体现，K8S 曾经成为企业多云治理的事实根底。但单服务商的单 K8S 集群真的满足需要么？
答案是否定的，作为基础设施的运维，咱们会和不拘一格的 K8S 集群打交道。有以后已有的各个厂商提供的公共云 K8S 集群，也有专有云版本部署在网络隔离机房环境下的 K8S 集群，以及独自拿进去做日常开发测试的 K8S 集群等等。除此之外，在阿里的外部场景还有更多的虚构 K8S 集群，比方 Flink 全托管场景等。
一般来说，大家常见的诉求是：
- 须要物理隔离，防止业务间相互影响。只管 K8S 本身提供了 Namespace 级别的隔离，你能够设置每个 Namespace 各自应用的 CPU 和内存，甚至能够应用 Network Policy 配置不同 Namespace 的网络连通性，但这些依然不彻底，企业还是须要一个更加彻底的物理隔离环境，以此防止业务之间的相互影响。
- 须要混合云。混合云场景下，企业心愿能够抉择多个私有云厂商和公有云解决方案，防止受限于繁多云厂商，或升高肯定老本。
- 须要利用异地多活。部署业务多个正本到不同 region 集群，防止单个 region 的断电造成利用的不可用状况，实现不把鸡蛋放在同一个篮子目标。
- 须要环境拆散。为了辨别开发测试生产环境，把这些环境部署到不同的集群。
- 须要肯定的集群拓展性来冲破繁多集群的容量下限。
当然从纯正的多集群视角来看，目前计划有 Federation V1 / Federation V2 / OCM 等解决方案，还有多个 kubeconfig 直连的形式。不过这块不是本次探讨的重点，这里并不探讨多集群的问题，而是探讨异构 K8S 底座，多集群计划能够看做是异构 K8S 底座计划的一个子集。
所以最初重点是：如何在一个决裂的十分重大的，位于多个不同环境的异构 K8S 底座下，高效率的进行利用治理与交付。
痛点 2 – 研发与运维的诉求抵触
咱们团队本身其实定位于运维平台开发，下面会有两类角色，一类是研发，一类是 SRE。在更小规模的公司体量下，运维开发和 SRE 会归为一体，对研发提供运维平台及服务。
当一个人的时候，咱们推崇全栈工程师，DevOps。但随着规模和体量越来越大，肯定会呈现很多责任田，归属到不同的团队和不同的人。
在上述演进的过程中，研发和运维之间的矛盾会愈发凸显：在研发及产品视角，疯狂迭代疯狂上性能能力拿下用户拿下市场；在运维视角，不动线上不做变更就不会出问题。
痛点 3 – 研发与运维的分工抵触
在物理机 /ECS 时代，咱们本身管制着从下到上的整个链路。为了和谐上述矛盾，咱们制订了各种各样的变更标准，开发了各式各样的变更工具和流程，当然也吵过了很多的架。
那么在云原生的浪潮之下，Kubernetes 对立了底层的基础设施，缩小了大部分的底层运维工作，大家开玩笑说全副变成了 YAML 工程师。但还是有一个很重要的问题没有解决，就是：YAML 怎么写？谁来写？如何交付到指标 K8S 集群？
过来的两年多的工夫里，下面这些问题实实在在地摆在了咱们团队的背后，在以后的定位与场景下，要反对专有云、公共云、团体外部、开源社区等环境下的不拘一格各式各样的 K8S 集群下面的服务托管与交付。
实践后行：OAM
古时候有兵马未动，粮草先行。这里咱们是代码未动，实践后行。先说一下咱们为什么会抉择 OAM(Open Application Model) 作为咱们解决问题的实践根底。
咱们下面探讨了多种多样的痛点后，根本能够总结上面几点：
- 一个是开发者破费了太多的工夫在基础设施的细节中。机器从哪来，网络环境怎么样，中间件资源 /DNS/ 负载平衡怎么生成，团体外部的服务怎么适配到公共云 / 专有云各个底座上等等。或者更进一步，每个开发者都是 Yaml 工程师，哪怕都是 K8S，但每个底座让你提交的 YAML 都不一样。
- 另外一个是可扩展性低。有越来越多的平台 or 底座在尝试去撑持各种类型需要的业务，但一般来说，利用自身对于平台的诉求会很快超过平台的能力。
- 还有云服务供应商绑定。当抉择了一个固定的底座后，利用交付的方方面面将会打上这个底座的烙印，当想尝试转到另一个底座的时候难于登天。
- 最初是随着团队规模的收缩，研发、运维、平台人员之间开始各种互相踩脚，沟通和协调的老本也越来越高。
OAM 针对上述痛点提出了以下几个观点：
- 利用为先：一个利用的交付与部署应该是自蕴含的，其中的各类操作行为应该作为利用定义的一部分，这些内容与理论基础设施无关。
- 清晰和可扩展性：定义一套凋谢规范，能够模块化整个利用交付流程，依据集体须要将这些模块自在组装，达成本人想要的后果。
- 云服务供应商无关：定义的凋谢规范应该是一套更高级别的形象，能够跨本地集群、跨云服务供应商，不会被锁定到任何一个厂商的底座。
OAM 通过一系列概念的定义，实现了对一个利用的形象，实现了角色职责的拆散，将利用交付这件事件与底座解耦，使得跨云疾速交付利用成为可能。开发同学也不再关怀底座实现细节，只关怀本人的利用模型即可。OAM 的诞生，旨在定义云原生利用规范。
接下来咱们简略介绍下 OAM 中的局部概念：
一个 Application，也就是上图中最里面的蓝框，代表一个利用，是蕴含多个组件 Component 的，这里的组件就是咱们日常交付的最小业务单元，也就是上图中的浅绿色局部，比方一个微服务、一个 Job、一个 Helm 包等。那么组件 Component 的外部是由蓝色的 Workload 和深绿色的 Trait 组成的。Workload 就是工作负载类型，形容了以后 Component 是谁，而 Trait 则定义了以后组件的运维属性，比方我须要给这个微服务加个 200G 存储，加一条网关路由，限度多少 CPU 内存资源，或者更简单一点，当 Pod 漂移后 IP 变动了去做一些内部数据保护的事件。下面我形容的这些都能够用 Trait 来形象及形容。
下面说的这几个概念，都是面向终态的，和 K8S 本身的面向终态的逻辑是统一的，我只须要申明式的写出我心愿的理论交付后的利用的样子，而不须要关怀外部是怎么 Reconcile（和谐）去实现的。
![]()
除此之外，还有工作流 Workflow 和利用执行策略 Policy 的概念作为补充，他们是面向过程的，用于解决单纯的面向终态的申明形式无奈笼罩的交付过程管制，比方人工审核、回滚、多集群公布等等。
我认为 OAM 模型带给咱们的最大影响是，咱们须要时时刻刻将“关注点拆散”这个事件作为最大的准则，简略来说就是明确人员分工。这外面有三个角色：
- 第一个角色是利用开发人员，也就是写业务代码的同学，他们只须要负责组件 Component 的定义，比方我是什么类型的服务，镜像怎么构建，须要哪些参数来启动运行。
- 第二个角色是利用运维人员，他们定义下面讲到的运维特色，也就是 Trait，并将利用开发人员定义好的 Component 和这些 Trait 绑定到一起，辅以 Policy + Workflow，来生成最终交付的 Application YAML，并提交到 Runtime 实现，去保护整个利用的生命周期。
- 最初一个角色是基础设施运维人员，他们去管制整个平台有哪些 Workload 可供下面两类角色应用，以及保护整个平台层面的稳定性。
当然在理论实际的过程中，依据团队规模，有可能一人身兼数职，但随着团队规模的扩充，按下面的形容进行团队的分工，能够最大限度的升高沟通合作的老本，进步利用治理与交付的效率及稳定性。
多云环境交付实际
终于讲完了实践，咱们接下来进入实际环节。
先简要形容下咱们的团队所面临的业务场景，有四大块，别离是专有云、公共云、团体外部还有开源社区：
- 专有云 ：将 ABM 交付到各个客户现场环境中，依赖对立的阿里专有云 K8s 底座。大部分的客户环境是网络隔离的，不出差到现场的状况下，只能拍照一来一回解决问题。
- 公共云 ：交付各个阿里大数据产品到公共云 ACK 集群上 (资源集群 or 业务集群)，多 Region，为云上客户提供服务。
- 团体外部 ：部署各个大数据产品到团体外部 K8S 集群上，多 Region，为团体外部各业务方提供服务；另外还须要将咱们本身交付到 OXS(阿里云内核区域)K8s 公共集群中 (权限受限)。
- 开源社区 ：交付 SREWorks 到各类用户自建的集群下以及各大厂商公共云。
产品状态
面对下面所说的简单多云环境，咱们最终设计的产品架构如下：
大家能够看到，咱们针对于多云下的利用治理和交付场景，自研了一套基于 OAM 模型的 AppManager 服务，能够认为是一套 OAM 模型的 Java Runtime 实现。它作为利用引擎，提供了很多能力，涵盖构建、部署、制品治理、工作流引擎、插件、多云反对、多环境反对、状态感知等等，提供底层能力并向上裸露 API。在此之上，咱们针对三个场景提供了对应的用户界面，并对理论用户提供服务。
- 首先是企业应用治理：各类开源 / 自有利用的云原生部署计划，可扩大各种组件类型，让使用者能够一键部署简单利用撑持业务。
- 之后是运维利用治理，这里会细分一下：
<!—->
-
- 第一类是应用前端低代码模式构建的运维利用配置，可能被疾速嵌入集成运维中台能力。此类利用无理论后端，均为纯正的利用配置汇合。
- 第二类是应用微服务类型构建的运维利用，可能辨认并托管下面说的的利用配置，实现对应的运维中台能力。
<!—->
- 最初是大数据利用治理，对应开源场景 SREWorks 下的企业应用治理。在外部咱们通过该零碎实现阿里云上的所有大数据产品的交付、售卖及管控能力。
为了更好的和内部互动，咱们开源了 SREWorks，作为一整套数智化运维的解决方案，也就是上图中的 AppManager + 企业应用治理 + 运维利用治理，冀望能为大家提供开箱即用的云原生利用 & 资源交付的运维平台。大家感兴趣的能够去 Github 上进一步理解，一会儿会独自介绍。其中，AppManager 和咱们外部应用的是同一套代码和分支，始终放弃着和开源社区的同步；企业应用治理和运维利用治理通过肯定剪裁和开源适配；而大数据利用治理因为波及阿里云上各个大数据产品的交付、售卖及管控细节，暂不开源。
微服务
接下来咱们针对不同的业务类型来看一下整体的流程：
首先是最简略的微服务，通过 AppManager，研发的同学配置好本人的仓库和 Dockerfile，就能够主动构建进去对应的镜像，以及包装后的制品——微服务组件包，多个微服务组件包最终打包为一个独立带版本的利用包。
之后是 SRE 同学入场，通过抉择研发同学提供的制品，配合本人配置的一系列交付参数，比方部署到哪些指标集群、须要针对每个集群设置什么参数、加上哪些运维特色 Trait、配置什么策略、用什么工作流来编排、如何监测感知利用运行状态等等，这些最终生成了一份 Application 的 Yaml 文件，提交到 AppManager 运行。之后会由 AppManager 解析上述 YAML 并按要求交付到各个环境中，实现整个多云环境下的利用交付过程。
另外在右下角这类专有云隔离环境下，咱们还反对了离线包交付，不便在网络隔离的环境下依然简略高效的交付全副的利用。
大数据产品
接下来看阿里云上售卖的大数据云产品的场景：
大数据产品因为业务个性简单，有大量的动静渲染及相互依赖关系，所以目前采纳了咱们外部自研的 AbmChart 组件类型来承载，还有通用的 Helm/Kustomize 两种状态，但不论采纳哪种状态，都是 Component，在流程上和方才并没有什么不同，都是构建、打包、交付、监测。只不过组件类型的外部解决流程较为简单，以及交付的指标集群及状态多样化。
SREWorks 开源社区
最初是 SREWorks 开源社区，SREWorks 是咱们团队对 SRE 理念的工程实际的一套开源产品。通过形象通用运维模型，实现五大外围价值场景，包含智能化运维、数据化运维、云原生 DevOps、云原生运维开发、多云治理。撑持“品质、老本、效率、平安”的运维需要，提供“交付、监控、治理、管制、经营、服务”全生命周期能力撑持。
对立管控计划
看完了利用治理及交付的流程，之后咱们来看一下对立管控的计划：
因为是多云环境，所以会须要一个核心环境 AppManager 服务来作为整体的管控，也就是核心绿色的局部。
咱们把每一个网络隔离或用处隔离的环境称为一个单元 Unit，单元内自成一体，对外无任何依赖。
每个单元须要部署一个 AppManager 作为这个单元本人的管控，并负责本人这个单元下所有利用的交付动作。核心 AppManager 只负责向各个单元 AppManager 下发命令即可。
在这个管控架构下，咱们目前有几种类型的单元，每个单元能够非常灵活地适配其底座架构部署。
鉴于本次演讲篇幅比拟长，咱们将演讲稿分为了高低两篇文章。在这上篇中，咱们曾经对多云治理有了一个根本的理解。在下篇中，咱们将更深刻地解析多云治理的要害能力：AppManager。