开发人员与运维人员是 IT 畛域很重要的两大人群，他们都会参加到各种业务零碎的建设过程中去。DevOps 是近年间火爆起来的一种新理念，这种理念被很多人谬误的解读为“由开发人员（Dev）学习一大堆新的技能，从而把握运维人员（Ops）该解决的事件”。然而能力越大，责任越大，当维持生产环境稳固为要位的运维责任落到开发人员的肩头时，少数程序员收回了 扯淡的 DevOps，咱们开发者基本不想做运维! 的吆喝。那么在云原生时代，到底应该怎么达成 DevOps 的体验呢？我的观点是由平台工程来连接这两大人群，各自做好各自畛域的事件。
令人“讨厌”的 DevOps
首先，我十分心愿你能先看一看引言中提到的 扯淡的 DevOps，咱们开发者基本不想做运维! 这篇文章。这篇文章从亚马逊云科技社区参加负责人 Emily Freeman 的一条推特动手，察看了很多留言后，得出了文章题目这种相似怒吼个别的论断。从绝大多数回复这条推特的 IT 从业者的口中，我听到了对于将运维职责强加给开发人员这种 DevOps 体验疾恶如仇。
开发人员对于“谁构建，谁运行”这种正气凛然的话示意无感，对于学习运维畛域的新技能，亦或是将本人退出轮班反对人员的行列都感觉力不从心；运维人员的本职工作被剥离之后，则对本业余的前景惶惶不安，会胆怯运维团队的从新洗牌。
开发与运维，的的确确是两个不同的工种，有着相似“车床工与管道工”的区别。
| 开发人员 | 运维人员 | |
|---|---|---|
| 专业技能 | 开发语言、开发框架、中间件、数据库 | 硬件、操作系统、网络、存储、虚拟化 |
| 日常工作 | 了解需要、开发文档写作、开发代码 | 装置部署、监控、日志、问题排查、变更 |
| 文化标签 | 自在、发明 | 激进、责任 |
一些公司认为从表格中把大量的运维人员管辖的工作，一股脑的“左移”给开发人员就是 DevOps。在专业技能和日常工作畛域带来的缺口，能够通过开发人员的勤奋学习加以补足，然而在文化标签畛域的抵触，将会是导致开发人员讨厌这种 DevOps 体验的根本原因。
DevOps 的真意与平台工程
在我看来，DevOps 的真意是利用软件工程思维，解决简单且沉重的运维问题。真正适宜做 DevOps 工作的人，是具备肯定软件工程能力的运维专家，在这里，对运维能力的要求更重要。
DevOps 工程师，能够通过设计或抉择一款平台产品，来将简单的运维工作形象为产品化的运维特色。从这个角度上讲，开发人员将会是这个平台产品的用户，他们可能在不理解简单基础设施的状况下，操作并保护应用程序。DevOps 工程师，应该是更懂开发人员需要的运维工程师 。
在追根溯源，找到了这条推特之后，我理解到了更多 IT 业内人士对 DevOps 的认识，从中找到了很多和我有共鸣的声音。
To me that’s a sign we haven’t made ops intuitive/easy enough for most devs to be able to handle it.
对我来说，这表明咱们还没有让运维变得足够直观 / 简略，以至于大多数开发人员都无奈解决它。
—— @Liz Fong-Jones (方禮真)
The “platform” should do the heavy lifting ops, lacking a real platform the ops team (DevOps/are/platform team) is the platform. Devs can then focus on the application level operations of their apps using the knobs and levers provided by the platform.
“平台”应该做沉重的运维，不足真正的平台时运维团队就是平台（DevOps/are/platform team）。而后，开发人员能够应用平台提供的旋钮和杠杆专一于其应用程序的应用程序级操作。
—— @pczarkowski
IT 行业近年来的发展趋势，始终是一直以平台能力的晋升，来解决简单基础设施的应用问题的。最开始，程序开发人员须要面对的是一台物理服务器，在不足运维能力的状况下，会由运维人员解决无关服务器的所有，包含操作系统、网络配置等等。而到当初，程序开发人员曾经很少须要跟服务器打交道，甚至我见过的很多程序员并不把握任何无关命令行的常识，就能够面向服务器开发利用零碎。这种转变让程序开发人员更加专一于业务代码自身，不用分神去做一些沉重且琐碎的运维事务。带来这种转变的，是处于倒退过程中的平台工程，在让基础设施一直变得简略易用。
最原始的裸机时代，并没有开发运维之分。从底层基础设施，始终到最顶层的业务零碎都是同一批人在解决，这一批老程序员能够被称为真正的全栈工程师。但毫无疑问，每一个开发人员，都心愿可能抛却运维工作，更专一于本人开发的代码。
云计算时代的衰亡以虚拟化技术为根底，软件定义基础设施变得煊赫一时起来。运维人员通过建设并保护一套 IaaS 云平台，将计算资源进行池化。开发人员按需申请本人须要的虚拟机，从而失去一个操作系统界面来进行交互。与操作系统打交道，对开发人员仍然是个微小的挑战，在 IT 畛域，操作系统就像一座沉没在海上的冰山，看似只露出冰山一角，然而其宏大的常识畛域“身躯”都暗藏在海平面以下。和裸机时代相比拟，开发人员和运维人员曾经是两个齐全不同的群体，开发人员曾经能够将本人的大部分精力放在业务零碎上了。值得一提的是，对操作系统的掌控是不折不扣的运维畛域技能。
容器技术以及 Kuberentes 的横空出世，成为了云计算时代的分水岭。软件定义基础设施的技术手段曾经被施展到了极致，并且成为了现阶段运维人员的标配技能。运维人员通过建设并保护一套 PaaS 云平台，终于将操作系统这一座最初的“大山”从开发人员的身上搬开。开发人员能够将更多的精力放在业务零碎上了，除了他们仍然须要学习容器技术和 Kubernetes，至多他们要学会如何面向 Kubernetes 编写业务零碎所需的申明式配置文件。运维人员也通过 PaaS 云平台失去了本人想要的能力，容器技术和 Kubernetes 为他们带来了弹性、便捷性的微小晋升。
追随时代的变迁，我得出了一个论断： 从开发人员与运维人员的关系上来看，IT 畛域的演变，就是运维人员通过一直向上接手开发人员眼中“跟开发无关的杂活”，来一直为开发人员减负。开发人员在失去了解放后，能够将视角更多的聚焦在本人开发的业务零碎上，开释出本人的创造力。
那么追随论断中的趋势，解放开发人员累赘的脚步相对不会进行。DevOps 的工作，就是以开发人员为用户群体，打造一套能够让开发人员毫无阻碍的应用基础设施的“云原生平台“。
云原生是一种面向云设计利用的思维理念，充分发挥云效力，组织内 IT 人员相互协作构建弹性牢靠、松耦合、易治理、可观测的云利用零碎，最终目标是晋升软件交付效率，升高运维复杂度。相比上文中提到的 PaaS 平台，起码要可能防止开发人员去编写简单的 Kubernetes 申明式配置文件。
现有开源产品状况
在云原生平台畛域，曾经有不少我的项目在深耕。在这里我列举了三个各具特色的云原生畛域的平台级产品：Rancher、KubeSphere、Rainbond，后续的具体设计思路中，也会关注已有产品的实现。
这三款开源产品中，Rancher 是元祖级容器治理平台，退出 SUSE 后，可能显著感觉在云原生生态畛域一直发力，Rancher 在各个档次能够集成的云原生畛域工具集曾经十分丰盛。Rancher 专一于帮忙 DevOps 团队面对多集群状况下的运维和平安挑战，从这一点来说，Rancher 更偏差于运维人员的应用体验，而非面向开发人员提供更高的易用性。
KubeSphere 是来自青云的“面向云原生利用的 容器混合云”。除了对 Kubernetes 集群内的各种资源的治理能力之外，Kubesphere 主打即插即用的插件式生态扩大能力。
Rainbond 由北京好雨科技出品，从其介绍来看，它是一款主打易用性的云原生多云治理平台。
升高业务部署难度
诚恳地讲，为古代开发语言开发而来的业务零碎制作容器镜像并不是什么难以把握的技能。然而不可否认的是，绝大多数 IT 从业人员仍然会将制作镜像这件事件归为运维人员治理，而不是开发人员要关怀的事件。
那么 DevOps 工程师就有必要思考，如何在开发人员对容器技术无所不知的状况下，使之能够间接从代码开始部署业务零碎。
在这个方面，Heroku 是无可争议的先行者。Heroku 是一个反对多种编程语言的云平台即服务产品。在 2010 年被 Salesforce.com 收买。Heroku 作为最元祖的云平台之一，从 2007 年 6 月起开发，过后它仅反对 Ruby，但起初减少了对 Java、Node.js、Scala、Clojure、Python 以及 PHP 和 Perl 的反对。
开发人员在应用云原生平台时，只须要在界面中填写代码仓库的地址，对应的用户名明码等根底信息，就能够期待代码构建成为镜像，并自在的运行在 Kubernetes 云环境中去。
现有开源产品也在这方面给予了肯定的反对：
| Rancher | KubeSphere | Rainbond | |
|---|---|---|---|
| 实现形式 | 通过集成 Epinio 我的项目，继而深刻集成了 Paketo Buildpacks 来实现源码构建 | 提供定制化的根底镜像来联合用户代码构建我的项目 | 基于 Heroku buildpack 定制的源码构建能力 |
| 反对语言类型 | Java、GraalVM、Golang、.NetCore、Nodejs、PHP、Ruby、Python | Java、Nodejs、Python | Java、Golang、.NetCore、Nodejs、PHP、Python、Html 动态 |
| 应用体验 | 全副命令行操作，应用简单 | 图形化操作，间接提供代码地址，构建产出镜像，进而部署业务 | 图形化操作，提供代码地址即可实现构建与部署，构建参数可配置，自由度高 |
更进一步的设计，是将代码的提交、检测、部署等流程都集成到 CI/CD 流水线中去，开发人员只须要进行代码的提交，后续的流程会主动触发实现，生成检测报告，并实现代码的上线部署。而与之相干的第三方工具集，由 DevOps 团队负责进行保护，开发人员能够充沛的发挥拿来主义——拿来用就好。
在这方面 KubeSphere 做的更加全面，通过集成 Jenkins 实现了基于图形化的流水线配置，这种形式对于以前就在应用 Jenkins 的团队很敌对。并且这种实现继承了 Jenkins 生态原有的高自由度，能够更好的将其余第三方 CI 工具纳入流程之中。
Rainbond 通过在构建流程中退出自制的主动触发能力，也能够实现局部流水线工作。这种配置绝对编写 Jenkinsfile 来说更简略一些，可能满足一些根本场景。然而其扩展性和自由度有余，可能接收的第三方 CI 工具不够丰盛。
Rancher 并没有在产品中集成 CI 方面的能力，在 CD 方面通过集成 fleet 我的项目来实现 GitOps，应用的门槛较高。
这样的应用体验还有一个长处，从始至终都不须要开发人员去编写格局严苛的 Kubernetes 申明式配置文件。这对开发人员而言无疑是一个极大的利好，Kubernetes 虽好，但学习曲线十分平缓。Kubernetes 默认通过 yaml 格局的申明式配置文件来部署业务零碎，其中绝大多数的字段定义都是运维特色的体现，换句话说，绝大多数的字段定义，都不应该是开发人员关注的事件。
DevOps 工程师应该抓住开发人员应用 Kubernetes 的痛点，防止其接触简单运维事务。云原生平台理当提供这种应用体验，让开发人员对 Kubernetes 齐全无感知的状况下，实现业务零碎的部署工作。换句话说，让 Kubernetes 变得对开发人员“通明”。
从这个方面来说，通过对三款开源云原生平台的体验，发现 Rancher 和 KubeSphere 虽说均能够基于图形化界面来部署本人的业务组件，然而这些图形化配置只是 yaml 申明式配置文件的“翻译”，对于 Kubernetes 不够相熟的用户想要顺利应用，还是有肯定的门槛。Rainbond 这一点则做的十分不错，部署业务时齐全感触不到 Kubernetes 的存在，对于不相熟 Kubernetes 的用户而言十分敌对。然而产品化定制的水平越高，追随 Kubernetes 后退的脚步就越难，上游 Kubernetes 一直在推出新的性能个性，如何将新个性形象成为用户易于了解的性能将会是个挑战。最新版本的 Rainbond 推出了 Kubernetes 属性这一性能个性，容许用户以 yaml 模式编辑 workload，也是为突破自设的“天花板”。
升高操作基础设施的难度
既然要设计一款平台级的软件产品，那么就须要将简单且不易被把握的技术，形象成为用户易于了解的性能。DevOps 工程师设计的云原生平台产品，首要任务之一，是可能升高开发人员应用基础设施的门槛。这个章节次要探讨的，是开发人员自行治理本人业务零碎的运维特色。
就拿存储这件事来说，开发人员到底关注什么呢？
围绕存储这个概念，咱们能够说出一堆名词，块设施、文件系统、对象存储、本地磁盘、磁盘阵列、NFS、Ceph 等等。这些名词毋庸置疑都与存储相干，也确实会被各种业务零碎所应用，但我置信，绝大多数的开发人员对这些名词并不关怀。
作为用户，开发人员只关怀一件事件，我所负责的业务零碎，指定目录中的数据须要被长久化的保留下来。
大多数状况下，业务零碎波及到的存储场景都应该是简略的。在云原生时代，咱们甚至呐喊开发人员在开发业务零碎的时候，应该尽量做到“无状态化”，即在业务零碎中，不存在限度实例横向扩容的状态数据，至多做到不同实例之间，数据能够共享。依据这一点，DevOps 工程师们齐全能够为开发人员提供一个可能适应大多数场景的默认存储类型，各个云厂商提供的 NAS 类型存储是个很好的抉择。
应用简单存储的场景更多见于业务零碎所调用的各种中间件中，比方数据库须要高速稳固的块设施类型存储，再比方大数据畛域的“存算拆散”场景下对接对象存储等等。然而在大多数场景下，这些简单中间件的保护并不是开发人员应该关怀的事件。它们由专门的运维人员进行保护，开发人员只须要失去拜访它们的地址即可。
所以在这种简略存储场景下，开发人员最好能够仅仅填写一下本人须要被长久化的目录地址，由云原生平台来实现底层存储的配置。对存储基础设施的操作，开发人员并不需要关怀。
从应用体验上来说，Rancher 和 KubeSphere 可抉择的存储类型很多，这是因为它们的产品生态优于 Rainbond，比方 Rancher Lab 间接推出了轻量级的存储解决方案 Longhorn，对于各大公有云厂商提供的存储产品驱动也都有集成。Rainbond 仍然在易用性方面做的够好，实现了上文中仅关注业务零碎长久化目录的应用体验。然而仅对 NFS 类型的存储反对比较完善，对于其余类型的存储反对，须要在底层基础设施中自建驱动，装置起来不如前二者不便。
易于了解的利用模型
从工作负载层面上讲，Kubernetes 只通过 Deployment、Statefulset 等形象形容单个组件的特色，然而少数状况下，开发人员开发出的业务零碎会蕴含若干微服务组件。那么如何对整个业务零碎进行对立的治理就变成了一个问题。解决方案之一，就是通过云原生利用平台，在单个组件之上，形象出利用这个概念。利用应该是由人为规定的一组服务组件（workload）组成，服务组件之间具备显式或隐式的关联调用关系，彼此之间有机组合成为一个整体，作为一套残缺的业务零碎对外提供服务。
开发人员能够将所有的服务组件视作一个整体来进行治理，而非机械的独自治理每一个服务组件，这种操作体验无疑会更简略，也便于开发人员了解。对利用的治理能够包含对立的生命周期治理、对立的装置降级卸载，灵便拼装服务组件之间的调用关系，更正当的解决业务零碎的交付流程。
目前 Kubernetes 畛域内较为成熟的交付工具 Helm，其设计也暗合此类模型，一条简略的 helm install xxx 命令，即可装置起一大堆组件以及围绕这些组件的配置。
Rancher 并没有实现本人的利用模型，其利用的装置形式集成了 Helm，并没有体现出利用治理能力。
KubeSphere 则更进一步，在我的项目下的利用负载中提出了利用的概念。在利用中能够通过 Helm 或自建的模式部署服务，集成了微服务治理、单个组件的版本控制、路由治理、灰度公布等能力。其对 Helm 模板的反对，使得其从实践上能够反对任何市面上已有的 Helm Chart 包的装置部署。
Rainbond 的利用概念是最欠缺的，除了惯例的生命周期操作、整个利用级的版本控制这样的惯例能力之外，还有些十分易用的自研性能，可能简化开发人员对本人利用的治理。比方基于泛解析域名机制实现的对外服务域名，点击开启对外服务，就会生成一个公网可用的域名拜访本人的利用，这比一层一层的配置 Ingress 规定容易太多。又比方利用复制能力，能够批量的将整套利用复制到另一个工作空间，而不用从新手动搭一套。
利用模板是 KubeSphere 和 Rainbond 均提出的一个概念，利用模板存在的意义是能够将开发好的利用复制到不同的环境中去，是一种制备新一代制品并交付散发的技术。利用模板的根底应用体验，是能够疾速不便的装置整套利用零碎，最好是一键化的体验，KubeSphere 和 Rainbond 都提供了利用商店，供用户疾速装置一些曾经制作好的利用模板。利用模板更高层次的应用体验，则是开发人员能够无任何技术累赘的开发出本人的利用模板，而不仅仅是从利用商店拉取他人制作好的利用模板。
易于掌控的微服务架构
微服务架构也是云原生平台不可短少的一个元素。微服务架构旨在帮忙开发人员建设高类聚、低耦合的古代利用零碎，将以往烟囱式的业务零碎架构，拆散成为一大堆彼此间更为独立，蕴含本身性能特点的微服务模块。容器与相干编排技术的成熟，为微服务架构的落地打下了根底。云原生利用平台，则为开发人员更简略的动手微服务框架提供了可能。
云原生平台首选的微服务框架，应该是以 Istio、Linkerd 为代表的 Service Mesh 微服务框架，也被称为“服务网格”。绝对于 Spring Cloud、Dubbo，这种微服务框架提供了更高的自由度和适应性，开发人员不须要被某种开发语言或产品绑定，只须要回归网络编程即可将本人的业务零碎连贯成为一个整体。这里要重点提出的是微服务架构对业务代码无侵入，只有无侵入的实现，能力最大限度升高开发人员破费精力学习其余畛域常识的可能性。
DevOps 工程师能够通过设计云原生平台性能来进一步优化配置微服务的应用体验，大胆构想一下，开发人员只须要在两个服务组件之间拖动一条表征微服务调用关系的线，就能够生成对应的微服务配置。这样的操作体验齐全能够使注册核心、管制立体这种微服务畛域中简单的概念对开发人员屏蔽。实质上讲，保护注册核心或者管制立体也是运维人员须要关怀的工作。
Rancher 因为其本身的定位，产品中没有集成任何微服务相干的能力，用户须要手动装置 Istio 等微服务框架，通过简单的 yaml 配置，来援用微服务能力。
KubeSphere 和 Rainbond 都在利用层面默认集成了 Service Mesh 微服务框架，不同之处是前者集成了 Istio 计划，而后者的 Service Mesh 微服务框架是自研的。从应用体验上来说，KubeSphere 产品化的包装了 Istio，大幅度降低了 Istio 的应用体验，但这不意味着用户能够齐全抛却 Istio 这一层的概念，利用外部的拓扑依附当时的配置来体现。Rainbond 自研的微服务框架易用性更高一些，曾经实现了利落拽式的微服务拼装模式，这一点还是很惊艳的。然而本人造的轮子过多，内部的其余计划有好的个性时想要疾速集成接收，就须要在微服务标准的对接档次更上层楼，毕竟 Istio、Linkerd 这些 Service Mesh 微服务框架一统江湖的状况下，其余生态的联合都会以它们为规范，而非自研框架。目前 Rainbond 也提供集成形式接收了 Istio 治理模式，但还没有失去大量用户的应用验证。
对运维人员敌对
之前的探讨，都是以开发人员为受众去考量的，但咱们不应该遗记保护着底层基础设施失常工作的运维人员。任何软件的稳固运行都只是临时的，出问题只是一个工夫问题。云原生平台自身作为开发人员的基础设施，也须要被继续的保护。如何优化运维人员的治理体验，也是在云原生平台设计过程中的重点。
当今时代，Kubernetes 的应用与保护、容器化技术都曾经成为了运维人员的标志性技能，对操作系统的掌控以及命令行工具的应用则是运维人员的看家本领。所以云原生平台在面向运维人员的设计中，不必要在易用性或图形化上思考过多，更多要思考的是可靠性、安全性、底层基础设施生态的兼容性。
Rancher 在运维层面的体现十分出众。得益于其丰盛的周边生态，Rancher 在各个领域都失去了自家其余产品的原生反对。首当其冲的就是 RKE/RKE2/K3S 这几个 kubernetes 发行版，升高了不同场景下 Kubernetes 的装置难度。容器平安方面有 NeuVector 容器平安平台负责全生命周期的治理。基础设施方面有轻量级分布式块设施存储系统 Longhorn。除了丰盛的生态之外，Rancher 产品界面的设计尤其合乎运维人员的爱好。集体体验过程中认为 Kubectl Shell 十分惊艳，这是一个分屏式的命令行操作界面，运维人员能够一边在下半分屏 Shell 交互分页中敲命令，上半分屏中实时察看操作后果。
KubeSphere 也比拟适宜运维人员保护和治理。尤其是在监控报警层面，KubeSphere 制作了大量合乎本身产品理念的可观测性图表，体验很不错。对于集群或节点的管制也做了图形化的设计，便于运维人员掌控。生态方面，KubeSphere 背靠青云，也在一直倒退围绕本身的云原生我的项目，能够利用自家的驱动对接青云的云平台、云存储，以及负载平衡等基础设施。其内置的可插拔式的组件管理系统，能够疾速扩大出平台级的其余能力。
Rainbond 对运维人员不太敌对，甚至是一种“忘记”了运维人员的设计理念。体验之后发现所有的运维操作仍然离不开登录服务器这个前提。没有提供图形化亦或者命令行交互界面来操作集群和节点。对接多集群时，提供了图形化装置 Kubernetes 集群继而装置 Rainbond 的能力，体验还算不错。产品生态相较 Rancher 不够丰盛，好在官网提供了很多文档撑持，来对接很多其余的云原生生态产品。比方提供文档对接阿里云 ACK、华为云 CCE、腾讯云 TKE 等云基础设施的装置形式。
在用户权限治理方面，Rancher、KubeSphere 沿用了 Kubernetes RBAC 这一套体系，Rainbond 仍然有些特立独行，权限管理体系并没有齐全对照原生 Kubernetes RBAC 设计，甚至在应用 Rainbond 的时候，齐全没有感觉到有 RBAC 体系的存在。对接内部的身份管理系统时，KubeSphere 主推 LDAP 协定，而 Rainbond 应用了 Oauth2.0 协定的实现。
其余方面，诸如稳定性、行为审计、监控报警方面三款产品各自有实现，没什么太大的区别。
写在最初
绝对于招聘文武全才的“全栈式”开发人员搞定所有的 IT 事务，我更偏向于找到不同畛域的专家来搞定各自畛域的问题。在运维事务的畛域里，构建并保护一套性能完备的云原生平台，可能更好的解决 IT 业务零碎从底层基础设施到开发过程，最终达到生产上线的运维反对问题。这是对 DevOps 理念比拟正当的一种落地形式。
文中重点提到了 Rancher、KubeSphere、Rainbond 这三款云原生平台级产品各自不同的实现。
归纳起来，Rancher 更偏差运维人员应用，来治理企业外部的各类 Kubernetes 基础设施。开发人员想要很好的应用 Rancher，必须具备 Kubernetes 操作能力以及容器化技术。从这个角度来说，Rancher 的定位应该位于 PaaS 与云原生平台之间。
KubeSphere 和 Rainbond 都属于以利用为核心的云原生平台产品，二者的设计思路不同之处见仁见智。KubeSphere 以可插拔式框架纳入了云原生畛域的其余我的项目为己所用，将这些我的项目的能力串联起来为最终用户提供一站式的应用体验，然而这样的应用体验必然是有门槛的，每纳入一个我的项目，最终用户不免须要同时学习该我的项目和 KubeSphere 本身。Rainbond 的设计思路则更加的内聚，少数性能都自研。这样做的益处是性能体系高度自我符合，最终用户的应用体验十分好，性能之间连接关联更合乎人类思维，却容易自我限定，进步了纳入其余云原生生态的门槛。
DevOps 团队能够间接抉择既有的云原生平台级产品应用，也能够基于开源我的项目二次开发。更落地的形式是抉择其中多款进行混合部署，各取所长，以提到的三款产品为例，DevOps 团队齐全能够抉择 Rancher + KubeSphere 或 Rancher + Rainbond 的组合，它们之间并没有抵触，向下对接基础设施，治理集群的安全性与合规性是 Rancher 最善于的事件，向上为最终开发人员进步易用的云原生平台的应用体验则交给 KubeSphere 或 Rainbond，最终的指标，是开发人员通过云原生平台的反对，从以往的运维工作之中解放出来，将精力更多的放在所开发的业务之上。