乐趣区

关于javascript:如何基于-K8s-构建下一代-DevOps-平台

jiezi

简介： 以后云原生 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 / DockerHub；
  • CI/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，这种形式能够解决企业外部所有问题，然而挑战在于很难与生态进行对接。如 RDS，SLB 的能力都嵌到 YAML 文件中，无奈复用，简直不具备原子化能力。同时无奈合作，无奈提供给兄弟部门或生态应用，只能给外部关闭生态应用。下层零碎不同利用对接 DevOps 平台时，须要写不同格局的 YAML，这也是十分苦楚的。

  • 难以了解，必须通过界面可视化透出
  • 无奈复用，简直不具备原子化能力
  • 无奈合作，只能外部关闭生态应用

OAM 利用模型的技术原理

OAM 利用模型的呈现，解决了上述利用治理的难题，上面咱们来介绍一下 OAM 模型的技术原理。

  1. Component 组件

OAM 中常见的概念是 Component 组件，齐全从研发角度定义的待部署单元。下图右侧是 YAML 中 Component 的例子，其中黄色局部能够灵便自定义。OAM 中会定义规范的架构 ContaineriseWorkload，示意工作负载局部，外面是待部署单元的具体形容。这时就能够解决关注点拆散的问题，帮忙利用侧工程师去掉很多细节，只须要关怀开发须要关注的端口号，镜像等等。

应答挑战一，在 OAM 中能够定义数据库表白资源须要应用云资源，Workload 中能够依据本人的须要定义不同的组件，包含基于虚拟机的利用、或者老的 Function 利用。组件是利用开发者关怀的。

  1. Trait

如果只是组件，组合起来就能够构建简略的利用。如果关怀利用运维的问题，OAM 中有 Trait 的概念，指的是在原来组件的根底上附加一些特色。特色指的是运维的能力，如手动扩缩容能力、内部拜访能力、公布、负载平衡。弹性扩缩容、基于流量的治理等等。通过 OAM 的 Trait 能够很灵便的失去插件化裁减能力。不同的 component 绑定不同的特色。

  1. Scope

Component，Trait 以及所有组装起来的 Application Configuration 就是 OAM 中的三种次要的概念。但当多个组件独特合作时应该如何解决？OAM 中有个边界 Scope 的概念，是一种非凡的 Trait，将多个 Component 组合在一起，共享一组资源组，CPU 等特色用 Scope 示意，拓展多个组件的独特特色。

OAM 加持下的下一代 DevOps 技术

  1. OAM：以利用为核心的分层模型

OAM 是以利用为核心的分层模型，首先须要运行在服务端的 OAM 解释器，对于 YAML 的读取须要通过 OAM 解释器。OAM 提供 Trait，Component 让用户填写，编成 APP Config。APP Config 通过 OAM 解释器具备 Deployment，Ingress，HPA 或者云资源等能力。这种办法能够将研发、运维基于基础设施进行分层，研发关怀 Component，运维关怀 Trait，基础设施通过 OAM 解释器提供各种能力，与 K8s 紧密结合，对其利用概念做了补充。

  • 分层
  • 模块化
  • 可复用
  1. 疾速的纳入 K8s 生态已有 Operater 能力

OAM 能够疾速的纳入 K8s 生态已有的 Operater 能力，下图右边的 Component 中是一个 CRD 的实例，左边是 Trait 中的 CRD 的实例，两头示意 Component 底下的 Workload 和 Trait 别离对应了 K8s 自定义资源的能力。如果想要应用 K8s 中的某些能力，只须要在 Trait 中写入相应的字段即可。

  1. OAM 框架解决组件依赖关系和启动程序

OAM 框架解决组件依赖关系和启动程序。OAM Runtime，OAM 解释器会将组件依赖关系和启动程序解决好，下图中 Component 之间有 dependency 关系，Trait 与 Component 之间有 preComponent 或者 postComponent 等关系。

  1. OAM Trait 灵便解决资源绑定难题

启动程序厘清之后波及到资源绑定问题，一边是应用的数据库，另一边是 Web 的程序，Web 的程序绑定数据库连贯串资源。在 OAM 中只须要写一个 Trait 就能够解决资源绑定问题，下图左边，K8s 通过 Secret 承载连贯串信息，Service Binding Trait 对应一个运行的 Operator，Web Hook 拿到 Secret 后注入进数据库中。

  1. Workload 与 Trait 交互机制

大家会思考接入 OAM 会不会比拟麻烦，需不需要改代码。OAM 设计了 Workload 与 Trait 交互机制，OAM 外部零革新，只须要扩大 Workload 和 Trait。首先，Component 中创立 Workload 实例，再创立 Trait 实例，只须要在 Trait 中查看 Workload 的 Definition，从而配置 Trait 中须要的能力。


（OAM 内核零革新，插件式疾速接入新能力）

如果开发了新的能力，碰到抵触问题也是十分头痛的。在 OAM 框架中定义 Trait 时，能够查看哪些字段是抵触的，回绝掉新的利用的创立，从而保障 Trait 之间的兼容性，使得运维问题可发现、可治理。


（可发现、可治理的 Traits 零碎）

  1. 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 侧，用户只须要装上插件，就能够很不便的嵌入很多丰盛的能力。

原文链接
本文为阿里云原创内容，未经容许不得转载。

退出移动版