继续创作，加快生长！这是我参加「日新计划 10 月更文应战」的第2天，点击查看活动详情
最近因为作业需求，需求找一个功用完善的云原生运用渠道，经过自己挑选和朋友引荐，剩下 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.0
Rainbond
支撑经过一条指令在 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 的系统办理上功用有欠缺。
因为个人常识和经历有限，如有了解不对的地方，还请见谅。
