关于devops:Kubernetes-已经成为云原生时代的安卓这就够了吗

简介：本文将介绍如何在 Kubernetes 上构建新的利用治理平台，提供一层形象以封装底层逻辑，只出现用户关怀的接口，使用户能够只关注本人的业务逻辑，治理利用更快更平安。

作者：司徒放

导语：云原生时代，间接应用 Kubernetes 和云基础设施过于简单，如用户须要学习很多底层细节、利用治理的上手老本高、容易出错、故障频频。随着云计算的遍及，不同云又有不同的细节，进一步加剧了上述问题。

本文将介绍如何在 Kubernetes 上构建新的利用治理平台，提供一层形象以封装底层逻辑，只出现用户关怀的接口，使用户能够只关注本人的业务逻辑，治理利用更快更平安。

云原生时代是一个十分好的时代，咱们所面临的是整体技术的颠覆性变革，全面地对利用做端到端重构。目前，云原生在演进过程中产生了三个关键技术：

一是容器化，容器作为标准化交互的介质，在运维效率、部署密度和资源隔离性方面相比传统形式有很大改良，据 CNCF 最新调研报告显示，目前已有 92% 的企业生产零碎在应用容器；

二是 Kubernetes，它对基础设施进行了形象和治理，现已成为云原生的标配；

三是 Operator 自动化运维，通过控制器和定制资源的机制，使 Kubernetes 不仅能够运维无状态利用，还能够执行由用户定义的运维能力，实现更简单的自动化运维利用进行自动化部署和交互。

这三项关键技术其实是逐步演进的关系，另外，在利用交付畛域，也有与之对应的实践在追随上述技术一直地演进。云原生的崛起，带来了交付介质、基础设施治理、运维模型和继续交付实践的全面降级和冲破，减速了云计算时代的到来。

图 1 云原生技术全景图

从 CNCF 公布的云原生技术全景图（见图 1）中，能够看到云原生的蓬勃生态，细数图中这 900 + Logo，其中不乏开源我的项目、守业公司，将来云原生的技术都会在这些中央诞生。

云原生“操作系统”Kubernetes 带来的利用交付挑战

上文提到，Kubernetes 已成为云原生的标配，其对下封装基础设施的差别，对上反对各种利用的运维部署，如无状态利用、微服务，再如有状态、批处理、大数据、AI、区块链等新技术的利用，在 Kubernetes 下面都有方法部署。Kubernetes 曾经成为了现实意义的“操作系统”。它在云原生的位置正如挪动设施中的 Android。为什么这样讲？Android 不仅仅装在咱们的手机上，它还进一步渗透到汽车、电视、天猫精灵等智能终端里，挪动利用能够通过 Android 运行在这些设施上。而 Kubernetes 也有这样的后劲或发展趋势，当然它不是呈现在智能家电中，而是呈现在各家私有云、自建机房，以及边缘集群。能够料想，Kubernetes 将来会像 Android 一样无处不在。

那么，有了 Kubernetes 这层交付当前，容器 + Kubernetes 这层界面是不是就能够解决掉所有的交付问题了？答案必定不是。试想，如果咱们的手机中只有 Android 零碎，它可能满足咱们工作和生存需要吗？不能，必须有各种各样的软件应用才行。对应到云原生，它除了 Kubernetes 这个“操作系统”外，也须要一套利用的交付能力。在手机中，软件应用能够通过相似“豌豆荚”这样的利用以便用户装置，同样在云原生时代，咱们也须要将利用部署到不同的 Kubernetes 集群上。但因为 Kubernetes 海量琐碎的设施细节与简单各异的操作语言，导致部署过程中会遇到各种各样的问题，这时就须要云原生的“豌豆荚”来解决这个问题，也就是利用治理平台，去屏蔽交付的复杂性。

利用治理平台在业界有两种支流模式，第一种是传统平台模式，在 Kubernetes 上“盖一个大帽子”，将所有复杂度屏蔽，在此之上，再依据需要本人提供一层简化的利用形象。通过这种形式，尽管利用平台变得易用了，但新的能力须要由平台开发实现，也就带来了扩大难、迭代迟缓的问题，无奈满足日益增长的利用治理诉求。

另一种解法是容器平台模式。这种模式比拟云原生，组件是凋谢的，扩展性强，然而，它不足应用层的形象，导致了很多问题，比方开发者学习路线平缓。举个例子，当一个业务开发者把本人的代码提交到利用平台时，他须要写 Deployment 部署利用、写 Prometheus 规定配置监控、写 HPA 设置弹性伸缩，写 Istio 规定管制路由等，这些都不是业务开发心愿去做的。

