继续创作，加速生长！这是我参加「日新方案 10 月更文应战」的第1天，点击查看活动概况
开发人员与运维人员是 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，终究的方针，是开发人员经过云原生渠道的支撑，从以往的运维作业之中解放出来，将精力更多的放在所开发的事务之上。
