最近因为工作须要，须要找一个功能完善的云原生利用平台，通过本人筛选和敌人举荐，剩下 KubeSphere和Rainbond ，这两个产品都是基于 Kubernetes 之上构建的云原生利用平台，性能都十分弱小，但产品定位和性能偏重不同，本文将介绍我在选型过程中从各维度比照两款产品的过程记录。
产品定位比照
KubeSphere 是在 Kubernetes 之上构建的面向云原生利用的分布式操作系统，齐全开源，反对多云与多集群治理，提供全栈的 IT 自动化运维能力，简化企业的 DevOps 工作流。作为全栈的多租户容器平台，KubeSphere 提供了运维敌对的向导式操作界面，帮忙企业疾速构建一个弱小和功能丰富的容器云平台。KubeSphere 为用户提供构建企业级 Kubernetes 环境所需的多项性能，例如多云与多集群治理、Kubernetes 资源管理、DevOps、利用生命周期治理、微服务治理（服务网格）、日志查问与收集、服务与网络、多租户治理、监控告警、事件与审计查问、存储管理、拜访权限管制、GPU 反对、网络策略、镜像仓库治理以及平安治理等。
Rainbond 是一个云原生利用治理平台，应用简略，不须要懂容器、Kubernetes和底层简单技术，反对治理多个Kubernetes集群，和治理企业应用全生命周期。次要性能包含利用开发环境、利用市场、微服务架构、利用交付、利用运维、利用级多云治理等。Rainbond 遵循 以利用为核心的设计理念，对立封装容器、Kubernetes和底层基础设施相干技术，让使用者专一于业务自身, 防止在业务以外技术上破费大量学习和治理精力。
| KubeSphere | Rainbond | |
|---|---|---|
| Slogan | 面向云原生利用的混合云平台 | 云原生多云利用治理平台 |
| 形象 | 容器和K8s概念和形象为主，利用级形象为辅 | 利用级形象 |
| 定位 | 面向懂K8s相干技术的运维和开发 | 面向所有运维和开发，平台治理须要懂K8s |
因为产品形象不同，体现进去的概念和流程也有很大差别，KubeSphere次要是Kubernetes相干概念和形象，应用和治理都须要懂Kubernetes相干体系常识，懂Kubernetes的人能疾速上手，Rainbond利用级形象，应用门槛很低，面向不懂Kubernetes的一般开发人员，平台治理跟KubeSphere一样都须要懂Kubernetes。
开源社区活跃度比照
| KubeSphere | Rainbond | |
|---|---|---|
| 社区活跃度 | 论坛、微信群都沉闷 | 微信 钉钉沉闷 |
| Stars | 11003 | 3451 |
| 文档成熟度 | 很全面 | 很全面 |
| 版本迭代 | 近一年迭代了4个版本 | 近一年迭代了8个版本 |
| 开源 | 100% 开源 | 100% 开源 |
KubeSphere 社区更加沉闷些，毕竟是万星开源我的项目，用户遍布国内外。Rainbond 社区用户根本都是国内用户，Star上差了些不过Github、社区群也蛮沉闷的。
装置体验比照
KubeSphere
反对通过一条命令在 Linux 上疾速装置 KubeSphere。
./kk create cluster --with-kubernetes v1.22.10 --with-kubesphere v3.3.0Rainbond
反对通过一条命令在 Mac、Win、Linux 上疾速装置 Rainbond。
docker run --privileged -d -p 7070:7070 -p 80:80 -p 6060:6060 rainbond/rainbond:v5.8.1-dind-allinone| KubeSphere | Rainbond | |
|---|---|---|
| Docker Desktop and ARM | 不反对 | 反对 |
| Linux | 反对 | 反对 |
| Kubernetes | 反对 | 反对 |
| 私有云、托管Kubernetes | 反对 | 反对 |
| 装置后组件数量 | 启动所有可拔插组件后 Pod 大略 55 个左右 | 大略 15 个 Pod |
KubeSphere和Rainbond装置都很简略。 KubeSphere 自研的 KubeKey 装置工具，在服务上装置 K8s 和 KubeSphere 很不便。KubeSphere 的可拔插组件这个设计还蛮好的，Allinone装置之后有 5 个 Pod 左右，能满足根本运行需要，须要其余性能就通过可拔插开启，开启所有组件后 Pod 大略 60 个左右。Rainbond 能反对在 Mac M1 Docker Desktop 上装置，这个装置体验还蛮好的能够在本地开发，Rainbond 启动后 Pod 大略15个左右，内存占用1G 左右。
利用部署性能比照
KubeSphere
KubeSphere对接git仓库部署源码，反对 Source-to-Image (S2I) 规范工作流将源码打包成镜像，并部署在 Kubernetes 集群中。反对 Java、Python、Node，其余语言可通过自定义 S2I 实现源码构建。
KubeSphere采纳 Binary-to-Image (B2I) 规范工作流将二进制打包成镜像，并部署在 Kubernetes 集群中。反对通过 Jar、War、二进制
KubeSphere 反对自定义继续构建的流水线
Rainbond
Rainbond反对对接和整合 Gitlab、Github、Gitee、SVN，实现对立入口
Rainbond 的构建反对自动识别源代码类型，反对自动识别 Java Maven、Java Gradle、Java Jar、Java War、Python、PHP、.NetCore、Golang、NodeJS、Static HTML。
每种辨认的开发语言反对设置环境相干信息，并主动构建成容器镜像。
| KubeSphere | Rainbond | |
|---|---|---|
| 源码部署 | 反对 Java、Python、Node | 反对自动识别 Java Maven、Java Gradle、Java Jar、Java War、Python、PHP、.NetCore、Golang、NodeJS、Static HTML |
| 二进制部署 | Jar、War | Jar、War |
| 容器镜像 | 反对容器镜像部署 | 反对容器镜像、docker run、docker compose部署 |
| Kubernetes 利用 | Yaml、Helm | Yaml、Helm |
| 继续交付 | 反对GitOps和自定义流水线步骤 | 反对GitOps |
KubeSphere 兼容Kubernetes体系，利用部署应用S2I和B2I，KubeSphere自定义流水线性能十分弱小，配置灵便。Rainbond 利用部署不须要懂容器和Kubernetes，反对常见的源代码，并自动识别和构建，应用非常简单。
微服务架构性能比照
KubeSphere
KubeSphere的微服务架构基于 Istio 实现，反对微服务的流量可视化治理。
基于Jaeger的调用链分析
Rainbond
Rainbond的微服务架构拓扑和服务编排，通过图形化的编排，增加组件之间的依赖关系，增加后也会注入服务之间的连贯信息等。拓扑图能够展现服务之间的关系，用色彩辨别服务的状态等。
微服务实时性能剖析
| KubeSphere | Rainbond | |
|---|---|---|
| 服务网格反对 | Istio | 内置、Istio、Linkerd |
| 服务拓扑图 | 流量拓扑图 | 微服务依赖关系和服务状态展现 |
| 服务治理 | 熔断、限流 | 插件实现熔断断路器和限流 |
| 微服务可观测性 | 调用链分析 | 通过插件扩大十分多可观测性： 性能剖析、pinpoint、skywalking、Jaeger等 |
| 微服务编排 | 代码编排 | “利落拽”的模式编排微服务依赖关系 |
KubeSphere 齐全依赖 Istio 实现微服务架构，对Istio的性能反对十分残缺，KubeSphere补救了Istio没有图形化的控制面板的有余，简化了 Istio 的上手难度，服务之间的拓扑图是依据流量走向主动生成的，能够直观的看到服务间流量。
Rainbond 的服务网格、服务治理、可观测性都是通过插件体系反对的，传统利用开启服务网格插件，马上就能反对微服务架构，服务治理和可观测性也只须要开启相应插件，Rainbond内置了很多插件，有须要还能够自行扩大，能够将本人趁手的工具增加进来，另外，图形化手动编排服务是个特色，不必改代码就能够动静调整依赖关系。
利用市场性能比照
KubeSphere
内置利用商店有 30 个利用可间接装置。
基于 Helm Chart 创立利用模板。
公布 Helm Chart 利用模板。
Rainbond
内置利用商店有 90+ 利用可间接装置。
反对用户将曾经部署好的利用一键公布至利用市场，无需编写简单的YAML。能够一键公布利用模型内所有元数据，例如依赖关系、配置文件、存储信息等。
反对利用离线导出导入，反对导出 Rainbond App 利用包、Docker Compose 利用包、非容器环境利用包。
反对基于 Rainbond 利用市场一键装置和一键降级，降级会蕴含利用模型内所有元数据，包含依赖关系等。
| KubeSphere | Rainbond | |
|---|---|---|
| 利用模板 | Helm | Rainbond 利用模版、Helm |
| 利用公布 | 上传 Helm Chart | 一键公布到利用市场 |
| 利用装置 | 一键装置 | 一键装置 |
| 利用降级 | 整体降级 | 局部降级或整体降级 |
| 离线导入导出 | 不反对 | 离线导出多种格局包 |
| 内置利用 | 30 可用利用 | 90+ 可用利用 |
在利用市场这块Rainbond的性能比KubeSphere弱小很多，易用性也好很多。KubeSphere 在利用市场这块是基于规范的 Helm 实现的，在利用公布、装置、降级这套流程里是依照规范的 Helm 利用标准实现，制作 Helm Chart 门槛比拟高，性能也受限于Helm。Rainbond 的利用市场 定义了本人的利用模型标准，也反对Helm Chart转成Rainbond的利用模型，利用公布反对一键公布由几十个服务组成的利用，无需编写简单的YAML，离线导出是在企业软件交付场景十分实用的性能。
Kubenetes 多集群治理性能比照
KubeSphere
KubeSphere反对对接多个 K8s 集群，反对各种云厂商托管 K8s 集群以及公有云、混合云等。借助 KubeSphere的图形化 Web 控制台，用户能够治理底层的基础架构，例如增加或删除集群。能够应用雷同的形式治理部署在任何基础架构上的异构集群。反对跨集群利用散发，资源整合等。反对通过图形化界面治理节点，监控集群状态、利用资源监控、集群告警和告诉等。
集群监控
Rainbond
反对对接多个 K8s 集群，反对各种云厂商托管 K8s 集群以及公有云、混合云等。反对用户通过控制台增加或删除集群，反对跨集群利用散发。
通过grafana扩大的集群和节点监控
| KubeSphere | Rainbond | |
|---|---|---|
| 多集群治理 | 反对对接多个 K8s 集群 | 反对对接多个 K8s 集群 |
| 集群治理 | 存储管理、节点治理 | 命令行治理 |
| 集群监控和可视化 | 丰盛的监控 | 通过grafana扩大的监控 |
| 多租户 | 从平台角色、企业空间角色、我的项目角色三个维度定义多租户 反对企业空间、我的项目进行资源限额，反对多租户的逻辑隔离、网络隔离 | 从企业角色、团队角色两个维度定义多租户 反对对团队的资源限额，反对多租户的逻辑隔离 |
KubeSphere 在多集群治理这块比Rainbond体验好，有丰盛的监控和可观测性，治理存储和节点在控制台全副实现，Rainbond在集群治理这块须要在命令行下治理，监控性能也弱一些。
利用运维性能比照
根本治理
KubeSphere
反对对工作负载、容器组级别的治理，反对工作负载的YAML编辑、版本回滚、删除、从新创立等。
反对对容器级别的日志查问过滤，反对全局的日志查问过滤。
KubeSphere 采纳 Kubernetes 原生模式进行利用拜访，可通过 NodePort、LoadBalancer、Ingress实现内部拜访。反对扩大第三方负载平衡控制器以及 Ingress 控制器
Rainbond
反对对利用、组件级别的治理，反对利用批量启动、重启、更新、敞开、删除以及组件的操作，反对利用和组件级别的环境变量、版本回滚等。
组件日志实时查看和筛选
Rainbond采纳对立的利用网关，反对配置HTTP路由规定和HTTPS证书
由 Rainbond Gateway 对立封装拜访，反对http、tcp、udp、grpc拜访组件。
| KubeSphere | Rainbond | |
|---|---|---|
| 根本治理 | 反对对工作负载级别的治理 | 反对对利用、组件级别的治理 |
| 日志 | 反对容器组日志查问过滤和全局日志查问过滤 | 反对组件日志查问过滤 |
| 监控 | 反对工作负载级别的告警以及自定义监控图 | 反对组件级别的监控以及图表，告警可扩大 |
| 伸缩 | 反对手工和主动 | 反对手工和主动 |
| 网关 | 反对 NodePort、LoadBalancer 和 Nginx Ingress | 由 Rainbond Gateway 对立封装拜访，反对http、tcp、udp、grpc |
对于根本治理来说 KubeSphere 是原生 K8s 的一些治理，比方删除Pod、编辑YAML、配置环境、自定伸缩等，同样 Rainbond 展示的是利用级概念，比方：在K8s里没有敞开的概念，而在Rainbond里利用不必了间接敞开，想用了再启动，Rainbond做了很多利用级的概念转化，对于不动K8s的开发人员更加容易接受。
KubeSphere 在网关这块同样也是遵循了 K8s 原生的模式，通过 NodePort、LoadBalancer、Ingress实现内部拜访，并通过图形化操作简化了 YAML 的操作，长处是能够扩大更多第三方 Ingress 控制器，例如 Traefik 等。Rainbond 网关则是通过 Rainbond Gateway 对立封装实现内部拜访，简化了用户的操作，一键开启内部拜访，同时也能配置 HTTP 的路由规定等，应用的体验十分好。
总结
总体来说，KubeSphere和Rainbond都很成熟，也都有大量开源应用用户，只是定位不同，所以实用场景也会不同。
KubeSphere 在兼容Kubernetes生态方面做的十分好，包装和整合了很多云原生的工具，并扩大了对Kubernetes和开源工具的治理能力，对于想要治理Kubernetes集群的系统管理员是个好的工具，相熟Kubernetes的工程师也能够自行扩大KubeSphere的能力。但对开发人员来开发和治理利用来说，门槛比拟高，须要学习和了解的概念十分多。
Rainbond 屏蔽了底层简单的技术，基于利用级形象，在Rainbond的产品闭环里，体验十分好。这实用一般的开发人员开发和治理利用，对于不相熟 Kubernetes用户疾速起步也是一个不错的抉择，在企业软件交付上Rainbond十分善于。但在对Kubernetes 的系统管理上性能有欠缺。
因为集体常识和教训无限，如有了解不对的中央，还请见谅。