所以，不论是哪种解法，都有优缺点，须要取舍。那么，到底怎么做能力封装平台的复杂性，还能领有良好的扩展性？这是咱们始终在摸索的。

通过利用治理平台，屏蔽云原生利用交付的复杂性

2012 年，阿里巴巴曾经开始做容器化相干的调研，起初次要是为了进步资源利用率，开始了自研容器虚拟化技术之路。随着应答大促的机器资源量一直增多，在 2015 年开始采纳容器的混合云弹性架构，并应用阿里云的私有云计算资源，撑持大促流量顶峰。这也是阿里巴巴做云原生的晚期阶段。

转折产生在 2018 年，阿里巴巴的底层调度采纳开源的 Kubernetes 后，咱们从面对虚拟机的脚本化装置部署模式，转变为基于规范的容器调度零碎部署利用，全面推动阿里巴巴基础设施的 Kubernetes 降级。但很快，新的问题就呈现了：利用平台没有规范、不对立，大家“各自为政”。

因而，咱们在 2019 年携手微软公布了凋谢利用模型——OAM（Open Application Model），并开始做 OAM 平台化革新。所有都比较顺利，2020 年 OAM 的实现引擎 KubeVela 正式开源，在外部推动多套利用治理平台基于 OAM 和 KubeVela 演进。并推动了三位一体策略，不仅阿里外部的外围零碎全面应用这套技术，而且在面向客户的商业化云产品以及在开源时，都应用同样的技术。通过全面拥抱开源，让整个 OAM 和 KubeVela 社区参加共建。在这段摸索历程中，咱们走了不少弯路，也累积了许多踩坑教训，接下来将作具体介绍，同时分享 KubeVela 的设计原理和应用办法，帮忙开发者理解云原生利用治理平台的残缺解决方案，进步利用开发者的应用体验和利用交付效率。

云原生利用治理平台的解决方案

在摸索云原生利用治理平台解决方案的过程中，咱们次要遇到 4 项重大挑战，并总结了 4 个根本准则，下文将一一介绍。

挑战 1：不同场景的利用平台接口不对立，反复建设。

尽管，云原生有了 Kubernetes 零碎，但在不同场景它会构建不一样的利用平台，且接口齐全不对立，交付能力存在很大差别，比方 AI、中间件、Serverless 和电商在线业务都有各自不同的服务平台。因而，在构建利用治理平台时，不免反复开发和反复运维。最现实的情况当然是实现复用，但运维平台架构模式各有不同，没方法做到互通。另外，业务开发者在不同场景对接利用交付时，对接的 API 齐全不同，交付能力存在很大差别。这是咱们遇到的第一个挑战。

挑战 2：“面向终态”无奈满足过程式的交付形式。

在云原生时代，面向终态的设计很受欢迎，因为它能缩小使用者对实现过程的关怀。使用者只须要形容本人想要什么，不须要具体布局执行门路，零碎就能主动把事件做好。但在理论应用过程中，交付过程通常须要审批、暂停察看、调整等人为干涉。举个例子，咱们的 Kubernetes 零碎在交付过程中处于强管护的状态，要审批公布。在《阿里团体变更治理标准》中明确“线上变更，前 x 个线上生产环境批次，每个批次变更后察看工夫应大于 y 分钟。”“必须先在平安生产环境（SPE）内进行公布，只有在 SPE 验证无问题后，能力在线上生产环境进行灰度公布。”因而，利用交付是一个面向过程而非面向终态的执行流程，咱们必须思考，怎么让它更好地适应面向过程的流程。

挑战 3：平台能力扩大复杂度太高。

上文提到，传统模式下的利用平台扩展性差，那么在云原生时代，有哪些常见扩大平台的机制？在 Kubernetes 零碎中，能够间接用 Go Template 等模板语言做部署，但毛病是灵活性不够，整个模板写下来结构复杂，难以做大规模的保护。有些高手可能会说“我能够自定义一套 Kubernetes Controller，扩展性肯定很好！”没错，然而，理解 Kubernetes 及 CRD 扩大机制的人比拟少。即便高手把 Controller 写进去了，他还有后续的许多工作要做，比方须要编译并将其装置在 Kubernetes 上运行，另外，Controller 数量也不能始终这样收缩下来。因而，要想做一个高可扩大的利用平台有很大挑战。

