共计 5788 个字符，预计需要花费 15 分钟才能阅读完成。
最近因为工作须要，须要找一个功能完善的云原生利用平台，通过本人筛选和敌人举荐，剩下 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 的系统管理上性能有欠缺。
因为集体常识和教训无限，如有了解不对的中央，还请见谅。