做网站用什么地图好,做网站公司职员工资,做网站用语言,游戏门户网站模板简介#xff1a; 当前云原生 DevOps 体系现状如何#xff1f;面临哪些挑战#xff1f;如何通过 OAM 解决云原生 DevOps 场景下的诸多问题#xff1f;云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答#xff0c;并分享如何基于 OAM 和…简介 当前云原生 DevOps 体系现状如何面临哪些挑战如何通过 OAM 解决云原生 DevOps 场景下的诸多问题云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。 作者 | 孙健波天元 导读当前云原生 DevOps 体系现状如何面临哪些挑战如何通过 OAM 解决云原生 DevOps 场景下的诸多问题云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。 什么是 DevOps为什么基于 Kubernetes 构建
2009 年举办了第一届 DevOpsDays 大会DevOps 名字被首次提出。到 2010 年DevOps 的概念越来越火出了 What is DevOps 的文章讲解了 DevOps 的概念方法论及配套的工具。简单来说研发工程师需要和运维工程师深度的合作同时通过一系列工具保证研发更加顺畅从而更容易的接触生产环境。
到 2013 年Docker 出现了工程师可以第一次到软件生产环境中定义通过 Docker image 完成单机软件的交付和分发。此时 DevOps 开始慢慢落地。2015 年开始DevOps 相关的工具越来越多资源利用率出现了一些问题CNCF 的成立使得 DevOps 的实践往 Kubernetes 上走。 DevOps 的三个阶段
阿里在 Kubernetes 上的实践也取得了非常好的成果。在规模方面阿里内部集成了数十个节点可以达到上万的集群同时具备高性能和安全特性秒级扩容神龙安全容器。具备极致的弹性分钟级拆解公有云计算资源无限资源池。另一方面Kubernetes 社区已经具备非常丰富的 DevOps 生态基础功能包括镜像托管、CICD 流水线、任务编排、发布策略、镜像打包、分发、丰富的应用运行时的负载支撑、丰富弹性和应用扩容能力。
为什么阿里基于 Kubernetes 构建 DevOps平台
1阿里基于 Kubernetes 的无限资源池与基础设施能力
大规模 – 单集群最高可达 10000 节点、百万 Pod高性能 – 秒级扩容智能伸缩神龙 安全容器极致弹性 – 分钟级拆解公有云计算资源无限资源池
2社区围绕 Kubernetes 已经具备丰富的 DevOps 生态基础功能
源码到容器镜像仓库Kubernetes 是容器平台事实标准Github / DockerHubCI/CD 流水线、任务编排、发布策略Argo / Teckton / Spinnaker / Jenkins-X / Flagger镜像打包、分发Helm / CNAB丰富的应用运行负载支撑Deployment(无状态) / StatefulSet(有状态) / OpenKruise(原生有状态增强)丰富的弹性和应用扩缩容能力HPA / KEDA。
基于 Kubernetes 的 DevOps 平台新挑战
下图展示了一个云原生下的 DevOps 流水线的典型流程。首先是代码的开发代码托管到 Github再接入单元测试的工具 Jenkins此时基本研发已完成。再接着到镜像的构建涉及到配置、编排等。云原生中可以用 HELM 打包应用。打包好的应用部署到各个环境中。但整个过程中会面临很多挑战。首先在不同的环境需要不同的运维能力。 一个云原生 DevOps 流水线的典型流程
其次配置的过程中要创建云上数据库需要另外打开一个控制台来创建数据库。还需要配置负载均衡。在应用启动以后还需要配置额外的功能包括日志、策略、安全防护等等。可以发现云资源和 DevOps 平台体验是割裂的里面充斥着借助外部平台创建的过程。这对新手来说是非常痛苦的。
挑战一云资源与 DevOps 平台体验割裂
DevOps 流程中充斥着大量需要外部平台创建的过程 挑战二研发、运维、基础设施关注点耦合
下图是常用的 K8s 的 YAML 配置文件大家经常吐槽这个配置文件很复杂。
简单来说 YAML 配置文件可以分为三大块一块是运维比较关心的配置包括实例数策略和发布。第二块是研发关心的涉及到镜像、端口号等。第三块是基础设施工程师看得懂的如调度策略等。K8s 的配置文件中将方方面面的信息都耦合在一起这对 K8s 工程师来说是非常适合的但是对应用侧的终端工程师而言有很多不需要关心的配置指标。 DevOps 流程中缺乏对“应用”这个概念的描述K8s 的 YAML 文件的定位并不是终端用户
挑战三平台的自定义封装简单却能力不足
DevOps 平台对 K8s 能力封装抽象只剩下 5 个 Deployment 的字段需要研发填写。从用户角度而言这种设置非常好用简单。但是针对稍微复杂的应用涉及到应用状态管理健康检查等等一系列的操作此时这 5 个字段是不够的。 挑战四CRD 扩展能力强大DevOps 平台无法直接复用
CRD(Customize Resource Definition) 扩展能力强大几乎所有软件都可以通过 CRD 的方式进行扩展包括数据库、存储、安全、编排、依赖管理、发布等。但是对 DevOps 平台来说上面接口并没有向用户暴露导致无法直接复用。 挑战五DevOps 平台开发的新能力使用门槛高
如果平台想要扩展一些能力而原生的自动扩缩容能力不太合适希望开发定时的扩缩容YAML文件随着业务情况而设置。但此时用户使用YAML的门槛非常高不清楚如何使用YAML。随着新能力开发越来越多能力之间会出现冲突这也非常难以管理。 运维同学怎么知道这个扩展能力怎么用看 CRD看配置文件看 …… 文档扩展能力间出现冲突导致线上故障比如CronHPA 和 默认 HPA 被同时安装给了同一个应用K8s 扩展能力之间的冲突关系如何有效管理如何有效的对运维透出
挑战六不同 DevOps 平台需要完全重新对接
很多云原生实践中会遇到的问题即需要定义非常复杂的 YAML这种方式可以解决企业内部所有问题但是挑战在于很难与生态进行对接。如 RDSSLB 的能力都嵌到 YAML 文件中无法复用几乎不具备原子化能力。同时无法协作无法提供给兄弟部门或生态使用只能给内部封闭生态使用。上层系统不同应用对接 DevOps 平台时需要写不同格式的 YAML这也是非常痛苦的。 难以理解必须通过界面可视化透出无法复用几乎不具备原子化能力无法协作只能内部封闭生态使用
OAM 应用模型的技术原理
OAM 应用模型的出现解决了上述应用管理的难题下面我们来介绍一下 OAM 模型的技术原理。
1. Component 组件
OAM 中常见的概念是 Component 组件完全从研发角度定义的待部署单元。下图右侧是 YAML 中 Component 的例子其中黄色部分可以灵活自定义。OAM 中会定义标准的架构 ContaineriseWorkload表示工作负载部分里面是待部署单元的具体描述。这时就可以解决关注点分离的问题帮助应用侧工程师去掉很多细节只需要关心开发需要关注的端口号镜像等等。 应对挑战一在 OAM 中可以定义数据库表达资源需要使用云资源Workload 中可以根据自己的需要定义不同的组件包括基于虚拟机的应用、或者老的 Function 应用。组件是应用开发者关心的。 2. Trait
如果只是组件组合起来就可以构建简单的应用。如果关心应用运维的问题OAM 中有 Trait 的概念指的是在原来组件的基础上附加一些特征。特征指的是运维的能力如手动扩缩容能力、外部访问能力、发布、负载均衡。弹性扩缩容、基于流量的管理等等。通过 OAM 的 Trait 可以很灵活的得到插件化扩充能力。不同的 component 绑定不同的特征。 3. Scope
ComponentTrait 以及所有组装起来的 Application Configuration 就是 OAM 中的三种主要的概念。但当多个组件共同协作时应该如何处理OAM 中有个边界 Scope 的概念是一种特殊的 Trait将多个 Component 组合在一起共享一组资源组CPU 等特征用 Scope 表示拓展多个组件的共同特征。 OAM 加持下的下一代 DevOps 技术
1. OAM以应用为中心的分层模型
OAM 是以应用为中心的分层模型首先需要运行在服务端的 OAM 解释器对于 YAML 的读取需要通过 OAM 解释器。OAM 提供 TraitComponent 让用户填写编成 APP Config。APP Config 通过 OAM 解释器具备 DeploymentIngressHPA 或者云资源等能力。这种方法可以将研发、运维基于基础设施进行分层研发关心 Component运维关心 Trait基础设施通过 OAM 解释器提供各种能力与 K8s 紧密结合对其应用概念做了补充。 分层模块化可复用
2. 快速的纳入 K8s 生态已有 Operater 能力
OAM 可以快速的纳入 K8s 生态已有的 Operater 能力下图左边的 Component 中是一个 CRD 的实例右边是 Trait 中的 CRD 的实例中间表示 Component 底下的 Workload 和 Trait 分别对应了 K8s 自定义资源的能力。如果想要使用 K8s 中的某些能力只需要在 Trait 中写入相应的字段即可。 3. OAM 框架解决组件依赖关系和启动顺序
OAM 框架解决组件依赖关系和启动顺序。OAM RuntimeOAM 解释器会将组件依赖关系和启动顺序处理好下图中 Component 之间有 dependency 关系Trait 与 Component 之间有 preComponent 或者 postComponent 等关系。 4. OAM Trait 灵活解决资源绑定难题
启动顺序厘清之后涉及到资源绑定问题一边是使用的数据库另一边是 Web 的程序Web 的程序绑定数据库连接串资源。在 OAM 中只需要写一个 Trait 就可以解决资源绑定问题下图右边K8s 通过 Secret 承载连接串信息Service Binding Trait 对应一个运行的 OperatorWeb Hook 拿到 Secret 后注入进数据库中。 5. Workload 与 Trait 交互机制
大家会考虑接入 OAM 会不会比较麻烦需不需要改代码。OAM 设计了 Workload 与 Trait 交互机制OAM 内部零改造只需要扩展 Workload 和 Trait。首先Component 中创建 Workload 实例再创建 Trait 实例只需要在 Trait 中查看 Workload 的 Definition从而配置 Trait 中需要的能力。 OAM 内核零改造插件式快速接入新能力
如果开发了新的能力碰到冲突问题也是非常头痛的。在 OAM 框架中定义 Trait 时可以检查哪些字段是冲突的拒绝掉新的应用的创建从而保障 Trait 之间的兼容性使得运维问题可发现、可管理。 可发现、可管理的 Traits 系统
6. OAM无限能力的 DevOps 平台体系
下图是 DevOps 平台体系最下层是 OAM Runtime一部分是 Workload对应运行时的承载的 Runtime如 Function、Container、虚拟机、Serverless Service 等。另一部分是 Trait对应运维能力如发布、弹性扩缩容、日志、安全等等。再上一层可以根据场景化组合Application Profile组装成不同的业务形态平台不同平台可以使用不同组合的 Workload 和 Trait具备不同的能力。通过 OAM 标准化的模型构建无限能力的 DevOps 平台满足各种场景的需要。 在用户侧OAM 加持下的研发 DevOps 流程在镜像构建完成之后使用达到统一OAM 提供了 APP Config包含不同的 Component每个 Component 包含不同的运维能力 Trait支持不同的环境如测试环境、生成环境。OAM 配置统一适合不同的云可以拿到不同的集群中直接运行。在 K8s 侧用户只需要装上插件就可以很方便的嵌入很多丰富的能力。 原文链接 本文为阿里云原创内容未经允许不得转载。