挑战 4：不同环境不同场景，交付差别微小。

在利用交付过程中，对于不同用处的环境，其运维能力差异特地大。比方开发测试环境，器重开发和联调效率，每次批改采纳热加载，不从新打包、走镜像部署的一套流程，同时为开发人员部署按需创立的独立环境。再比方预发联调环境，有攻防演练、故障注入的日常运维诉求。以及在生产环境，须要退出平安生产、服务高可用方面的运维能力。此外，同一个利用，组件依赖也有微小差别，数据库、负载平衡、存储，在不同云上存在诸多差别。

针对以上四项挑战，咱们总结了古代利用治理平台的 4 点外围设计准则：

1. 对立的、基础设施无关的凋谢利用模型。

2. 围绕工作流的申明式交付。

3. 高度可扩大，易编程。

4. 面向混合环境的设计。

准则 1：对立的、基础设施无关的凋谢利用模型。

怎么提炼对立的、基础设施无关的凋谢利用模型呢？以凋谢利用模型，即 OAM 为例，首先，它的设计非常简单，且可能大幅简化咱们对治理平台的应用：原来使用者要面对上百个 API，OAM 将其形象成 4 类交付模型。其次，OAM 从业务开发者视角形容要交付的组件，要用到的运维能力和交付策略，由平台开发者提供运维能力和交付策略的实现，从而对开发者屏蔽基础设施细节与差异性。通过组件模型，OAM 能够用来形容容器、虚拟机、云服务、Terraform 组件、Helm 等制品。

图 2 用凋谢利用模型形容的一个利用交付示例

如图 2，这是用 OAM 形容的一个 KubeVela 利用交付示例，外面蕴含上述 4 类模型。首先，要形容一个利用部署时蕴含的待交付组件（Component），个别是镜像、制品包、云服务等模式；其次，要形容利用部署后用到的运维能力（Trait），比方路由规定、主动扩缩容规定等，运维能力都作用于组件上；再次，是交付策略（Policy），比方集群散发策略、健康检查策略、防火墙规定等，任何一个部署前须要恪守的规定都能够在这个阶段申明和执行；最初，是工作流（Workflow）的定义，比方蓝绿部署、带流量的渐进式部署、手动审批等任意的管道式继续交付策略。

准则 2：围绕工作流做申明式的交付。

下面 4 类模型中最外围的是工作流，利用交付实质上是一次编排，将组件、运维能力、交付策略、工作流步骤等按程序定义在一个有向无环图 DAG 外面。

图 3 KubeVela 通过工作流编排利用交付的示例

举个例子，利用交付前的第一步，比方装置零碎部署依赖、初始化查看等，通过交付策略形容并在交付最开始的时候执行；第二步是依赖的部署，比方利用依赖了数据库，咱们能够通过组件创立相干的云资源，也能够援用一个已有的数据库资源，将数据库连贯串作为环境参数注入到应用环境中；第三步是用组件部署利用自身，包含镜像版本、凋谢端口等；第四步是利用的运维能力，比方设置监控形式、弹性伸缩策略、负载平衡等；第五步是在线上环境插入一个人工审核，查看利用启动是否有问题，人工确认没问题之后再持续让工作流往下走；第六步是将剩下的资源并行部署完，而后通过钉钉音讯做回调，将部署完的音讯通知开发人员。这就是咱们在实在场景中的交付流程。

这个工作流最大的价值在于，它把一个简单的、面向不同环境的交付过程通过标准化的程序，较为标准地形容了进去。

准则 3：高度可扩大、易编程。

咱们始终心愿可能像乐高积木一样构建利用模块，平台开发者能够应用平台的业务开发轻松扩大利用平台的能力。但前文提到，用模板语言这种形式，灵活性不够、扩展性有余，而写 Kubernetes Controller 又太简单、对开发者的业余能力要求极高。那怎么能力既有高度可扩展性，又有编程的灵活性？咱们最初借鉴了谷歌 Borg 的 CUElang，这是一个适宜做数据模板化、数据传递的配置语言。它人造适宜调用 Go 语言，很容易与 Kubernetes 生态交融，具备高灵活性。而且 CUElang 是动静配置语言，不须要编译公布，响应速度快，只有将规定公布到 Kubernetes，就立马失效。

图 4 KubeVela 动静扩大机制

以 KubeVela 的动静扩大机制为例，平台开发者编写完 Web 服务、定时工作等组件模板，以及弹性伸缩、滚动降级等运维能力模板后，将这些能力模板（OAM X-Definition）注册到对应的环境。KubeVela 依据能力模板内容将能力运行时须要的依赖装置到对应环境的集群上。此时，利用开发者就能够应用平台开发者方才编写的这些模板，他通过抉择组件和运维能力构建出一个利用 Application yaml，并将 yaml 公布到 KubeVela 管制面上。KubeVela 通过 Application yaml 编排利用，运行对应选取的能力模板，最终把利用公布到 Kubernetes 集群中。整个从能力定义、利用形容，到最终实现交付的过程就实现了。

准则 4：面向混合环境的设计。

在 KubeVela 设计之初，咱们就思考到将来可能是在混合环境（混合云 / 多云 / 分布式云 / 边缘）中做利用的交付，且不同环境、不同场景的交付差别较大。咱们做了两件事。第一，将 KubeVela 管制立体齐全独立，不入侵业务集群。能够在业务集群中应用任何来自社区的 Kubernetes 插件运维和治理利用，由 KubeVela 负责在管制立体治理和操作这些插件。第二，不应用 KubeFed 等会生成大量联邦对象的技术，而是间接向多集群进行交付，放弃和单集群治理统一的体验。通过集成 OCM/Karmada 等多容器集群治理计划反对 Push 和 Pull 模式。在地方管控、异构网络等场景下，KubeVela 能够实现平安集群治理、环境差异化配置、多集群灰度公布等能力。

以阿里云外部边缘计算产品的计划为例，开发人员只需将编写的镜像和 KubeVela 的文件间接公布到 KubeVela 管制立体，管制立体会将利用组件散发到核心托管集群或边缘集群。边缘集群能够采纳 OpenYurt 等边缘集群治理计划。因为 KubeVela 是多集群对立的管制立体，所以它能够实现利用组件的对立编排、云 - 边集群差别配置，以及汇聚所有底层的监控信息，实现对立可观测和绘制跨集群资源拓扑等目标。

总结

总的来说，上述 4 个 KubeVela 外围设计准则能够简略囊括为：

1．基于 OAM 形象基础设施底层细节，用户只须要关怀 4 个交付模型。

2．围绕工作流的申明式交付，工作流无需额定启动过程或容器，交付流程标准化。

3．高度可扩大、易编程：将运维逻辑用 CUE 语言代码化，比模板语言更灵便，比写 Controller 简略一个量级。

4．面向混合环境的设计，提供环境和集群等围绕利用的概念形象，对立管控所有利用依赖的资源 (蕴含云服务等)。

图 5 KubeVela 在阿里云原生基础设施的地位

目前，KubeVela 曾经成为阿里云原生基础设施一部分。从图 5 可见，咱们在 Kubernetes 之上做了很多扩大，包含资源池、节点、集群治理能力，对工作负载和自动化运维能力也做了很多反对。KubeVela 在这些能力之上做了一层对立的利用交付和管理层，以便团体业务可能实用不同场景。

将来云原生将如何演进呢？回顾近十年的云原生倒退，一个不可逆转的趋势是标准化界面一直上移。为什么？从 2010 年左右云计算锋芒毕露到现在站稳脚跟，云的算力失去遍及；2015 年前后容器大范畴铺开，带来了交付介质的标准化；2018 年左右，Kubernetes 通过对集群调度和运维形象，实现了基础设施治理的标准化；近两年 Prometheus 和 OpenTelemetry 逐步让监控走向对立，Envoy/Istio 等 Service Mesh 技术在让流量治理更加通用。从这些云原生倒退历程中，咱们看到了云原生畛域技术碎片化和利用交付复杂性的问题，提出凋谢利用模型 OAM 并开源 KubeVela 试图解决这个问题。咱们置信，应用层标准化将是云原生时代的趋势。

作者介绍：

司徒放，花名“姬风”|阿里云资深技术专家，阿里云利用 PaaS 及 Serverless 产品线负责人。2010 年退出阿里巴巴后始终深度参加服务化和云原生架构的屡次跨代演进，如链路跟踪、容器虚拟化、全链路压测、异地多活、中间件云产品化、云原生上云等。负责并主导了阿里巴巴在微服务、可观测性、Serverless 等畛域的开源技术和商业化产品建设，致力于通过云原生技术，为内部企业提供成熟稳固的互联网架构解决方案和产品。参加或主导设计的开源我的项目包含 KubeVela、Spring Cloud Alibaba、Apache Dubbo、Nacos 等。

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