CNCF 最新年度调查已经把一个事实说得很清楚：Kubernetes 基本已经坐稳了生产基础设施底座的位置。真正卡住团队的，越来越不是“要不要上 K8s”，而是“组织到底吃不吃得下它”。

很多团队今天遇到的尴尬，其实都很像。

项目启动会上，大家都认同要往云原生走。
架构师说 Kubernetes 已经是行业共识。
管理层也觉得这事迟早要做。

但几个月之后，真正推进起来，问题却不是出在技术路线，而是出在这些更现实的地方：

• 开发说，改个服务还得等运维；
• 运维说，大家都想上 K8s，但没人想先把这套复杂度接住；
• 业务说，为什么平台搭了，交付还是没变快；
• 交付团队说，每个客户还是像重新来一遍。

如果你们也有类似体感，那这篇文章可能比一篇“如何快速学会 K8s”更值得看。

因为今天最重要的问题，已经不是“你懂不懂 Kubernetes”，而是：

当 Kubernetes 成了底座之后，团队要靠什么，才能真的把它用起来。

先把外部结论说清楚​

先看两个来自 CNCF 的明确信号。

信号 1：Kubernetes 已经不是前沿尝试，而是生产基础设施​

CNCF 2026 年度调查显示，在使用容器的受访者里，82% 已经在生产环境运行 Kubernetes。

这意味着两件事：

1. 讨论“要不要上 Kubernetes”这件事，意义已经在下降。
2. 接下来真正拉开差距的，不是会不会装，而是会不会用、怎么组织起来用。

信号 2：真正的挑战，越来越不是工具本身​

CNCF 官方解读这份调查时，直接给了一个很值得传播的判断：

culture, not complexity or security, is now the top barrier

翻译成人话就是：

今天很多团队落不了地，已经不只是因为技术复杂，而是因为组织接不住。

一张图看懂：问题已经从“技术门槛”转向“组织门槛”​

这张图里最关键的变化是：

• 以前大家在争“技术行不行”
• 现在更多团队在面对“组织怎么把技术吃下去”

这也是很多平台讨论经常讲偏的地方。

很多内容还在用一种默认前提写文章：
只要技术路线选对，团队自然会跟上。

现实通常没这么顺。

为什么很多团队明明认可 Kubernetes，却还是落不了地？​

问题一般出在 4 个地方。

1. 技术共识有了，但角色边界没变​

很多团队嘴上已经接受了云原生，但实际协作方式还是老路子：

• 开发写完代码，继续等运维发版；
• 运维继续做“平台翻译官”；
• 业务继续把交付当成后置动作。

结果就是，底层换成了 Kubernetes，上层流程却没变。

技术升级了，组织习惯没升级。

2. 平台搭起来了，但真正用的人没跟上​

这在很多企业里都很常见。

平台团队把底层搭得很完整，功能也不差，但最后真正高频操作的人依然只有少数几位运维或架构师。开发团队、测试团队、交付团队仍然觉得这套东西“不是给自己用的”。

这不是平台没价值，而是平台没有变成“大家愿意用、用得起、用得明白”的产品。

3. 大家都知道 K8s 很强，但不是每个团队都该先去学它​

这一点很容易被误解。

Kubernetes 当然重要。
但“重要”和“需要每个人先学会”是两回事。

对于很多团队来说，当前最贵的问题根本不是“不会 Kubernetes”，而是：

• 交付链路太长；
• 环境信息太散；
• 部署动作太依赖少数人；
• 每次上线都像在做一个小项目。

如果这些问题不先解决，单纯把学习成本再叠上去，团队只会更累。

4. 对 ToB、私有化、内网场景来说，组织门槛会被放大​

如果你所在的团队还涉及这些场景：

• 私有化部署
• 客户现场交付
• 多环境多集群
• 信创迁移
• 内外网隔离

那“Kubernetes 是底座”并不意味着事情更简单，反而意味着：

你更需要一层能把复杂度往后收、把交付流程往前拉平的平台。

谁更适合直接深上 Kubernetes，谁更适合先降低组织门槛？​

这个问题特别重要，因为它决定了你到底该怎么开始。

这里不是说“不要学 Kubernetes”。
而是说：

不要把“学 Kubernetes”误当成所有团队的第一步。

很多团队真正需要的第一步，其实是：

先找到一条不被 Kubernetes 复杂度拖死的落地路径。

这也是 Rainbond 最值得被重新理解的地方​

Rainbond 最容易被误解成一种“图形化界面更友好的容器平台”。

如果只这么理解，其实低估了它。

更准确的说法应该是：

当 Kubernetes 已经成为底座后，Rainbond 要解决的是“组织如何把这套底座真正吃下去”的问题。

它并不是去否定 Kubernetes，而是往上做了一层很关键的事情：

• 把底层概念往后收；
• 把应用视角往前提；
• 把开发、运维、交付之间的协作门槛降下来。

这意味着什么？

意味着很多团队不用先把所有人都训练成 Kubernetes 使用者，才能开始云原生试点。
他们可以先围绕“应用”工作：

• 从源码、软件包或镜像开始；
• 先把应用跑起来；
• 再去做版本、升级、回滚、日志、依赖和交付。

这对下面几类团队尤其重要：

• 中小研发团队；
• 传统企业信息化部门；
• 私有化 / 离线交付团队；
• 想做平台工程，但当前还在早期阶段的团队。

一张判断图：Rainbond 到底接住了哪一层问题？​

这张图想说明的不是“Rainbond 比 Kubernetes 更重要”。

恰恰相反。

它说明的是：

Kubernetes 的重要性已经被证明了，所以现在更重要的问题变成：谁来帮团队真正把它用起来。

Rainbond 就是在这个位置上有意义。

如果你是技术负责人，这篇文章真正该带走什么？​

带走 3 个判断就够了。

判断 1：Kubernetes 已经不再是“是否值得”的问题​

外部共识已经很强，继续争这个问题本身意义不大。

判断 2：接下来最关键的不是底座，而是组织门槛​

你团队能不能真的推进，取决于：

• 谁来接复杂度；
• 谁来完成交付；
• 谁愿意真正用平台；
• 上线之后谁能维护住。

判断 3：如果你们当前最大的痛是“落不了地”，就别从最重的地方开始​

很多团队失败，不是因为平台太弱，而是因为第一步走得太重。

如果你的团队现在最真实的问题是：

• 不想先把每个人都训练成 Kubernetes 专家；
• 想先跑通一个真实应用；
• 更在意交付效率，而不是先做复杂治理；

那 Rainbond 这种路径，通常比“先把整个团队压进底层复杂度”更现实。

最后一句话​

今天最值得传播、也最值得记住的，不是：

“Kubernetes 很重要。”

而是：

当 Kubernetes 已成底座之后，真正把团队卡住的，越来越是人和组织。

而 Rainbond 的价值，恰好不在底座层，而在这层更难、也更现实的组织门槛上。

参考信息​

• Rainbond 官方文档：
  • Rainbond 是什么
  • 设计思想

但真正决定选型的，往往不是“谁功能更多”，而是：

• 你的团队当前有没有成熟的平台工程能力
• 你们最紧迫的问题是多集群治理，还是先把第一个应用跑起来
• 你们更看重平台能力深度，还是上手门槛和交付效率

如果这些问题没有先想清楚，再完整的功能对比也很难帮你做出正确判断。

所以这篇文章不打算回答“谁最强”，而是帮助你回答另一个更关键的问题：

Rainbond、Rancher、KubeSphere、Sealos，哪个更适合你当前的团队阶段？

先说结论​

如果你的团队当前最真实的问题是：

• 不想先把整个团队都训练成 Kubernetes 专家
• 想尽快跑通第一个云原生试点
• 更关心应用交付效率，而不是先做复杂的平台治理

那么 Rainbond 更值得优先评估。

如果你的团队已经具备比较成熟的 Kubernetes 平台工程能力，重点是：

• 多集群治理
• 更复杂的企业级控制能力
• 更大的平台统一性需求

那么 Rancher、KubeSphere 或 Sealos 可能更符合你的阶段目标。

这不是谁绝对更好，而是谁更适合你当前要解决的问题。

一句话理解四者的差异​

• Rainbond：更适合想降低门槛、先把应用跑起来的团队
• Rancher：更适合已经有 Kubernetes 认知基础、要管理更复杂集群环境的团队
• KubeSphere：更适合需要一套较完整云原生平台能力、并能接受相应复杂度的团队
• Sealos：更适合偏云上、偏开发者效率、偏 AI / 应用快速部署场景的团队

先不要比功能，先比团队阶段​

一个最常见的误区是：

团队明明当前最大的问题是“难开始”，却拿着偏“复杂治理”的平台标准去选工具。

结果通常是：

• 平台能力看起来很强
• 但真正推进速度没有变快
• 业务团队仍然很难参与
• 第一个试点迟迟跑不起来

所以与其先问“谁更全面”，不如先问：

我们当前最缺的，到底是平台治理能力，还是更容易开始的路径？

四个平台适合谁​

Rainbond 更适合谁​

Rainbond 更适合下面这些团队：

• 有开发团队，但没有专职 Kubernetes 专家
• 想提升应用交付效率，但不想先投入太多平台建设成本
• 需要本地部署、私有化部署或信创场景落地
• 想先通过一个真实试点验证方向，而不是一开始全面替换

Rainbond 的核心价值不是“把 Kubernetes 变没”，而是：

让不懂 Kubernetes 的团队，也能先把应用跑起来。

如果你的团队当前最重要的问题是“怎么迈出第一步”，Rainbond 的优势会更明显。

Rancher 更适合谁​

Rancher 更适合下面这些团队：

• 已经具备较成熟的 Kubernetes 认知和运维能力
• 需要统一管理多个集群
• 更关注企业级治理能力、控制面和标准化
• 组织规模更大，平台复杂度不是主要障碍

Rancher 的强项不在“让所有人都能快速上手”，而在于：

在更成熟的 Kubernetes 环境里，提供更强的统一治理能力。

KubeSphere 更适合谁​

KubeSphere 更适合：

• 希望用一套平台承接更多云原生能力的团队
• 接受一定平台复杂度，换取更完整功能覆盖
• 需要较强中文生态和国内市场认知支持的团队

KubeSphere 的吸引力往往来自“能力更全”，但这也意味着它并不是最轻量、最容易开始的选择。

Sealos 更适合谁​

Sealos 更适合：

• 更偏云上工作流、开发者效率和快速部署的团队
• 希望弱化 YAML、Dockerfile、传统 CI/CD 复杂度的团队
• 更接近“云上开发环境 + 应用部署平台”一体化体验的团队
• 对 AI 应用、Agent、数据库、全栈应用快速上线感兴趣的团队

Sealos 的吸引力更偏：

• 云上开发与部署一体化
• 更强的“开发者云平台”心智
• 更明显的 AI-native / 应用快速上线叙事

这也意味着它和 Rainbond 的区别，不只是功能对比，而是：

• Rainbond 更偏 应用平台 / 私有化 / 本地部署 / 试点落地
• Sealos 更偏 云上开发体验 / 快速部署 / AI-native 平台体验

最关键的区别，不在功能表​

从实际落地角度看，四者真正的差异主要在这 5 个维度。

1. 上手门槛​

• Rainbond：更低，适合先让更多团队成员参与交付
• Rancher：中到高，需要更强的 Kubernetes 背景
• KubeSphere：中到高，平台能力更全，理解成本也更高

2. 应用交付路径​

• Rainbond：更强调围绕“应用”组织交付流程
• Rancher：更偏集群和治理层
• KubeSphere：平台能力较完整，但团队需要理解更多系统结构
• Sealos：更偏云上开发到部署的一体化路径

3. 组织适配性​

• Rainbond：更适合中小团队、传统企业数字化团队、试点阶段团队
• Rancher：更适合成熟平台团队
• KubeSphere：更适合愿意投入平台建设的人群
• Sealos：更适合更偏开发者效率、云上产品化交付的团队

4. 部署环境和使用方式​

• Rainbond：更适合本地部署、私有化部署、信创和传统企业试点
• Rancher：更适合复杂集群环境和企业级治理
• KubeSphere：更适合需要较完整云原生平台能力的环境
• Sealos：更适合云上快速部署、开发者工作流和 AI-native 场景

5. 当前阶段是否需要“先跑起来”​

如果你当前不是在优化第 3 个集群，而是在发愁第 1 个试点怎么落地，那么 Rainbond 和 Sealos 的优先级通常会更高。
但两者的发力点并不完全一样：

• Rainbond：更适合“应用平台 + 私有化 / 本地化 / 企业试点”
• Sealos：更适合“云上开发者体验 + 快速部署 + AI-native 应用”

什么时候更应该先看 Rainbond​

以下几种情况，Rainbond 通常更值得优先试：

情况 1：团队不想先补完整套 Kubernetes 知识​

你们不是不愿意学，而是现实里没有这个空档。

这时真正重要的是，先找到一条能让团队进入“可交付状态”的路径。

情况 2：你们需要一个真实试点，而不是平台大会战​

第一次做云原生试点，不应该先拿最复杂的核心系统做赌注。
更好的做法是：

• 选一个真实但风险可控的业务应用
• 跑通完整交付流程
• 观察新人上手、发布路径和协作效率是否改善

情况 3：你们更关心私有化 / 本地部署 / 信创落地​

如果你的团队对这类场景关注度高，那么“本地可控、路径更顺、门槛更低”的价值会比单纯的功能广度更重要。

什么时候不应该优先看 Rainbond​

如果你的团队已经具备以下特点，Rainbond 可能不是你最先看的方向：

• 已经有成熟的 Kubernetes 平台工程体系
• 更在意多集群治理和复杂企业级能力
• 组织可以承担更高的平台复杂度
• 主要目标不是“先开始”，而是“做更强治理”

这时 Rancher 或 KubeSphere 往往更值得先比较。
如果你的团队更接近“开发者云平台 / AI 应用快速部署 / 更偏云上效率”的诉求，那么 Sealos 也值得重点比较。

第一次评估，建议这样做​

不要只看官网和功能列表，建议直接做一个真实试点。

第一步：选一个真实但风险可控的应用​

不要先上最核心系统。
选择一个真实、有持续迭代需求、但不会把最高业务风险压上的应用。

第二步：重点看 3 个问题​

1. 新人是不是更容易上手
2. 应用交付路径是不是更短
3. 团队是不是更少被基础设施细节拖住

第三步：再决定要不要扩大范围​

真正有效的选型，不是先做一个完美判断，而是先看：

它能不能帮助你的团队更顺利地迈出第一步。

最后总结​

如果你把这四个平台放在一起看，最重要的不是“功能谁更全”，而是：

• 你的团队当前在哪个阶段
• 你最想解决的问题是什么
• 你要的是更强治理、更容易开始，还是更顺的云上开发体验

如果你的团队最真实的问题是：

不懂 Kubernetes，也想先把应用跑起来

那 Rainbond 就是值得优先评估的方向。
如果你的团队更偏云上开发、AI 应用快速部署和一体化开发工作流，那么 Sealos 也会是一个必须纳入比较的对象。

快速开始​

• 快速安装：
  • https://www.rainbond.com/docs/quick-start/quick-install

加入社区​

• 如果你在选型、安装或试点过程中遇到问题，欢迎加入 Rainbond 用户交流群交流。

常见情况是：

• 开发团队希望更快上线应用
• 运维团队希望平台标准化
• 管理者知道云原生是方向
• 但团队没有足够时间，先把 Kubernetes 全学一遍，再开始交付业务

于是问题就出现了：

不是方向不对，而是真正落地之前，团队先被复杂度挡住了。

团队卡住的，往往不是技术能力，而是推进节奏​

Kubernetes 很强，但它天然更偏基础设施能力。对于很多业务团队来说，真正困难的不是“容器是什么”，而是：

• 概念太多，学习路径太长
• 部署、网络、存储、日志、依赖服务要一起看
• 很难在短时间内跑通一个让团队有信心的试点

结果就是，大家都知道云原生应该做，但真正推进时，总是停在“先研究一下”。

Rainbond 更适合被理解为一条更容易开始的路径​

Rainbond 的价值不在于替代 Kubernetes，而在于降低团队使用云原生能力的门槛。

它更适合解决这类问题：

• 能不能让团队先把第一个应用跑起来
• 能不能让非平台工程背景的成员参与交付
• 能不能让开发、测试、运维围绕“应用”协作，而不是被基础设施细节拖住

简单说，Rainbond 试图解决的不是“平台功能够不够多”，而是：

团队能不能更顺利地迈出云原生第一步。

什么样的团队适合先试点​

Rainbond 更适合下面这几类团队：

• 有开发团队，但没有专门的 Kubernetes 专家
• 想提升交付效率，但不想先投入太多平台建设成本
• 需要本地部署、私有化部署或信创场景落地
• 想先用一个真实项目验证方向，而不是一次性改造全部系统

如果你的团队已经具备成熟的平台工程能力，重点关注多集群治理、复杂安全体系和深度定制，那么你更关心的重点可能不一样。
但如果你当前最真实的问题是“怎么先开始，而且别太难”，Rainbond 值得优先试点。

第一个试点，不要选最复杂的系统​

第一次试点的目标不是“证明平台无所不能”，而是验证：

• 新人是不是更容易上手
• 部署和回滚路径是不是更清晰
• 团队是不是更聚焦应用交付本身

所以更好的做法通常是：

• 选一个真实但风险可控的业务应用
• 它最好有持续迭代需求
• 但不要把最高业务风险压在第一次试点上

只要第一次试点能顺利跑通，后面的推广成本就会明显降低。

一个更现实的评估方法​

如果你正在评估 Rainbond，建议不要先陷入抽象讨论，而是先回答这 3 个问题：

1. 你的团队现在最卡的是安装、学习成本，还是发布流程？
2. 你们是否缺少专职 Kubernetes 平台工程能力？
3. 你们是否需要一条更适合真实业务节奏的试点路径？

如果答案偏向“是”，那么比起继续讨论概念，更好的做法是直接拿一个真实应用试一次。

结语​

Kubernetes 本身不是问题。
真正的问题是，很多团队在享受云原生收益之前，先被第一步的复杂度拦住了。

如果你的团队正在寻找一条更贴近业务交付的落地路径，Rainbond 值得从一个真实试点开始认真评估。

快速开始​

• 快速安装：
  • https://www.rainbond.com/docs/quick-start/quick-install

加入社区​

• 安装过程中如果遇到问题，欢迎加入 Rainbond 用户交流群，和我们一起交流实践经验。

对于运维和开发工程师来说，离线环境部署 Kubernetes往往是一场噩梦。

当你兴致勃勃准备大干一场时，现实通常是这样的：

• 镜像缺失： ImagePullBackOff 成了屏幕上最常见的报错。
• 配置繁琐： 证书、ETCD、网络插件……稍微错一个参数，集群就起不来。
• 不仅是K8s：装好了 K8s 只是第一步，还得装监控、装网关、装管理面板……

有没有一种工具，能像在线安装一样丝滑，把 K8s 集群和管理平台一次性端进离线机房？

今天，我们要向大家推荐一款神器 ROI (Rainbond Offline Installer)

什么是 ROI？​

ROI 是 Rainbond 团队专为完全离线环境打造的一站式部署工具。

它的目标很简单：让离线环境下的云原生平台交付，变得像 apt-get install 一样简单。

无论你是需要在无网的物理机房交付项目，还是在很多安全限制的内网做 POC，ROI 都能让你事半功倍。

1. 真正的全栈离线交付​

ROI 不止安装 K8s。它提供了一个包含所有依赖的大礼包。

• 自动 OS 调优： 内核参数、防火墙、Swap……ROI 自动帮你按最佳实践配置好。
• 内置 K8s (RKE2)： 基于轻量级、高安全性的 RKE2 发行版，符合生产标准。
• 自动存储配置： 自动配置 LVM 和 NFS，不再为持久化存储头疼。
• 内置MySQL：集群模式下默认部署 MySQL 主从集群，为 Rainbond 集群提供高可用的 MySQL。
• 预加载镜像： 所有需要的容器镜像都已打包，无需配置任何 Registry 代理。

2. 极简操作，零门槛上手​

忘掉那些几百行的 Ansible 脚本吧。ROI 的操作逻辑简单到令人发指：

1. 下载：一条命令把所有离线包下载到本地。
2. 分发：自动将包分发到集群所有节点。
3. 安装：一个命令 roi up，集群就好了。

不仅仅是 K8s，更是 Rainbond​

很多朋友为了离线装 K8s 费尽周折，但装好 K8s 后，如何让不懂 K8s 的开发人员也能用起来？ 这才是更大的挑战。

使用 ROI，你在获得一个标准 K8s 集群的同时，还免费获得了一套强大的云原生应用管理平台 —— Rainbond。

Rainbond 能为你做什么？

• 应用视角的管理： 不需要写 Yaml，不需要懂 Service/Ingress，直接通过源码或镜像就能部署应用。
• 应用市场： 像手机装 App 一样安装 MySQL、Redis、GitLab 等中间件。
• ......

ROI + Rainbond，不仅解决了怎么装的问题，更解决了怎么用的问题。

如果你想从解决方案角度判断“纯离线安装、离线交付、鲲鹏 / 麒麟部署、x86 到 ARM 迁移”应该先看哪条路径，建议进入 离线 / 信创 / 国产化专题，完全离线环境可以直接从 纯离线环境安装 开始。

快速上手演示​

眼见为实，让我们看看用 ROI 部署有多简单。

第一步：在有网环境下载离线包​

# 下载 ROI 工具
curl -o roi https://get.rainbond.com/roi/roi-amd64 && chmod +x roi

# 一键下载所有离线资源
./roi download

第二步：将文件拷贝到离线服务器​

拿到 offline-packages 目录后，通过 U 盘或光盘拷贝到内网服务器。

第三步：单机一键安装（最简模式）​

单机部署下默认会部署 NFS Server，你需要手动安装，如 yum -y install nfs-utils。

TODO：未来会支持自动部署

# 无需任何配置，直接起飞
./roi up

第四步：集群模式安装（生产模式）​

只需编写一个简单的 cluster.yaml：

hosts:
  - name: node-1
    address: 172.16.0.134
    internalAddress: 172.16.0.134
    user: root
    password: root

  - name: node-2
    address: 172.16.0.135
    internalAddress: 172.16.0.135
    user: root
    password: root

  - name: node-3
    address: 172.16.0.136
    internalAddress: 172.16.0.136
    user: root
    password: root

# Role assignment
roleGroups:
  etcd: [node-1, node-2, node-3]
  master: [node-1, node-2]
  worker: [node-1, node-2, node-3]
  nfs-server: [node-1]
  rbd-gateway: [node-2, node-3]
  rbd-chaos: [node-2, node-3]

# Storage configuration
storage:
  nfs:
    enabled: true
    sharePath: /nfs-data/k8s
    storageClass:
      enabled: true

# Database configuration - MySQL with master-slave replication
database:
  mysql:
    enabled: true
    masterPassword: "RootPassword123!"
    replicationPassword: "ReplPassword123!"

# Rainbond configuration
rainbond:
  version: v6.4.0-release

然后执行：

./roi up -f cluster.yaml

✅ 安装完成！

终端会直接输出访问地址。打开浏览器，你不仅拥有了一个 Ready 状态的 K8s 集群，更拥有了一个功能完备的 Rainbond 控制台。

离线交付不再难，用 ROI 重新定义你的部署效率。

您是否也正为此头疼：IT资源如同散落的珍珠，管理混乱，利用率低下如无底洞？应用运维依旧是“手工作坊”，部署靠经验，升级靠祈祷，半夜被告警惊醒是家常便饭？与供应商的协作交付，标准不一，沟通不畅，项目上线遥遥无期？辛辛苦苦开发的软件成果，随着项目结束或人员流动便“随风飘散”，难以沉淀为企业真正的能力？

如果您正面临这些困境，那么，请允许我们为您介绍一款开源软件——Rainbond，新一代云原生应用管理平台。它并非简单的工具堆砌，而是一套深思熟虑的“组合拳”，以“应用”为绝对核心，致力于为您带来前所未有的现代化转型体验。Rainbond是如何化腐朽为神奇，疏通应用现代化之路上的“肠梗阻”呢？请看其精心打造的四大“神兵利器”！

神兵利器一：统一资源管理 —— 施展“乾坤大挪移”，化零为整，让资源高效转起来！

过去，物理服务器、各种品牌的虚拟机、以及新兴的Kubernetes集群往往各自为政，形成一个个“资源孤岛”，不仅管理界面繁杂，更导致资源分配靠“拍脑袋”，大量资源闲置浪费。

Rainbond的统一资源管理能力，首先就能兼容并包，无论是您现有的物理服务器、VMware、OpenStack等虚拟机环境，还是各类Kubernetes集群，都能被Rainbond一站式平滑接入和统一管理。您无需“推倒重来”，即可保护历史投资。更妙的是，Rainbond提供灵活的资源分配机制，团队空间既可以独占整个集群以保障关键业务的安全隔离，也可以多个团队共享一个集群，通过精细化的配额管理，既避免了资源浪费，又防止了“抢资源”的尴尬。正如我们的用户所言，通过Rainbond，“资源利用率提升看得见”，为应用现代化奠定了坚实而经济的底座。

神兵利器二：应用自动化运维 —— 演绎“无招胜有招”，运维化繁为简，让应用稳如磐石！

“在我机器上是好的！” 这句让无数开发者和运维人员头疼的话，背后是环境不一致、部署流程繁琐、运维高度依赖人工经验的无奈。应用现代化，首先要解放运维生产力。

Rainbond的应用自动化运维能力，彻底改变了这一局面。它屏蔽了Kubernetes等底层技术的复杂性，让普通信息化人员也能轻松上手管理应用的全生命周期。无论是从源码、Docker镜像还是Helm Chart部署应用，往往只需“一点即达”或通过简单的向导式操作即可完成。更重要的是，应用级的监控、告警、日志、弹性伸缩、无感知升级、一键回滚等高级运维能力，在Rainbond中都已开箱即用。底层基于Kubernetes的强大能力，自动保障应用的高可用、负载均衡和故障自愈，真正实现“让应用自己照顾自己”，运维团队终于可以从无尽的救火中解脱，聚焦更有价值的业务支撑工作。

神兵利器三：标准化供应商交付 —— 赐予“尚方宝剑”，规范流程，让协作畅通无阻！

企业信息化建设离不开外部供应商的参与，但供应商的交付过程往往是项目管理的“黑盒”。测试环境不统一、交付物五花八门、上线过程反复折腾、版本升级困难重重……这些都严重影响了项目进度和质量。

Rainbond的供应商交付管理解决方案，为企业与供应商的协作提供了“尚方宝剑”。它能为每个供应商提供独立的、安全的、资源可控的测试环境，互不干扰。更核心的是，供应商在Rainbond中测试通过的软件，可以一键发布为标准的“应用模版”。企业信息化部门在生产环境中，可以直接基于此模版一键安装部署，省时省力。当供应商有新版本或Bug修复时，只需在测试环境验证通过后更新应用模版，生产环境即可实现业务不中断的一键升级。整个交付、测试、上线、升级的每一步都清晰可追溯，让企业“管理更安心”，真正掌控与供应商的协作全局。

神兵利器四：软件资产化管理 ——打造“聚宝盆”，沉淀核心能力，让价值持续生金！

软件是企业数字化的核心，但很多时候，软件代码、配置、经验、以及有价值的解决方案，往往随着项目的结束或人员的变动而流失，无法形成可持续积累和复用的企业“资产”，导致大量重复开发和重复建设。

Rainbond的软件资产化管理理念及功能，致力于将企业的每一次软件投入都转化为真正的“聚宝盆”。它可以直接连接Git仓库，实现从代码提交到应用编译、构建、部署的自动化持续交付，所有组件的编译历史、版本信息自动记录。更重要的是，供应商交付的、或企业内部开发的关键应用和解决方案，都能以“应用模版”的形式在Rainbond中集中保存和管理。这意味着，即使“供应商离开也能自主运维”，因为测试环境就能独立编译和测试。每个应用模版都保留所有历史版本，任何人都能一键安装、升级或回滚。这些沉淀下来的应用模版，构成了企业内部的“能力库”，新项目可以直接调用和复用，极大节省重复开发成本，加速创新步伐，让软件资产持续为企业创造价值。

价值升华：Rainbond，驱动企业IT运营模式的深刻变革

通过这四大“神兵利器”的协同发力，Rainbond为企业应用现代化带来的，绝不仅仅是技术层面的点状优化，更是IT运营模式的系统性变革。它让您的应用交付速度倍增，更快响应市场变化；让您的IT资源成本显著降低，每一分投入都物尽其用；让您的开发运维效率大幅提升，团队精力聚焦核心业务；让您的业务系统更加稳定和富有弹性，从容应对各种挑战。更深层次地，Rainbond赋予了企业前所未有的自主可控能力，并将每一次软件投入都沉淀为可传承、可复用、可增值的宝贵数字资产。

业务问题的范畴​

首先有必要明确一点，什么样的问题算是 Kubernetes 领域的业务系统问题。Kubernetes 目前已经是云原生时代各类 “上云” 业务系统所处运行环境的事实标准。

我们假定你已经拥有了一套健壮的 Kubernetes 环境，业务系统的运行状态不会受到底层运行环境异常的影响，当业务系统出现问题时，Kubernetes 也可以正确的收集到业务系统的运行状态信息。

有了这假定条件之后，我们就可以将业务系统问题约束在业务从部署到正常运行起来这一时间区间内。所以本文探讨的业务系统问题的范畴包括：

• 业务系统的规格定义问题
• 业务系统的调度问题
• 业务系统长期运行中的问题

解决这类问题的意义​

解决这一类的问题的意义是显而易见的，因为将业务系统运行起来是一种最基础的需求。具备一套健壮的 Kubernetes 运行环境或者是编写了一套业务系统代码都不会为我们产生直接的价值。只有将业务系统代码运行到一个稳定的环境中，面向最终用户提供服务时才会为我们产生真正的价值。

值得庆幸的是，解决这类问题多半只需要我们踩一次坑。对于大多数全新的业务系统而言，部署到 Kubernetes 环境中去时，所可能遭遇的问题只需要被处理一次。一旦部署完成，业务系统就可以专注于迭代功能，不断循环完成发布过程即可，顺利进入了一个循环往复的 CI/CD 流程之中。

除去基础需求这一显而易见的意义，我们也会探讨如何降低解决这类问题的难度，解决问题难度的降低本身也具有意义。云原生时代，我们倡导每个开发人员都能够掌控自己的业务系统，这种掌控也对开发人员提出了新的要求，即掌控 Kubernetes 的使用。这有点将运维层面的工作附加给开发人员的意思，实际推广过程并不顺利。为了便于开发人员使用 Kubernetes 来部署与调试自己开发的业务系统，企业可以选择云原生应用平台来降低开发人员使用 Kubernetes 的门槛，Rainbond 就是这样一款云原生应用管理平台，其易用性的特点降低了开发人员的学习门槛，同时能够为业务系统赋能。

从一份yaml开始​

正常情况下，负责部署业务系统的工作人员是通过声明式的配置文件来定义业务系统的，其中的关键部分称之为规约(Spec)。这些规约字段通过格式严苛的 Yaml 类型配置文件来定义，正确填写其中的键与值需要庞杂的 Kubernetes 知识的保障。而掌握配置文件的格式，以及配置中的内容，往往是开发人员学习原生 Kubernetes 的首个陡峭门槛。

原生的使用方式中，kubectl 命令行工具会为这些配置文件提供严苛的校验机制，然而在校验无法通过时，能够给出的提示却并不是很友好。

以一份非常简单的 Yaml 配置文件为例：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: my-nginx
  name: my-nginx
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-nginx
  template:
    metadata:
      labels:
        app: my-nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        env:
        - name: DEMO_GREETING
          value: "true"  # 此处必须用引号扩起来，因为这是个 string 类型
        securityContext:
          privileged: true # 此处必须不能使用引号，因为这是个 bool 类型

配置中有两个 true 值，然而其中一个必须使用引号，而另一个则不是，这对一些新手而言并不是很友好。而加载这份配置文件的错误版本时，系统给出的报错虽然可以定位问题，但是交互体验更加不友好。

$ kubectl apply -f my-deployment.yaml
Error from server (BadRequest): error when creating "my-deployment.yaml": Deployment in version "v1" cannot be handled as a Deployment: v1.Deployment.Spec: v1.DeploymentSpec.Template: v1.PodTemplateSpec.Spec: v1.PodSpec.Containers: []v1.Container: v1.Container.Env: []v1.EnvVar: v1.EnvVar.Value: ReadString: expects " or n, but found t, error found in #10 byte of ...|,"value":true}],"ima|..., bigger context ...|ainers":[{"env":[{"name":"DEMO_GREETING","value":true}],"image":"nginx","name":"nginx"}]}}}}

像这样的问题，在类似 Rainbond 这样的云原生应用管理平台中，则不会出现。产品设计之时，就已经屏蔽了一些常见输入错误，用户不需要关注传入值的类型问题，平台会自行进行转换。

平台会自动为环境变量添加引号以匹配 string 类型：

以开启/关闭来体现 bool 类型：

对于一些特殊输入，也会进行合理校验，提供的反馈信息更加人性化：

借助这些功能，即使是小白用户也可以正确的定义业务系统的规格。

调度过程中的问题排查​

业务系统的规格定义完成后，就可以提交给 Kubernetes 系统了，下一步，Kubernetes 将会借助自身调度机制，将业务系统分配到合适的宿主机上运行起来。在进行调度的过程中，业务系统会在一小段时间内处于 Pending（待定的） 的状态，然而长期处于 Pending 状态则说明调度过程中出现了问题。

Kubernetes 以事件的形式，记录了业务系统在进入运行状态之前的每一个步骤。一旦出现了 Warning 甚至更严重级别的事件时，就说明业务系统的部署过程受阻了。了解如何查看这些事件，并理解其背后代表的意义，对于排查调度问题非常有帮助。

能够让业务系统长期处于 Pending 状态的常见问题包括：镜像拉取失败、资源不足等。使用原生 Kubernetes 时，难免和命令行打交道，来获取对应 Pod 的事件信息。

$ kubectl describe pod <podName> -n <nameSpace>

当所有的计算节点都没有足够的内存资源来调度业务系统的 Pod 时，事件信息是这样的：

Events:
  Type     Reason            Age        From               Message
  ----     ------            ----       ----               -------
  Warning  FailedScheduling  <unknown>  default-scheduler  0/3 nodes are available: 3 Insufficient memory.

而拉取镜像失败则是这样的：

Events:
  Type     Reason     Age                From                              Message
  ----     ------     ----               ----                              -------
  Warning  Failed     26s                kubelet, cn-shanghai.10.10.10.25  Error: ErrImagePull
  Normal   BackOff    26s                kubelet, cn-shanghai.10.10.10.25  Back-off pulling image "nginx_error"
  Warning  Failed     26s                kubelet, cn-shanghai.10.10.10.25  Error: ImagePullBackOff
  Normal   Pulling    15s (x2 over 29s)  kubelet, cn-shanghai.10.10.10.25  Pulling image "nginx_error"

对事件列表的解读，是需要较深厚的 Kubernetes 领域知识的。开发者需要从事件列表中找到关键词，进而采取正确的行动来解决问题。

在 Rainbond 云原生应用管理平台中，已经事先想到了降低问题排查成本的需求，用户点击代表有问题的业务系统 Pod 的方块，即可了解其详细信息。在这个页面中，浓缩了核心问题的说明、当前 Pod 的状态以及说明，可以帮助用户极快的定位问题。

运行过程中的问题排查​

当业务系统完成了调度过程后，Kubernetes 系统就会将业务系统对应的 Pod 启动起来，到这里，已经距离业务系统对外提供服务很近了。但是不要掉以轻心，Pod 启动时是有可能遭遇运行异常的。

一般情况下，正常运行中的 Pod 是体现 Running 状态的，开发人员可以通过命令行的方式获取其状态：

$ kubectl get pod <podName> -n <nameSpace>

但是如果处于异常状态，则可能得到以下结果：

NAME                                 READY   STATUS             RESTARTS   AGE
demo-test-my-nginx-6b78f5fc8-f9rkz   0/1     CrashLoopBackOff   3          86s

CrashLoopBackOff 是一种异常的状态，除此之外还可能出现一些其他的异常状态，比如：OOMkilled 、 Evicted等。对于每一种错误类型的处理也不尽相同。这需要非常丰富的 Kubernetes 问题排查经验。

比如对于 CrashLoopBackOff 这种异常状态，它意味着 Pod 中的某个容器无法正常运行，代码运行过程中遭遇了不可容忍的问题，报错退出了。正确的处理，是应该查询问题 Pod 的日志，了解业务代码层面的异常。

$ kubectl logs -f <podName> -n <nameSpace>

这种排查的思路是可以固化的，与所部署的业务系统本身没有关系，所以 Rainbond 云原生应用管理平台做了一些人性化的设计，如果业务系统的 Pod 处于这种异常状态并被操作记录捕获，那么用户点击这条异常的操作记录，即可直接跳转到日志页面查看问题日志。这种设计隐式的为用户提供了排查思路，即使用户自己并没有意识到应该这么做。

还有一种特殊类型的运行过程中问题需要注意。 CrashLoopBackOff 这种问题一般出现在 Pod 启动时，用户很容易就可以捕捉到，而类似于 OOMkilled 这种问题一般是在业务系统运行很久之后，才会出现。这种问题不容易被用户捕捉到，这是因为 Kubernetes 会自动重启出现这类问题的业务系统 Pod 来自动恢复，从而导致问题的湮没。

Rainbond 云原生应用管理平台会自动记录这一类异常状态，并留下相应日志供后续的分析，了解到到底是 Pod 中的哪个容器导致了内存泄露。

写在最后​

基于原生 Kubernetes 进行业务系统的各阶段问题排查，需要开发人员对 Kubernetes 知识体系有较深入的了解，并且能够接受命令行交互式操作体验。这无形中提升了对开发人员的技术要求，也对其强加了一些运维领域的工作内容，使云原生落地体验受阻。开发人员也不应该拿到可以直接操作 Kubernetes 的命令行权限，这不符合安全规定。

为了能够让开发人员合理的调试业务系统，选用一款云原生管理平台将会是个正确的选择。云原生应用管理平台的设计者，深入了解过开发人员的诉求，通过为开发人员提供简单易用的功能，以及人性化的设计，让开发人员调试业务系统变得事半功倍。

如果你想从解决方案角度判断“业务怎么迁、环境怎么装、平台为什么适合长期承载”，建议进入 离线 / 信创 / 国产化专题；如果你当前只关心迁移路径，可以直接看 x86 到 ARM 迁移专题页。

兼容性问题核心是什么？​

本质上是指令集架构的差异导致的。X86 与 Arm 的指令集如同两种不同的语言体系，X86 容器镜像就像用中文写的说明书，直接放到 Arm 架构环境中，系统读不懂指令逻辑。传统迁移需要手动修改 Dockerfile、重新编译依赖，甚至调整源码中与架构相关的底层逻辑。我们之前迁移一个 Java 微服务时，光改环境配置就花了两天，还得逐个确认各模块的依赖，整个过程就像在拼一幅缺少说明书的复杂拼图。

Rainbond 的自动化适配咋玩？​

最近在项目中实践的 Rainbond 方案，确实提供了更高效的路径。其核心逻辑是通过源码构建流程的自动化适配。我们在测试环境用一个 Spring Boot 应用做过验证：直接提交 X86 架构下的原始源码，平台会自动识别目标 Arm 架构，完成依赖解析、编译环境适配及镜像构建，整个过程无需修改一行代码。

实测步骤拆解​

第一步：部署 Rainbond

在你的终端执行如下命令，10分钟就可以把 Rainbond 单机版跑起来。

curl -o install.sh https://get.rainbond.com && bash ./install.sh

划重点：这行命令默认装的是单机版，Arm64 服务器直接跑就行。要是后续想组集群，Web 页面里点几下就能添加多台 Arm 主机。

第二步：准备 RuoYi 项目源码

为啥拿 RuoYi 开刀？实话说，这框架太常见了，后台管理系统十有八九是它改的，而且自带 Maven 多模块结构，特适合测迁移兼容性。我从 Gitee 拉了最新版源码，特意没改任何配置，就想看看 Rainbond 能不能硬扛祖传代码。

小插曲：有同学问能不能直接传 Jar 包？试过了！Rainbond 可以直接上传 Jar 包构建服务，平台会自动识别为 Java 应用，不过源码迁移的好处是能直接改代码。

第三步：在 Rainbond 上创建应用

• 进入 Rainbond 的工作空间，新建应用 -> 选择从源码创建。并填写对应信息，仓库地址为：https://gitee.com/y_project/RuoYi.git。

• 检测出 Java Maven 多模块，进入多模块配置页面，勾选 ruoyi-admin 即可，其他都是依赖项。

• 点击开始构建后，控制台实时刷出日志：先下 Arm 版 JDK 1.8，再解析 pom.xml 里的依赖......到最后自动打镜像、运行。

后端跑起来后，我顺手把 RuoYi 的前端也迁了。流程几乎一样：

1. 源码扔到 Git 仓库
2. 在 Rainbond 选源码构建
3. 平台自动识别出 Node.js 前端项目，装 Arm 版 npm、编译打包......

End​

在信创转型的大背景下，技术工具的价值不仅在于解决问题，更在于提升转型效率。建议有迁移计划的同学可以提前在测试环境验证 Rainbond 的方案。

欢迎加入 Rainbond 交流群，进入 Rainbond 官网 https://www.rainbond.com 扫描首页社群二维码入群。

作为IT管理者或资深技术人员，您是否也常常面临这样的困惑：资源池看似庞大，实际利用率却不尽如人意？应用的上线、升级、扩容流程依旧繁琐，运维团队的压力有增无减？供应商交付的系统如同黑盒，后续的自主维护与迭代举步维艰？

倘若这些场景让您似曾相识，那么，或许是时候将目光投向一种以应用为中心的IT管理新范式了。诸如Rainbond等现代应用管理平台，正通过革新应用交付与运维模式，切实帮助企业IT摆脱传统虚拟化模式下的一些固有困境。

传统虚拟机模式：那些习以为常却不容忽视的痛点​

在深入探讨新范式之前，让我们不妨共同回顾一下，在应用管理这个核心环节上，传统虚拟机模式常常会让我们遭遇哪些挑战：

1.资源利用率的隐形浪费：

• 每一台虚拟机都承载着独立的操作系统内核、系统进程及各类库文件。这本身就意味着相当一部分计算和存储资源的固定开销。即便虚拟机上运行的应用负载不高，这种空载或轻载的资源消耗依旧存在，日积月累，不容小觑。

图解： 下面的虚拟机模式，每个应用都需背负一套完整的操作系统开销。上面基于容器的现代应用平台，多个应用共享宿主机操作系统内核，资源更为轻量，这意味着在同样的硬件条件下，能够承载更多的应用实例，从而有效提升整体资源利用率。

2.面向机器而非面向应用的管理困境：

• IT管理员的日常工作，更多是围绕虚拟机的生命周期（如创建、配置、打补丁、监控CPU/内存指标等）展开，而非直面应用本身。应用的部署、升级、故障排查等操作，往往需要运维人员深入到每一台虚拟机内部进行，管理半径过大。
• 当应用数量持续增长，虚拟机数量也随之线性膨胀，管理的复杂度和出错的概率也水涨船高。

3.应用交付与运维的慢与重：

• 部署周期长： 一个新应用的上线，从申请虚拟机资源、安装操作系统、配置运行环境到最终部署应用，整个流程往往耗时良久，难以适应快速变化的业务需求。
• 升级维护难： 应用版本的升级通常涉及多台虚拟机，确保环境一致性、执行顺序、以及必要的回滚预案，都对运维团队是不小的考验，且风险较高。
• 弹性响应滞后： 面对突发的业务高峰，虚拟机的扩容（无论是纵向增加配置还是横向增加数量）通常需要分钟级甚至更长的时间，难以实现秒级的敏捷弹性。

3.标准化缺失与软件资产的无形流失：

• 来自不同供应商、或由不同团队开发的应用，其运行环境、配置方式可能五花八门，缺乏统一的交付和管理标准，给后续的集成和维护带来诸多不便。
• 项目结束或人员流动后，相关的配置信息、部署经验、排错技巧等宝贵知识，往往难以得到有效沉淀和传承，无形中造成了企业软件资产的流失和重复建设的浪费。

应用为中心的新范式：现代应用平台的价值重塑之道​

以 Rainbond 这类现代应用管理平台为例，它们通常基于容器技术（如 Docker）和先进的编排调度框架（如 Kubernetes，但对用户屏蔽了其底层复杂性），将管理的重心从传统的机器彻底转向了应用，由此为企业IT带来了多维度的价值提升：

1.显著提升的资源利用率：

• 容器技术的轻量化特性，使得应用可以实现高密度部署，从而大幅提升底层硬件资源的实际利用率。这意味着企业可以用更少的服务器资源支撑更多的业务应用，直接有效地降低IT硬件采购和运维成本。

2.以应用为中心的全生命周期丝滑管理：

• IT管理员的操作界面和管理逻辑，直接聚焦于应用本身，而非纠缠于底层的虚拟机细节。平台通常提供从应用开发（支持源码直接构建）、部署、运行监控、智能告警、弹性伸缩、版本升级、一键回滚直至最终下线的一站式可视化管理能力。

图解：平台将应用置于管理的核心，所有相关操作均围绕应用展开，整个流程高度自动化、可视化，赋予IT团队前所未有的掌控力。

3.敏捷交付与高效运维的实现：

• 极速部署： 支持从源码、标准镜像、甚至是预置的应用市场等多种来源快速部署应用，将传统数小时乃至数天的上线时间缩短至分钟级。
• 平滑升级与可靠回滚： 内置灰度发布、蓝绿部署等高级发布策略，能够在不中断业务的前提下完成应用升级；一旦新版本出现问题，亦可实现快速、可靠的一键回滚，保障业务连续性。
• 自动化弹性伸缩：可根据应用实际负载情况，自动调整运行实例的数量或资源分配，从容应对业务流量的波峰波谷，既保证服务质量，又避免资源浪费。
• 故障自愈能力： 平台能够主动监测应用的健康状态，当检测到异常时，可尝试进行自动化的恢复操作，减轻人工干预压力。

4.标准化交付与软件资产的有效沉淀：

• 应用模版机制： 无论是企业自研应用，还是来自外部供应商交付的应用，在平台上经过测试验证后，都可以一键发布为标准化的应用模版。这个模版如同一个集装箱，封装了应用运行所需的一切元素（如程序包、依赖库、环境变量、端口配置、存储声明等）。
• 构建企业级应用市场： 这些标准化的应用模版可以被集中存储、版本化管理，并共享到企业内部的应用市场或软件资产库中。新的业务项目或相似需求出现时，团队成员可以直接从中选取合适的模版，一键部署、快速复用，极大地提升了开发和交付效率，有效避免了重复造轮子的现象。供应商交付的成果也因此得以固化、传承和再利用。

图解：不同来源、不同类型的应用，通过应用模版这一核心机制，实现了标准化的封装和统一纳管，真正转化成为企业可追溯、可复用、可传承的宝贵数字资产。

5.降低技术门槛，赋能更广泛的IT团队：

• 这类现代应用平台通常会精心设计用户交互界面，将底层诸如K8s等复杂技术的细节进行封装和屏蔽。这意味着，企业的信息化人员，即使没有深厚的容器编排或云原生技术背景，也能够相对轻松地完成应用的部署、管理和日常运维工作，从而降低了对少数高级专业运维人才的过度依赖。

直观对比：传统虚拟机管理模式 VS 现代应用平台​

并非全盘否定，而是面向未来的更优演进​

在此需要清晰指出的是，倡导现代应用平台并非主张对虚拟机进行一刀切式的全盘否定。在某些特定的应用场景下，例如那些需要完整操作系统级别强隔离的特殊应用、无法或极难进行容器化改造的超大型单体遗留系统、或对特定硬件驱动有强依赖的场景，虚拟机依然有其不可替代的用武之地。

然而，对于当今企业中绝大多数的应用，尤其是那些采用微服务架构、追求云原生特性、以及需要快速迭代和高效运维的业务系统而言，以Rainbond为代表的现代应用平台，无疑提供了相较于传统虚拟机管理模式更为优越、更具前瞻性的解决方案。它更像是一种技术范式的演进与升级，其核心价值在于帮助企业IT团队从繁重且琐碎的机器运维中解放出来，从而能够将更多的精力聚焦于应用价值的创造、交付与持续优化。

结语：拥抱变革，迎接IT管理的新时代浪潮​

在企业数字化转型的汹涌浪潮之下，IT部门正经历着从传统的成本中心到驱动业务创新的价值中枢的角色转变。选择并运用恰当的工具、平台与方法论，对于提升整体IT效能、有力支撑业务发展与创新，显得尤为关键。如果您的团队仍在为虚拟机的资源利用率瓶颈、应用部署运维的低效、以及软件资产的有效管理与传承等问题而深感困扰，那么，不妨花些时间，深入了解一下以Rainbond为代表的这种以应用为中心的IT管理新范式。这，或许正是您突破当前瓶颈、引领企业IT架构实现现代化升级的关键一步，并可能为您的企业IT效能带来质的飞跃。

如果你不是只想看单篇教程，而是想先判断“纯离线安装、鲲鹏 / 麒麟部署、x86 到 ARM 迁移、信创平台能力”之间的关系，建议进入 离线 / 信创 / 国产化专题，当前这篇对应的是 鲲鹏 / 麒麟部署子页。

一、环境规划​

准备至少两台机器。

二、准备离线包​

2.1 准备 RKE2 离线包（K8s）​

下载 RKE2 v1.30.4 离线安装包。

wget https://pkg.rainbond.com/rke2/v1.30.4+rke2r1/rke2-images-linux-arm64.tar
wget https://pkg.rainbond.com/rke2/v1.30.4+rke2r1/rke2.linux-arm64.tar.gz
wget https://pkg.rainbond.com/rke2/v1.30.4+rke2r1/sha256sum-arm64.txt
wget https://rancher-mirror.rancher.cn/rke2/install.sh

2.2 准备 Helm 离线包​

下载 Helm 二进制离线包。

wget https://get.helm.sh/helm-v3.18.1-linux-arm64.tar.gz

2.3 准备 Rainbond 离线包​

使用脚本下载 Rainbond 离线镜像。

cat >download_rbd_images.sh <<'EOF'
#!/bin/bash

IMAGE_DOMAIN=registry.cn-hangzhou.aliyuncs.com
IMAGE_NAMESPACE=goodrain
VERSION=v6.3.0-release

image_list="${IMAGE_DOMAIN}/${IMAGE_NAMESPACE}/rainbond:${VERSION}
${IMAGE_DOMAIN}/${IMAGE_NAMESPACE}/rbd-chaos:${VERSION}
${IMAGE_DOMAIN}/${IMAGE_NAMESPACE}/rbd-mq:${VERSION}
${IMAGE_DOMAIN}/${IMAGE_NAMESPACE}/rainbond-operator:${VERSION}
${IMAGE_DOMAIN}/${IMAGE_NAMESPACE}/rbd-worker:${VERSION}
${IMAGE_DOMAIN}/${IMAGE_NAMESPACE}/rbd-api:${VERSION}
${IMAGE_DOMAIN}/${IMAGE_NAMESPACE}/rbd-init-probe:${VERSION}
${IMAGE_DOMAIN}/${IMAGE_NAMESPACE}/rbd-monitor:v2.20.0
${IMAGE_DOMAIN}/${IMAGE_NAMESPACE}/apisix-ingress-controller:v1.8.3
${IMAGE_DOMAIN}/${IMAGE_NAMESPACE}/apisix:3.9.1-debian
${IMAGE_DOMAIN}/${IMAGE_NAMESPACE}/local-path-provisioner:v0.0.30
${IMAGE_DOMAIN}/${IMAGE_NAMESPACE}/minio:RELEASE.2023-10-24T04-42-36Z
${IMAGE_DOMAIN}/${IMAGE_NAMESPACE}/rbd-db:8.0.19
${IMAGE_DOMAIN}/${IMAGE_NAMESPACE}/registry:2.6.2
${IMAGE_DOMAIN}/${IMAGE_NAMESPACE}/alpine:latest"

for image in ${image_list}; do
    docker pull "${image}"
done

docker save -o rainbond-offline-images.tar ${image_list}
EOF

获取 Rainbond Helm Chart 包。

git clone -b main --depth=1 https://github.com/goodrain/rainbond-chart.git

三、离线部署准备​

以下操作在离线的麒麟 V10 服务器上执行。

3.1 导入离线包​

导入上述准备的离线包。

3.2 安装 Helm 命令​

解压离线包并将二进制移动到可执行目录。

tar zxvf helm-v3.18.1-linux-arm64.tar.gz && cp linux-arm64/helm /usr/local/bin

四、离线部署 K8s（RKE2 方式）​

4.1 配置 RKE2 参数​

1. 创建 RKE2 配置文件目录。

mkdir -p /etc/rancher/rke2/config.yaml.d

2. 配置 RKE2 参数，需禁用默认 Ingress 这会与 Rainbond 网关冲突。

cat >/etc/rancher/rke2/config.yaml.d/00-rbd.yaml <<EOL
disable:
- rke2-ingress-nginx
system-default-registry: registry.cn-hangzhou.aliyuncs.com
EOL

3. 配置私有镜像仓库，goodrain.me 是 Rainbond 默认安装的私有镜像仓库域名。

cat >/etc/rancher/rke2/registries.yaml <<EOL
mirrors:
  "goodrain.me":
    endpoint:
      - "https://goodrain.me"
configs:
  "goodrain.me":
    auth:
      username: admin
      password: admin1234
    tls:
      insecure_skip_verify: true
EOL

4.2 安装 RKE2（K8s 集群）​

1. 将 RKE2 离线镜像包放到指定目录，启动时它会自动加载离线镜像包。

mkdir -p /var/lib/rancher/rke2/agent/images
cp /root/artifacts-rke2/rke2-images* /var/lib/rancher/rke2/agent/images
# 同时将 Rainbond 离线镜像包也放入该目录
cp /root/rainbond-offline-images.tar /var/lib/rancher/rke2/agent/images

2. 准备安装目录。

mkdir /root/artifacts-rke2

3. 将 rke2、rke2-images、sha256sum 移动到一个目录中，如下所示：

mv install.sh rke2* sha256sum* /root/artifacts-rke2
cd /root/artifacts-rke2

4. 执行安装命令。

INSTALL_RKE2_ARTIFACT_PATH=/root/artifacts-rke2 sh install.sh

5. 启动 RKE2 服务。

systemctl enable rke2-server.service && systemctl start --no-block rke2-server.service

6. 查看启动日志，大概需要 5-10 分钟才能完全启动。

journalctl -fu rke2-server

4.3 配置 Kubectl（K8s 命令行工具）​

1. 配置 Kubectl 访问。

mkdir /root/.kube
cp /etc/rancher/rke2/rke2.yaml /root/.kube/config
cp /var/lib/rancher/rke2/bin/kubectl /usr/local/bin

2. 验证 K8s 集群状态。

kubectl get node
kubectl get pod -n kube-system

五、离线部署 Rainbond V6​

5.1 配置 Rainbond 安装参数​

1. 创建 Helm values.yaml 配置文件。

cat >values.yaml <<EOL
Cluster:
  #集群入口IP，网关节点的公网IP或者内网IP，或者网关节点之上的负载均衡
  gatewayIngressIPs: 192.168.0.100

  nodesForGateway:
  # k8s节点外网IP，没外网IP填写内网IP
  - externalIP: 192.168.0.100
  # k8s节点内网IP
    internalIP: 192.168.0.100
  # k8s节点名称，通过 kubectl get node 获取
    name: ecs-c893
# - More nodes for gateway
  nodesForChaos:
  # k8s节点名称
  - name: ecs-c893
# - More nodes for chaos
  containerdRuntimePath: /var/run/k3s/containerd  # containerd.sock文件路径
Component:
  rbd_app_ui:
    env:
    - name: DISABLE_DEFAULT_APP_MARKET # 禁用默认在线开源应用商店
      value: "true"
EOL

5.2 离线安装 Rainbond​

1. 执行命令离线安装 Rainbond。

helm install rainbond ./rainbond-chart --create-namespace -n rbd-system -f values.yaml

2. 执行完安装命令后，在集群中执行以下命令查看安装状态。

watch kubectl get pod -n rbd-system

3. 当名称包含 rbd-app-ui 的 Pod 为 Running 状态时即安装成功。如下所示，Pod rbd-app-ui-678979c995-94kzb 为 Running 状态时，表示 Rainbond 安装成功。

如果你需要在离线环境下使用 Rainbond 的源码构建功能，你需要额外下载离线源码构建的离线包，请阅读 Rainbond 离线环境下使用源码构建文档。

六、部署验证​

6.1 访问 Rainbond 验证​

1. 使用 gatewayIngressIPs 配置的 IP 地址访问 Rainbond，例如: http://192.168.0.100:7070。

2. 填写 Rainbond 注册信息并登录 Rainbond。

3. 查看集群信息。

6.2 快速部署测试应用​

以 Nginx 为例，在工作空间 -> 容器，通过 Nginx 镜像部署个应用。如下：

最后​

按照本指南操作，即使是非技术背景的管理者也能独立完成国产化容器平台的落地。接下来，通过 Rainbond 图形化界面，无需编写代码即可将企业应用轻松迁移至 Rainbond。

• 官网：https://www.rainbond.com
• Github：https://github.com/goodrain/rainbond

来自用户分享

在某事业单位做了五年运维，我和同事两个人管着十几人开发团队，还有 8 家厂商的外采系统（加起来有 30 多个应用）。两年前领导拍板上 K8s，我们熬夜搭集群、配 Jenkins 流水线，本以为能告别传统部署，结果掉进了新坑：每天 80% 时间都耗在敲 Kubectl 命令上，部署应用、调资源、查日志成了家常便饭。我们的开发团队里只有个别人懂 K8s，改完代码总得来找我们运维部署。厂商更离谱，供应商坚持要 ssh 进服务器改配置。

现状：K8s 用成了运维专属工具​

我们的现状是：

• 流水线是 Jenkins+Shell 脚本，开发提交代码后，自动触发构建自动部署，但每次来新的项目或者部署新的服务就要重新搭建流水线。

• 运维成了 K8s 翻译官，开发提需求得先翻译成 K8s 术语，比如我想加个前端服务 = Deployment+Service+Ingress。

为什么不用 PaaS 容器平台？​

起初拒绝 PaaS 容器平台有两个执念：

• 习惯了命令行：觉得敲 Kubectl 比点鼠标快，YAML 配置出错了直接 vim 修改更直接。
• 担心开发越权：怕开放 PaaS 平台后，开发误删 Namespace 或改坏配置。

现在想想，这就是典型的技术自负……

痛点爆发，30 + 应用逼出平台工程需求​

今年初新接 5 个外采系统后，运维组彻底绷不住了：

• 人力告急：我和同事每天加班到 9 点，还是处理不完部署需求，某次厂商更新导致集群崩溃，我们通宵抢救。
• 开发抱怨：前端改个页面要等运维 2 小时，开发组长甩来一句：你们运维是不是该扩招了？
• 领导卡成本：申请招人被驳回，理由是数字化转型要降本增效，试试平台工程，这词我还是第一次听说。

平台工程初探索​

查资料发现平台工程说白了就是让专业的人干专业的事。开发专注写业务代码，不用学 K8s 术语。厂商专注交付应用，不用懂容器技术。运维专注底层稳定性。就像餐馆里，服务员不用会炒菜，厨师不用擦桌子，老板不用端盘子，各干各的，效率才高。

于是我尝试了国内热门的容器平台：

• Rancher：功能强但开发玩不转。优点是多集群管理确实牛，权限配置颗粒度高。致命伤是我们开发玩不转，都是 K8s 的概念，太复杂了。

• KubeSphere：界面炫但操作反人类。优点是应用商店和多租户界面看着很先进。致命伤也是太复杂，虽然集成了很多工具，比如流水线、服务网格等等，这些我们都用不到。最基本的是我们开发连工作空间 - 项目 - 应用三级结构都搞不懂。

这俩平台都像给运维用的高级 K8s 管理工具，跟平台工程理念还差点意思。

偶然发现 Rainbond​

在技术论坛刷到一篇讲述平台工程的文章，其中就提到了 Rainbond 能让开发不用学 K8s 也能自服务。抱着死马当活马医的心态试了试，结果被我需要的三个功能惊艳到：

开发自服务：拖代码就能部署，不用写 YAML

• 开发把 Java 代码拖进界面，直接下一步点点点，平台自动生成镜像 + 部署。
• 前端部署 Vue 项目，直接上传打包后的静态资源，平台自动生成 Nginx 配置。

厂商自助接入：独立空间 + 模板化部署

• 给每家厂商开独立团队空间，限制 CPU / 内存使用。
• 某厂商交来 JAR 包，他们自己上传部署，也是下一步点点点，15 分钟完成部署。

运维解放：从执行者变规则制定者

• 把常用中间件（Redis/MySQL）做成应用模板放到 Rainbond 内部的组件库，开发直接安装复用。
• 平台本身就包含了应用部署的规范，不管是开发还是厂商都按照这个执行。

现在的运维组​

2 个人管 50 + 应用不是梦。

最后​

这是我从传统运维转型平台工程的真实经历，说实话，单位里的业务系统涉及敏感信息，截图就不往外放了，但踩过的坑和尝到的甜头必须唠唠：

• 效率提升是真的香：以前 2 个人管 30 个应用累到吐血，现在管 50 + 应用还能准点下班，开发自己部署、厂商自助更新，运维只负责底层不出问题就好。
• 平台工程不是噱头：Rainbond 把 K8s 封装成了傻瓜式，开发不用学 YAML，厂商不用懂容器，这才是该有的降本增效。
• 踩过的坑不想让你再踩：Rancher 和 KubeSphere 不是不好，只是更适合大团队，像我们这种 2 个运维 + 十几开发的配置，Rainbond 的轻量级适配性更强。

如果你们单位也在搞云原生转型，尤其是运维人力紧张、开发对 K8s 不熟悉的情况，真心建议试试 Rainbond 社区版（开源免费的！）

做了五年运维，最深刻的感悟是：技术自负是效率的天敌。以前总觉得懂 Kubectl 命令才专业，直到被平台工程打脸，真正的专业不是炫技，而是让复杂技术为业务服务。现在我常跟新人说：能让开发和厂商爽的运维，才是好运维，而 Rainbond，就是那个让所有人都爽的神器。

虚拟机的黄金时代与瓶颈​

虚拟机的优势毋庸置疑：

• 资源隔离：不同业务、不同团队可以运行在各自的虚拟机里，互不干扰。
• 灵活分配：可以按需“划分”CPU、内存，满足不同业务的需求。
• 兼容传统应用：老旧软件可以原样运行，无需大规模改造。

但随着企业IT环境变得更加复杂，这些优势逐渐变成了限制：

• 资源利用率难以进一步提升：虚拟机粒度太粗，容易导致资源浪费。
• 运维复杂度高：每个虚拟机都像一个小型数据中心，升级、迁移、扩容都很繁琐。
• 交付效率低：供应商交付、测试、上线、升级等流程缺乏标准化和自动化，协作成本高。
• 软件资产沉淀不足：交付成果分散在各个虚拟机里，难以统一管理和复用。

技术趋势：从“机器为中心”到“应用为中心”​

云原生、DevOps、微服务……这些新兴理念的本质，都是把IT管理的重心，从“机器”转向了“应用”。企业更关注“我能不能快速上线一个新功能”“能不能自动回滚升级”“能不能让不同团队独立协作而又互不干扰”。而这些诉求，恰好是传统虚拟机模式难以满足的。

Kubernetes等容器编排技术的兴起，进一步加速了这一趋势。它们用更细粒度的资源调度、更高效的环境隔离、更自动化的运维方式，逐步取代了虚拟机在很多场景下的地位。但Kubernetes本身门槛较高，对企业IT团队的技术要求也更高。

统一资源管理与自动化运维：新一代平台的核心​

在这场技术变革中，企业需要的是一个能够统一管理所有IT资源、简化运维复杂度、提升交付效率的平台。它不仅要兼容现有的物理服务器、虚拟机、Kubernetes集群，还要让不同的团队、供应商可以像“搭积木”一样协作交付和管理应用。

更重要的是，企业希望软件交付的每一步都能被记录、可追溯，形成真正的“软件资产”，而不是一堆“用完即弃”的虚拟机镜像。

Rainbond：应用为中心的企业IT新范式​

在这样的背景下，像Rainbond这样的应用管理平台应运而生。它并不是简单的“虚拟机替代品”，而是站在更高的视角，重新定义了企业IT的运维、交付和资产管理方式。

Rainbond的核心逻辑是：

• 用“应用模版”替代传统的“虚拟机镜像”，让每一次交付都能标准化、自动化、可追溯。
• 通过可视化管理中心，把物理机、虚拟机、Kubernetes集群统一纳管，资源分配灵活，既能独享也能共享。
• 让供应商拥有独立的测试空间，交付成果一键上线、升级、回滚，极大提升协作效率和安全性。
• 屏蔽底层技术细节，让普通信息化人员也能轻松管理应用，极大降低人力成本和出错率。

结语：虚拟机不会消失，但它的主角时代正在远去​

虚拟机依然有它的用武之地，比如兼容某些老旧系统。但在企业IT日益自动化、协作化、资产化的今天，“应用为中心”的管理模式正成为主流。Rainbond等平台的出现，标志着企业IT正从“机器为中心”迈向“应用为中心”的新阶段。

也许，是时候跟虚拟机说再见了。

第一个跳进脑海的方案就是 Dify。作为最近一直在关注的工具，它在文档处理上的灵活性特别吸引我 —— 既能像搭积木一样定制问答逻辑，又能完美适配本地化部署环境，天生契合既要智能高效，又要安全合规的需求。于是赶紧搜了一波资料，发现确实有不少可参考的实践经验，但系统从零搭建的教程却不多。想着可能有不少朋友和我一样，既想拥有专属的知识库系统，又苦于没有清晰的入门指引，索性决定把自己的实践过程整理出来。

接下来这篇文章，就打算用最接地气的方式，手把手带你从 0 到 1 搭建一套专属的本地知识库系统。无论你是想优化企业内部文档检索（不用担心敏感数据上传云端的风险），还是像我一样想为用户打造更智能的文档服务，都能跟着步骤一步步实现。咱们不卖关子，直接上干货。

Dify​

Dify 是一款开源的大语言模型(LLM) 应用开发平台。它融合了后端即服务（Backend as Service）和 LLMOps 的理念，使开发者可以快速搭建生产级的生成式 AI 应用。即使你是非技术人员，也能参与到 AI 应用的定义和数据运营过程中。

部署 Dify​

Dify 官方提供了使用 Docker Compose 部署的方式，如下：

$ git clone https://github.com/langgenius/dify.git --branch 0.15.3
$ cd dify/docker
$ cp .env.example .env
$ docker-compose up -d

你可能会遭遇无法获取 Github 代码、Docker 镜像等问题，需要挂🪜解决。

使用 Rainbond 部署​

对于不熟悉 K8s 的伙伴，又想在 K8s 中安装 Dify，可以使用 Rainbond 来部署。Rainbond 是一个无需了解 K8s 的云原生应用管理平台，支持通过可视化界面管理容器化应用，提供应用市场一键部署、源码构建等能力，帮助用户在不接触 K8s 底层的前提下，轻松实现应用的生产级部署与运维。

免费试用 Rainbond Cloud（零门槛快速体验）

如果你想零成本快速上手云原生部署，推荐直接体验 Rainbond Cloud（点击注册 https://run.rainbond.com，新用户即享免费额度）—— 无需自备服务器或配置复杂环境，注册登录后，在云端环境中一键部署 Dify，5 分钟内即可开启 AI 应用开发。

私有化本地部署（企业级可控性首选）

如果需要将 Dify 部署在自有服务器或数据中心（满足数据本地化、合规性要求），Rainbond 提供极简私有化部署方案，无需手动编写 K8s 配置，10 分钟内即可完成生产级环境搭建：

curl -o install.sh https://get.rainbond.com && bash ./install.sh

等待几分钟后，通过 http://IP:7070 访问 Rainbond 并注册登录。

通过应用市场一键部署 Dify

创建应用并选择通过应用市场部署，在开源应用商店中搜索Dify ，点击一键安装。

等待拓扑图中的组件颜色全部变为绿色则代表部署成功。

由于应用模板给每个组件分配的资源比较少，只能保障基本运行，在实测过程中索引 200 个文档左右 Worker 等服务就发生了 OOM。需要在安装完成后手动调整下相关组件的资源，比如 API、Worker、Plugin、Sandbox 组件的资源配额。进入到组件内 -> 伸缩，修改资源为 500m、1G ，具体根据实际情况来调整。

点击访问按钮即可通过平台生成的域名访问 Dify 可视化界面，注册即可开始 AI 应用开发之旅。

配置 Dify 使用本地大模型​

关于如何在本地部署 DeepSeek R1 大模型可以参考我写的上一篇文章 K8S 部署 Deepseek 要 3 天？别逗了！Ollama+GPU Operator 1 小时搞定，同时在哔哩哔哩也有视频。

添加 Embedding 模型​

Embedding 模型就像一个语义转换器：把我们写的文字、上传的文档这些人类能看懂的内容，变成机器能计算的数字指纹（向量）。比如怎么备份文件和文件备份步骤，这两句话意思差不多，经过模型处理后，生成的向量也很接近，这样机器就能知道它们是同一个意思，而不是只看字是不是一样。

在咱们的知识库里，上传的资料必须先通过这个模型转换成向量，存到专门的数据库里。这样当用户用自然语言提问时，系统不是傻乎乎地匹配关键词，而是真正理解问题的意思，从数据库里精准找到最相关的内容。比如问API 调用报错怎么解决，系统能直接定位到文档里讲错误处理的部分，而不是只返回带API和报错字眼的零散段落，这一步就像给知识库建了一个语义索引，是让 AI 能读懂咱们私有数据的关键。

使用 Ollama 部署本地的 Embedding 模型：

进入 Rainbond 的 Ollama 组件内，进入 Web 终端执行如下命令：

ollama pull bge-m3

为啥选 BGE-M3？主要因为它是专为中文检索场景定制的选手，背靠中科院团队研发，天生自带中文语义理解 Buff。你也可以直接在 Ollama 里搜索其他 Embedding 模型。

在 Dify 中配置本地 Embedding 模型和 LLM 模型​

进入 Dify 页面后，点击右上角头像 -> 设置 -> 模型供应商，安装 Ollama。插件安装可能需要点时间，如未成功请再次安装。

分别对接本地的 LLM 和 Text Embedding 模型相关信息。我这里填写的是 Ollama 内网地址，因为我的 Dify 和 Ollama 部署在一个 Rainbond 集群内，就可以通过内网访问；内网地址可在 Ollama 组件内 -> 端口查看到对内服务的访问地址，如下：

踩坑：保存后模型没有添加，我又添加了好几次，最后我等了10分钟左右插件才加载好，前面重复添加的几个都出来了-。-

配置系统默认模型。

创建知识库​

点击上方的知识库按钮，创建一个新的知识库，上传本地的文档并下一步。

这里是对文档进行分段与清洗，这里都默认就可以了，具体可以参考 Dify 知识库文档。

模型记得选择我们上面配置的 bpe-m3 Embedding 模型。

等待所有文档的状态变为可用即可进行下一步。

创建聊天助手​

首先我们创建一个聊天助手应用。

添加我们上面创建的知识库

点击右上角的发布，再点击运行。

测试对话​

可以说效果还是比较不错的。如果感觉回答的效果还不满意，可以参考文档对召回参数进行调整。

最后​

到这儿，一个能读懂企业私有文档、数据完全本地化可控的 AI 知识库就搭好了！从部署 Dify 到配置 Embedding 模型，再到上传文档、创建聊天助手，每一步都是围绕让技术落地为实际需求设计的；既解决了传统文档检索的低效问题，又用本地化部署守住了数据安全的底线。把复杂的架构变成人人能用的工具，让代码和文档真正服务于业务。

如果你在搭建过程中遇到资源调整、模型适配等细节问题，别忘了回到文中看看踩坑提示；如果想进一步优化问答效果，Dify 的召回参数配置、Rainbond 的资源调度策略都有很大探索空间。现在，你可以试着让这个专属的 AI 助手回答文档问题，也可以把它分享给团队小伙伴，让知识真正流动起来。

后续我还会分享更多本地化 AI 应用的实操经验，如果你对某个环节想深入了解，或者有新的需求场景，欢迎在评论区留言。咱们下期折腾再见～👋

尤其是最近给 Rainbond 开源社区的用户答疑时，发现大家对大模型私有化部署有需求，都希望把大模型部署到企业内网，既能按需定制优化，又能保障安全合规。

网上教程虽多，但大多零散且偏向极客操作，真正能落地到生产环境的少之又少。稍微花了点时间，终于跑通了一套全链路解决方案：

• Ollama：让大模型从文件变成可运行的服务，专治模型跑不起来的千古难题。
• RKE2：RKE2 是 Rancher 推出的轻量化 K8s，比传统 K8s 节省 50% 资源，适合本地服务器。

• Rainbond：让复杂的集群管理去技术化，非运维人员也能轻松管好大模型服务。
• GPU Operator：一站式部署，显卡驱动安装零干预、容器运行时统一管理、深度集成 K8S。

这套组合对开发者和企业来说，意味着效率与安全的双重升级：开发者无需处理模型环境和集群配置，Ollama+Rainbond 让部署从 “写代码” 变成 “点鼠标”，专注业务逻辑；企业则实现数据本地化，通过 RKE2 安全策略和 Rainbond 权限管理满足合规要求，搭配 GPU Operator 提升硬件利用率，让私有化部署既简单又高效。

接下来的教程，我会从服务器准备到环境搭建再到大模型部署，拆解每个关键步骤。无论你是想搭建企业专属大模型服务，还是探索本地化 AI 应用，跟着教程走，都能少走弯路，快速落地一个安全、高效、易管理的大模型部署方案。

准备​

首先需要一台干净的 GPU 服务器，推荐硬件配置如下（以 NVIDIA A100 为例）：

• CPU：14 核及以上
• 内存：56GB 及以上
• GPU：NVIDIA A100（24GB 显存，支持其他 CUDA 兼容显卡，需确认GPU Operator 支持列表
• 操作系统：Ubuntu 22.04（需匹配 GPU Operator 支持的系统版本

部署 RKE2​

先以单节点集群为例快速落地演示。

1. 创建 RKE2 配置​

创建私有镜像仓库配置（Rainbond 默认的私有镜像仓库）

mkdir -p /etc/rancher/rke2

cat > /etc/rancher/rke2/registries.yaml << EOF
mirrors:
  "goodrain.me":
    endpoint:
      - "https://goodrain.me"
configs:
  "goodrain.me":
    auth:
      username: admin
      password: admin1234
    tls:
      insecure_skip_verify: true
EOF

创建集群基础配置

cat > /etc/rancher/rke2/config.yaml << EOF
disable:
  - rke2-ingress-nginx #禁用默认Ingress，会与Rainbond网关冲突
system-default-registry: registry.cn-hangzhou.aliyuncs.com # 国内镜像仓库
EOF

2. 安装并启动 RKE2​

通过国内镜像加速安装，提升部署速度

# 一键安装RKE2（国内源）
curl -sfL https://rancher-mirror.rancher.cn/rke2/install.sh | INSTALL_RKE2_MIRROR=cn sh -  
# 启动服务
systemctl enable rke2-server.service && systemctl start rke2-server.service

提示：安装过程约 5-20 分钟（视网络情况），可通过 journalctl -fu rke2-server 实时查看日志。

3. 验证集群状态​

安装完成后，拷贝 Kubernetes 工具及配置文件，方便后续操作：

mkdir -p /root/.kube
#集群配置文件
cp /etc/rancher/rke2/rke2.yaml /root/.kube/config
#拷贝命令行工具
cp /var/lib/rancher/rke2/bin/{ctr,kubectl} /bin

执行以下命令，确认节点与核心组件正常运行：

#查看节点状态（应显示Ready）  
kubectl get node
#查看系统Pod（所有kube-system命名空间下的Pod应为Running状态）  
kubectl get pod -n kube-system

至此，K8S 集群 RKE2 已部署完成，接下来将通过 GPU Operator 接入显卡资源，为大模型运行提供算力支撑。

部署 GPU Operator​

1. 提前准备国内镜像（解决 NFD 镜像拉取问题）​

由于node-feature-discovery（NFD）镜像默认仓库在国外，需提前通过国内镜像站下载并打标签：

export CONTAINERD_ADDRESS=/run/k3s/containerd/containerd.sock
ctr -n k8s.io images pull registry.cn-hangzhou.aliyuncs.com/smallqi/node-feature-discovery:v0.17.2
ctr -n k8s.io images tag registry.cn-hangzhou.aliyuncs.com/smallqi/node-feature-discovery:v0.17.2 registry.k8s.io/nfd/node-feature-discovery:v0.17.2

2. 安装 Helm​

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 \
    && chmod 700 get_helm.sh \
    && ./get_helm.sh

3. 配置 GPU Operator 安装参数​

创建gpu-values.yaml，指定所有组件使用国内镜像仓库（避免拉取国外镜像失败）：

cat > gpu-values.yaml << EOF
toolkit:
  env:
  - name: CONTAINERD_SOCKET
    value: /run/k3s/containerd/containerd.sock
  - name: CONTAINERD_RUNTIME_CLASS
    value: nvidia
  - name: CONTAINERD_SET_AS_DEFAULT
    value: "true"
  version: v1.17.1-ubuntu20.04
  repository: registry.cn-hangzhou.aliyuncs.com/smallqi
validator:
  repository: registry.cn-hangzhou.aliyuncs.com/smallqi
operator:
  repository: registry.cn-hangzhou.aliyuncs.com/smallqi
  initContainer:
    repository: registry.cn-hangzhou.aliyuncs.com/smallqi
driver:
  repository: registry.cn-hangzhou.aliyuncs.com/smallqi
  manager:
    repository: registry.cn-hangzhou.aliyuncs.com/smallqi
devicePlugin:
  repository: registry.cn-hangzhou.aliyuncs.com/smallqi
dcgmExporter:
  repository: registry.cn-hangzhou.aliyuncs.com/smallqi
gfd:
  repository: registry.cn-hangzhou.aliyuncs.com/smallqi
migManager:
  repository: registry.cn-hangzhou.aliyuncs.com/smallqi
vgpuDeviceManager:
  repository: registry.cn-hangzhou.aliyuncs.com/smallqi
vfioManager:
  repository: registry.cn-hangzhou.aliyuncs.com/smallqi
  driverManager:
    repository: registry.cn-hangzhou.aliyuncs.com/smallqi
EOF

4. 一键安装 GPU Operator​

# 添加NVIDIA Helm仓库并更新
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia && helm repo update
# 安装GPU Operator（指定版本和配置文件，无需修改参数）
helm install gpu-operator -n gpu-operator --create-namespace \
  nvidia/gpu-operator --version=v25.3.0 -f gpu-values.yaml

提示：等待约 3-5 分钟，通过 kubectl get pod -n gpu-operator 确认所有 Pod 状态为Running。

5. 配置 RKE2 默认容器运行时​

配置 RKE2 默认使用 nvidia 作为容器运行时

cat > /etc/rancher/rke2/config.yaml << EOF
disable:
  - rke2-ingress-nginx #禁用默认Ingress，会与Rainbond网关冲突
system-default-registry: registry.cn-hangzhou.aliyuncs.com # 国内镜像仓库
default-runtime: nvidia #指定 nvidia 为默认容器运行时
EOF

# 重启RKE2使配置生效  
$ systemctl restart rke2-server.service  
# 等待5分钟，确保所有系统Pod重新启动完成 

6. 验证 GPU 算力调度​

创建测试 Pod，验证 GPU 是否正常被 K8s 识别和使用：

# 生成测试YAML（运行CUDA示例程序）  
cat > cuda-sample.yaml << EOF  
apiVersion: v1  
kind: Pod  
metadata:  
  name: cuda-vectoradd  
spec:  
  restartPolicy: OnFailure  
  containers:  
  - name: cuda-vectoradd  
    image: registry.cn-hangzhou.aliyuncs.com/zqqq/cuda-sample:vectoradd-cuda11.7.1-ubuntu20.04  
    resources:  
      limits:  
        nvidia.com/gpu: 1  # 声明使用1张GPU  
EOF

# 部署测试Pod
$ kubectl apply -f cuda-sample.yaml

查看日志（成功标志）：

$ kubectl logs -f cuda-vectoradd  
# 输出包含以下内容则表示GPU调度正常：  
[Vector addition of 50000 elements]  
...  
Test PASSED  #CUDA程序运行通过  
Done  

至此，GPU 资源已成功接入 RKE2 集群，已经可以在 K8S 集群内实现 GPU 调度。

部署 Rainbond​

1. 添加 Rainbond Helm 仓库​

helm repo add rainbond https://chart.rainbond.com  
helm repo update  

2. 配置集群网络参数​

创建 values.yaml，指定集群入口 IP 和节点信息：

cat > values.yaml << EOF  
Cluster:  
  gatewayIngressIPs: 14.103.241.65  # 填写服务器公网 IP 或负载均衡 IP
  nodesForGateway:
  - externalIP: 14.103.241.65       # 节点公网 IP
    internalIP: 10.64.0.2       # 节点内网 IP
    name: iv-ydu8hg737ks6iplmb2ks  # 节点名称（通过 kubectl get node 查看）
  nodesForChaos:  
  - name: iv-ydu8hg737ks6iplmb2ks  # 节点名称（通过 kubectl get node 查看）
  containerdRuntimePath: /run/k3s/containerd  # 指向 RKE2 的容器运行时路径
EOF

3. 一键安装 Rainbond​

helm install rainbond rainbond/rainbond --create-namespace -n rbd-system -f values.yaml

验证安装：

kubectl get pod -n rbd-system  # 观察名称含 rbd-app-ui 的 Pod 状态  
# 当状态显示 Running 且 Ready 为 1/1 时，说明安装完成（约 5-8 分钟）  

访问界面： 通过配置的 gatewayIngressIPs 地址访问，格式：http://10.0.0.5:7070。

部署 Ollama​

1. 通过 Rainbond 可视化界面安装 Ollama​

登录后点击创建应用，选择从应用市场创建，在开源应用商店搜索关键词 ollama 并点击安装

Rainbond 会自动拉取 Ollama 镜像并部署（镜像大小约 1.2GB）

2. 按需分配计算资源​

安装完成后，进入 Ollama 组件详情页，点击其他设置调整资源配额：

• CPU / 内存：建议根据模型规模设置（如 deepseek R1 14B 版本至少 12 核 + 32GB 内存），本例中暂时不限制（设置 0 表示使用节点默认资源）
• GPU 资源：在 limits 中添加 nvidia.com/gpu: 1（声明使用 1 张 GPU）。

limits:
  cpu: 0
  memory: 0
  nvidia.com/gpu: 1

保存配置后，点击左上角的重启按钮，等待 Ollama 组件重新启动使资源配置生效。等待约 1 分钟，组件状态恢复为绿色（Running）即可开始使用。

资源配置参考表（根据模型参数选择）：

部署 DeepSeek R1​

1. 通过 Web 终端启动模型服务​

在 Rainbond 界面中进入 Ollama 组件详情页，点击右上角Web 终端进入命令行模式（需确保浏览器允许 WebSocket 连接）。 执行 Ollama 官方提供的模型启动命令（以 32B 版本为例）：

ollama run deepseek-r1:32b

提示：若终端无响应，检查集群 WebSocket 地址是否可达：进入 平台管理 -> 集群 -> 编辑集群信息，复制 WebSocket 地址。在本地浏览器或 Postman 中测试该地址连通性。

2. 配置模型访问端口​

在 Ollama 组件详情页中，找到端口设置项：

1. 将默认的 HTTP 协议修改为 TCP

2. 复制生成的访问地址（格式为 http://你的服务器IP:随机端口，如 http://10.0.0.5:30000）。

注意：若使用域名访问，请在网关管理中绑定您的域名。

接入到 Chatbox 使用​

1. 下载并安装 Chatbox​

从 Chatbox 官方网站 下载对应平台的客户端（支持 Windows/macOS/Linux），完成安装后启动应用。

2. 添加 Ollama API 地址​

进入 Chatbox 设置界面（点击左上角菜单 -> 设置 -> 模型管理）：

1. 点击添加自定义模型，选择Ollama类型
2. 在地址栏粘贴 Rainbond 中获取的访问地址（如 http://10.0.0.5:30000），点击保存
3. 系统会自动识别已部署的模型（如 deepseek-r1:32b），无需手动配置参数。

3. 开始对话​

返回主界面，选择刚刚添加的 DeepSeek R1 模型，即可进入聊天窗口：

• 输入问题，点击发送
• 模型会实时返回响应，支持流式输出和历史对话记录查看。

最后​

通过 Ollama、RKE2、Rainbond 与 GPU Operator 的高效组合，1 小时内即可完成 Deepseek 大模型的私有化部署。这仅仅是大模型私有部署的第一步，后续可依托 Rainbond 的快速开发能力，通过微服务构建、可视化编排等功能，轻松实现业务系统与大模型的深度集成，让企业在安全可控的本地化环境中，灵活调用大模型能力，加速 AI 应用落地。

n8n 是什么？​

n8n 是开源的 AI 原生工作流自动化平台。它将 AI 能力深度融入工作流编排，支持通过可视化节点拖拽调用主流 AI 服务（如 OpenAI、Hugging Face），同时允许开发者通过代码自定义 AI 逻辑，实现从数据输入 → AI 处理 → 结果应用的全链路自动化。无论是非技术人员快速搭建智能流程，还是企业级复杂 AI 场景开发，n8n 都能提供高效解决方案。

AI 核心能力：重新定义智能工作流​

开箱即用的 AI 服务节点，零代码玩转智能处理​

• 主流 AI 服务原生集成：内置 OpenAI（GPT-3/4）、Anthropic（Claude）、Hugging Face（LLaMA、Stable Diffusion）、Midjourney 等节点，无需编写 API 代码即可实现：

  1. 文本生成：自动生成邮件回复、报告摘要、客服话术（如接收到用户咨询时，调用 GPT 节点生成初步回复草稿）。

  2. 多模态处理：图片上传 → Stable Diffusion 节点生成风格化图像 → 自动保存至云存储；语音文件 → Whisper 节点转文字 → NLP 节点提取关键信息。

  3. 数据分析：通过 Google Sheets 节点读取数据 → AI 节点自动分类 / 预测（如客户流失预警、销售趋势分析）。

• 可视化 AI 流程编排：通过拖放节点连接 AI 服务与业务系统，非技术人员也能快速搭建数据输入 → 智能分析 → 业务响应的闭环。

代码级 AI 扩展，满足企业深度定制需求​

• 脚本节点嵌入自定义 AI 逻辑：在 JavaScript/Python 节点中调用本地 AI 库（如 PyTorch、spaCy）或第三方工具（如 LangChain），实现复杂智能处理：

  1. 私有模型集成：企业可加载自训练的 NLP 模型（如法律文档解析模型），对上传的 PDF 文件进行关键条款提取，结果自动填入 CRM 系统；

  2. 多模型串联：组合 GPT（意图识别）+ 自定义规则引擎（业务逻辑）+ Midjourney（配图生成），构建用户需求描述 → AI 生成图文报告 → 邮件发送的全流程自动化。

• npm 包与 AI 框架支持：通过安装 Node.js 依赖（如langchain openai），扩展 AI 功能边界，例如：基于 LangChain 构建智能问答工作流：用户提问 → 检索企业知识库 → 生成包含内部数据的个性化回答，通过 Slack 自动回复。

典型 AI 应用场景：从效率工具到智能中枢​

智能客服与客户管理​

• 工单自动化分类：用户提交工单 → AI 节点解析问题类型（如退款、技术支持）→ 自动分配负责人并生成回复模板（调用知识库节点），响应效率提升 70%；

• 客户情绪分析：社交媒体评论 → 情感分析节点打分 → 负面评价触发人工复核流程，同时自动汇总趋势报告。

生成式 AI 内容生产​

• 电商商品描述批量生成：Excel 商品列表 → n8n 读取数据 → GPT 节点生成多语言描述 → Midjourney 节点生成展示图 → 同步至 Shopify 店铺，节省 80% 人工编辑时间；

• 个性化报告生成：数据库提取客户数据 → AI 节点按模板生成定制化分析报告（如投资组合月报）→ 自动加密发送至邮箱（集成 PDF 处理节点）。

AI 驱动的运维与开发​

• 代码安全审查：GitHub PR 提交 → n8n 调用 Codex 模型分析代码漏洞 → 自动评论风险点并触发 CI/CD 流程，减少人工审计成本；

• 智能监控与故障处理：Prometheus 指标 → AI 节点预测服务器负载异常 → 自动扩容 K8s 集群 + 发送带根因分析的报警（结合日志解析模型）。

n8n 部署​

Docker 部署​

n8n 提供了使用 Docker 镜像的部署方式，如下：

docker run -p 5678:5678 docker.n8n.io/n8nio/n8n

Rainbond 一键安装​

对于不熟悉 K8s 的伙伴，又想在 K8s 中安装 n8n，可以使用 Rainbond 来部署。Rainbond 是一个无需了解 K8s 的云原生应用管理平台，支持通过可视化界面管理容器化应用，提供应用市场一键部署、源码构建等能力，帮助用户在不接触 K8s 底层的前提下，轻松实现应用的生产级部署与运维。

免费试用 Rainbond Cloud（零门槛快速体验）

如果你想零成本快速上手云原生部署，推荐直接体验 Rainbond Cloud（点击注册 https://run.rainbond.com，新用户即享免费额度）—— 无需自备服务器或配置复杂环境，注册登录后，在云端环境中一键部署 n8n，5 分钟内即可开启智能工作流设计。

私有化本地部署（企业级可控性首选）

如果需要将 n8n 部署在自有服务器或数据中心（满足数据本地化、合规性要求），Rainbond 提供极简私有化部署方案，无需手动编写 K8s 配置，10 分钟内即可完成生产级环境搭建：

curl -o install.sh https://get.rainbond.com && bash ./install.sh

等待几分钟后，通过 http://IP:7070 访问 Rainbond 并注册登录。

通过应用市场一键部署 n8n

创建应用并选择通过应用市场部署，在开源应用商店中搜索n8n ，点击一键安装。

等待拓扑图中的组件颜色全部变为绿色则代表部署成功。

点击访问按钮即可通过平台生成的域名访问 n8n 可视化界面，注册即可开始设计工作流。

最后​

n8n 通过可视化 AI 节点降低门槛与代码扩展释放潜力的双重优势，让 AI 不再局限于独立工具，而是真正融入业务流程的每一个环节。无论是个人开发者快速实现 AI 小工具，还是企业构建复杂的智能自动化系统，它都能通过高度可扩展的架构和丰富的生态，成为 AI 落地的 最后一公里解决方案。如果你正在寻找一款既能快速上手，又能满足深度定制的智能工作流平台，n8n 绝对是你的不二之选。

作为一家发展中的互联网公司技术负责人，我一直在寻找能解决团队实际问题的云原生平台。我们是一个约30人的开发团队，主要做ToB业务，产品迭代速度快，但面临以下痛点：

• 部署效率低下：每次上线都需要运维手动发布，经常加班到深夜
• 环境一致性差：开发、测试、生产环境差异大，导致"我这边没问题"成为日常对话
• 资源利用率低：服务器资源分配不均，有的过载，有的闲置
• 团队技术债务重：想用容器化和云原生技术，但大多数开发对k8s完全不懂

记得去年一次重要客户演示前，我们花了整整两天时间才完成环境搭建，最后演示时还是出了问题。那次经历让我下定决心：必须引入一套云原生平台来解决这些问题。

为什么选择开源平台​

在考察各种解决方案时，我们很快将目光锁定在开源平台上，主要原因有：

• 成本可控：中小企业预算有限，开源方案可以大幅降低初始投入
• 避免厂商锁定：开源方案能够避免被单一厂商绑定，保持技术选择的灵活性
• 社区支持：活跃的社区意味着问题能更快得到解决，不必完全依赖商业支持
• 定制能力：开源意味着我们可以根据需要进行二次开发或定制

当然，开源也带来了一些挑战，如需要自行解决问题、维护升级等，但总体来说，对于我们这样的中小企业，开源云原生平台是最合适的选择。

三个候选平台初体验​

经过初步调研，我将目标锁定在三个开源平台：Rancher、KubeSphere和Rainbond。下面分享我实际体验这三个平台的过程和感受。

Rancher初体验​

首先尝试的是Rancher，因为它在国际上评价很高。搭建过程相对复杂，我们花了2天时间才完成：

• 优势明显：集群管理功能强大，对多云环境支持优秀
• 界面专业：仪表盘数据丰富，告警系统完备
• 最大问题：几乎所有界面都直接暴露k8s概念，我们的开发直呼"太复杂"

有趣的是，我们团队中唯一熟悉k8s的架构师却非常喜欢Rancher："概念清晰，没有多余的抽象层"。这一点让我意识到，不同技术背景的团队成员对同一工具的评价可能完全不同。

KubeSphere体验​

接下来尝试了KubeSphere：

• 优势：UI设计确实比Rancher友好很多，功能分类清晰
• 监控和可观测性：集成了很多工具，开箱即用
• 挑战：虽然UI友好，但仍保留了大量k8s概念

我们用它部署了一个微服务应用，过程中遇到了一些问题：

• 开发团队需要培训才能使用基本功能
• 资源管理比较复杂，需要预先定义许多配置
• DevOps流水线功能强大但配置繁琐

Rainbond体验​

最后我们试用了Rainbond：

• 优势：部署简单，界面对开发友好，几乎不暴露k8s概念
• 直观的应用管理：服务间依赖可视化，微服务治理较易用
• 不足：对于复杂网络配置的支持有限，高级功能需要使用企业版

有意思的是，当我让三个完全不懂k8s的开发分别尝试在三个平台上部署他们的服务时，只有在Rainbond上他们能够独立完成。而在测试过程中，我也逐渐意识到这些平台可能各有所长，适合不同的场景和用户。

三个平台的深入对比​

作为技术决策者，我关注的不只是易用性，还包括功能完整性、可扩展性和成本等多方面因素：

功能完整性与生态​

Rancher：

• 最完整的集群生命周期管理
• 与云厂商集成度高，支持多种CNI和存储方案
• 缺点：应用商店相对简单，一些功能需要额外集成

KubeSphere：

• 全家桶式解决方案，集成了监控、日志、CI/CD等
• 微服务治理能力强，服务网格支持好
• 缺点：有些集成组件会增加系统复杂度和资源消耗

Rainbond：

• 应用管理和交付能力突出，组件市场丰富
• 支持多种部署方式，包括源码、镜像和Helm等
• 缺点：集群管理能力有限，企业级功能需要付费

开源社区与支持​

三个平台的开源情况各有特点：

Rancher：

• 开源许可：Apache 2.0
• 社区规模最大，全球贡献者众多
• SUSE收购后商业支持更加完善
• 文档主要为英文，中文资料相对较少

KubeSphere：

• 开源许可：Apache 2.0
• 国内外都有活跃社区，青云QingCloud商业支持
• 文档支持中英双语，对国内用户友好
• 版本迭代速度较快，功能不断丰富

Rainbond：

• 开源许可：LGPL v3
• 主要为国内社区，好雨科技提供商业支持
• 完全中文的文档和社区，沟通无障碍
• 社区规模相对小些，但响应速度快

运维负担与成本​

实际运维过程中，三个平台各有优劣：

Rancher运维经历：

• 优点：稳定性好，升级路径清晰
• 缺点：需要专人维护，问题排查需要较深的k8s知识
• 成本：技术门槛高，需要专业k8s运维人员

KubeSphere运维经历：

• 优点：监控和日志系统完善，问题定位较快
• 缺点：占用资源较多，小规模团队维护压力大
• 成本：硬件要求相对较高，需要中等k8s知识

Rainbond运维经历：

• 优点：自动化程度高，日常运维工作少
• 缺点：自定义能力相对受限，与现有工具集成需要额外工作
• 成本：硬件要求适中，基本不需要k8s知识

随着对比的深入，我们开始思考是否可以结合各平台的优势，打造一个更适合我们团队的组合方案。

最终选择与反思​

经过三个月的试点测试，我们最终根据团队实际情况做出了选择。

对于我们这种情况（开发团队k8s知识有限，希望降低运维负担），我们采用了一种组合解决方案：Rancher负责底层k8s集群的创建和管理，Rainbond负责上层应用的部署和管理。

为什么是这种组合：

• Rancher在集群管理、多云环境支持方面表现卓越，由我们的少数k8s专业人员负责操作
• Rainbond为开发团队提供简单易用的应用管理界面，让他们能够自助完成部署
• 这种"专业工具做专业事"的组合最大化了两个平台的优势
• 我们有意识地将基础设施管理与应用管理分离，形成良好的职责边界

组合方案的实施：

• 首先由运维团队使用Rancher部署和管理基础k8s集群
• 然后在集群上部署Rainbond，开放给开发团队使用
• 运维关注集群健康和资源分配，开发关注应用交付

现实的妥协：

• 这种组合方案增加了一定的架构复杂性
• 需要维护两套系统，有一定运维压力
• 一些老旧系统的集成仍然是挑战

真实收获与教训​

经过半年的实践，我们的收获与教训如下：

收获：

• 部署效率提升了约4倍，从小时级缩短到分钟级
• 责任分离更清晰：运维团队专注于基础设施，开发团队专注于应用
• 资源利用率提高了约35%，减少了资源浪费
• 环境一致性问题大幅减少，"在我这能跑"的问题少了80%

教训：

• 团队需要更多的沟通才能有效协作，尤其是运维与开发之间
• 没有充分评估未来规模扩展时的管理难度
• 某些高级功能在两平台间存在重叠，造成了一些混乱

开源平台的长期思考​

在使用开源云原生平台的过程中，我们也对开源产品有了更深的理解：

• 没有万能平台：即使是最好的平台也有短板，组合使用可能更实用
• 社区活跃度至关重要：选择开源产品时，社区活跃度甚至比功能完整性更重要
• 商业支持与开源平衡：纯社区支持有时难以应对紧急问题，适当的商业支持是必要的
• 持续关注版本更新：开源产品迭代快，需要定期评估新版本的价值与风险
• 贡献回馈：我们也开始向这些项目提交问题和改进建议，成为社区的一部分

给其他中小企业的建议​

如果你的团队正在选型开源云原生平台，我的建议是：

1. 先明确优先级：是易用性优先，还是功能完整性优先？
2. 小规模试点：每个平台都至少试用1-2周，让真实用户参与评测
3. 评估真实成本：除了软件成本，还要考虑学习成本和运维成本
4. 考察社区健康度：GitHub活跃度、问题响应速度、文档完整性等
5. 考虑混合方案：不要局限于单一平台，混合使用可能更适合实际需求
6. 没有完美方案：可能需要组合使用多个工具来满足所有需求

最后，不要被厂商或网络评价左右，最适合自己团队的才是最好的平台。每个团队的情况不同，选择也会不同：

• 如果团队k8s经验丰富，单独使用Rancher可能更简单直接
• 如果需要全面的功能且有一定学习能力，KubeSphere是好选择
• 如果开发团队不懂k8s且希望快速上手，Rainbond值得考虑
• 对于大多数复杂需求的团队，组合方案往往是最务实的选择

没有银弹，只有适合自己团队的方案。云原生转型是一场马拉松，不是短跑，选择合适的开源平台组合只是这段旅程的起点。

拥抱 Arm64 的难处​

从 X86_64 迈向 Arm64 并非易事，指令集的改变，影响半径极大。

最直接的影响，是原来在 X86_64 环境中可以正常运行的业务系统需要基于 Arm64 重新编译才可以运行。即使开发时使用的语言具备跨架构的能力，重新编译本身就是一种很繁复的工作，需要投入大量的人力成本和时间成本。

Arm64 的开发语言生态并不是那么健全，这无形中会增加了本不该开发人员关心的负担。很多语言本身的运行环境都需要重新编译，更不要提很多开源中间件的适配工作。

以上仅仅是开发人员关注的重点。

在软件交付领域，软件交付到客户环境中运行起来，仅仅是个开始。业务系统的管理、监控、迭代、容灾都是交付团队需要持续关注的点。多数交付团队在 X86_64 架构下，都已经有了自己的解决方案。那么容器、Kubernetes、DevOps 这些先进的工具方法，在 Arm64 架构下如何复刻？

解决之道​

Rainbond 可以利用自身能力抹平芯片架构的差异，无论是开发人员，还是交付人员，都可以基于 Rainbond 找到拥抱 Arm64 的解决之道。Rainbond 通过不同层次的能力来解决从 X86_64 到 Arm64 的迁移问题。

• 既有能力：Rainbond 本身是一款适用于软件交付，或者应用运维管理的云原生应用管理平台。无论是快速交付部署，还是应用的管理、监控、迭代、容灾，既有的功能已经可以满足交付运维人员的日常需求。

• 容器化技术：Rainbond 基于容器化技术实现，容器这种轻量级的虚拟化技术在 Arm64领域已然大放异彩。自从容器支持多架构之后，绝大多数开源中间件都已经提供了基于不同架构的基础镜像，Arm64 自然是其中的标配。选择容器化技术，相当于选择了 Arm64 的生态支持。

• 自身兼容 Arm64 ：Rainbond 很早就开始落子国产化架构适配，自身适配了包含 Arm64 在内的多种架构。

• 极简的开发环境部署： Rainbond 已经支持运行于各种个人平台的 Docker Desktop 环境中，开发者只需要借助一台具有 M1 芯片的 MacBook ，即可花十分钟搭建起自己的 Rainbond Arm64 开发环境，方便至极。

• 源码构建兼容 Arm64 ：这是打通迁移到 Arm64 架构的最后一环。在 Rainbond 中，开发人员可以不改一行代码，直接利用源码构建自己的业务组件，即可将之部署运行于 Arm64 环境中。目前 Rainbond 源码构建已经支持了市面上多种主流语言，围绕语言自身的各种扩展依赖已经趋于完整。

Rainbond 兼容 Arm64​

Rainbond 云原生应用管理平台可以被部署在 Arm64 环境中。从 2020 年 1 月起，Rainbond 分别和华为、飞腾进行了适配测试。经过验证，Rainbond 在 Kunpeng 920 芯片以及 FT2000+/64 这两款 Arm64 芯片上均可以稳定运行， 达到生产可用的标准。

而对于个人开发领域，Rainbond 也在持续发力。目前，Rainbond 支持在各种个人 PC 平台下利用 Docker Desktop 运行。我们将 Rainbond 的所有组件集成进一个容器，这种方式可以使得个人开发者以最简化的方式，利用十分钟时间运行起个人的开发测试环境。而对于使用具有 M1 芯片的 MacBook 个人开发者而言，就已经相当于基于 Arm64 架构进行开发了。

• 在 Mac 上运行 Rainbond，10 分钟快速安装

• 在 Windows 上运行 Rainbond，10 分钟快速安装

Arm64 中的源码编译​

Rainbond 具备的源码编译能力由来已久。该功能脱胎自 Heroku/buildpack 项目，并由 Rainbond 团队针对自身需求做了大量优化。借助其能力，使用者可以基于多种语言的源代码，跳过编写 Dockerfile 的过程，完成业务的容器化。源码编译是部署企业自行开发业务的最简单方式，仅需要提供源代码的仓库地址。

目前 Arm64 源码编译支持的语言及版本如下：

在源码构建功能适配 Arm64 之后，使用者不需要自己对业务进行容器化，仅需要提供源码即可。这种体验，可以被称之为将业务零成本迁移至 Arm64 容器之中。极大的减轻了开发人员的技术负担，降低了迁移适配成本。而这一过程中，代码运行环境的处理、扩展依赖的处理都已经由 Rainbond Arm64 源码构建能力处理完成。

源码构建的原理并不复杂：

• 基于 Builder 提供一个统一的构建环境，根据业务源代码的特征，选择对应语言的 buildpack 脚本。
• 根据 buildpack 脚本的不同，以及用户在 Rainbond 控制台中指定的版本，会从第三方对象存储（Rainbond AliyunOSS）下载对应的语言运行环境预编译包（如 Openjdk）准备基础编译环境。
• 执行预编译过程，根据用户在 Rainbond 控制台中定义的编译特性（如依赖仓库地址等）进行编译环境的配置。
• 根据用户在 Rainbond 控制台指定的编译命令，或各语言的默认值，开始进行编译工作。期间会根据语言特征执行特定的操作，比如执行勾子函数、下载指定的扩展（PHP 扩展）等。
• 将构建完成的产物统一打包，打包的格式，是 Heroku 风格的 Slug 包。
• 基于 Runner 作为基础镜像，联合 Slug 包打包成为业务容器镜像，运行时自动解压 Slug 包，根据用户指定的启动命令，完成最终的运行。

整个构建过程拥有实时推送的日志，对于开发人员而言，和在自己的开发环境中编译操作没有太多差别。而编译过程中，需要提供 Arm64 支持的包括：语言运行环境预编译包、扩展、Nginx/Httpd 等中间价都已经由官方完成适配，免去了开发人员的辛劳，少掉了不少头发。

新安装的 Rainbond 平台，在首次进行源码构建时，会拉取 builder 和 runner 镜像，这个过程会花费几分钟时间。已经在 Arm64 环境中安装过 Rainbond 的用户，可以执行以下命令，拉取最新的镜像，来获取 Arm64 源码编译能力。

以 MacBook M1 电脑上安装的 Rainbond 为例，进入 rainbond-allinone 容器中操作：

docker exec -ti rainbond-allinone bash

获取内置镜像仓库的登录密码，登录镜像仓库：

hubpassword=$(kubectl get rainbondcluster -o yaml -n rbd-system | grep password | awk '{print $2}')
docker login --username=admin --password=${hubpassword} goodrain.me

处理镜像：

images=(builder runner)
for image in ${images[@]}
  do
    docker pull registry.cn-hangzhou.aliyuncs.com/goodrain/${image}:v5.5.0-release
    docker tag registry.cn-hangzhou.aliyuncs.com/goodrain/${image}:v5.5.0-release goodrain.me/${image}
    docker push goodrain.me/${image}
  done

Rainbond 提供了示例代码，可供源码构建测试之用。

开始构建后，会自动弹出实时推送的构建日志，供开发人员了解构建进度。

当前日志中依次提供以下信息：

• 代码仓库地址
• 代码最新提交信息
• 首次源码构建拉取 builder 镜像（该过程仅在首次构建中拉取）
• 识别构建环境 CPU 架构，当前为 linux-arm64
• 识别语言及构建方式，当前为 Java-maven
• 语言运行环境版本，当前会下载 Arm64 环境可用的 openjdk1.8
• 安装 Java 语言的能力扩展，包括 Pinpoint APM agent 和 jmx-exporter
• 安装 Maven 构建环境，当前版本 3.3.9
• 执行构建命令。

接下来的输出，和标准的 Java-maven 构建输出无二，是下载 pom 及依赖的过程。在构建完成后，输出日志：

代码编译过程到此完成，接下来，runner 会利用编译打包后的 slug 文件继续构建镜像，并完成向内置镜像仓库的推送：

首次构建，会拉取 runner 镜像，这个行为只会进行一次。

至此，源代码就已经变成了可以运行的容器镜像，该镜像可以在 Arm64 环境中运行。

持续交付​

当开发者成功将自己的业务系统部署在 Rainbond Arm64 环境中后，Rainbond 已有的交付流程，就可以最大化的降低向 Arm64 环境交付的难度。通过将业务系统整体发布为应用模版，就得到了可以向最终生产环境交付的标准交付物。无论是导出为离线包，还是基于线上 RainStore 交付，都可以很方便的实现。后续的流程可以参考以往的文章或参考官方文档。

使用 Rainbond 实现离线环境软件交付

离线交付的痛点​

在传统行业，如政府、能源、军工、公安、工业、交通等行业，为了防止数据泄露和运行安全考虑，一般情况下网络会采取内外网隔离的策略，以防范不必要的风险，毕竟在安全防护方面，网络物理隔离是网络安全防御最有效的手段，而网络隔离在软件交付过程中，对于外部软件开发厂商来说将会带来一系列的交付难题，也增加大量成本投入。例如：

1. 现场安装部署和验收测试，效率低下

交付过程中需要将应用程序及依赖的所有资源安装到离线客户环境，而客户环境有可能是物理服务器、虚拟机、私有云及 K8s 容器等各种环境，加上离线环境网络的限制，就会导致离线环境安装和部署效率低下。由于安装配置过程繁复，容易出错，在最终交付环境中需要重新进行验证测试工作，也需要浪费很多时间。如果部署的是微服务架构的应用系统复杂性更高，工作量还会加倍。

2. 离线环境定制开发和产品升级，成本高

定制开发需要开发人员投入，成本本来就高，在离线环境需要根据客户反馈持续迭代，迭代过程产品不断升级，每升级一次就要走一次安装部署和验证测试过程，成本很高。如果有些工作必须驻场开发，成本更高。

3. 网络不通，无法远程运维

交付完成后，应用需要持续运维，保障运行稳定性和功能持续可用，在网络无法联通的情况下，出任何问题都需要安排人员现场支持，甚至需要安排人员长期驻场。

技术选型​

上述问题的根本原因是因为，应用系统的多环境适配、应用安装部署、应用升级、应用运维等操作自动化程度不高，需要大量人员手工操作，所以效率很低，解决问题的重点在解决应用管理的自动化。当前，云原生技术已经越来越成熟，而云原生技术主要解决的就是应用管理的自动化问题，具体有两种开源实现方案 ：

1. Rancher+Helm

Rancher 是一款 K8s 管理工具，他提供 K8s 的管理 UI，包管理使用 Helm。对应离线交付的问题，Rancher 可以安装在多种运行环境（物理服务器、虚拟机、私有云），并且提供部分应用自动化运维功能，它可以解决 多环境适配和 应用运维问题，而 应用安装部署和 应用升级问题可以通过 Helm 包解决。

2. Rainbond+应用模版

Rainbond 是“以应用为中心”的应用管理平台，应用模版是 Rainbond 对应用打包的方案，Rainbond 提供应用的全生命周期管理（应用开发、应用编排、应用交付和应用运维）。Rainbond 可以部署到各种运行环境上（物理服务器、虚拟机、私有云），还可以部署到已有 K8s 集群和 Ranchar 上，解决客户多环境适配问题；Rainbond 提供应用运维面板解决应用运维问题，使用比较简单，不需要懂容器概念；Rainbond 的应用模版是一个亮点，只要在 Rainbond 上运行起来的应用就可以一键发布成应用模版，简化了应用模版的制作，而且应用模版可以导出离线包，特别适合离线环境的 应用安装部署和 应用升级。

下面分别比较一下两个方案

Rainbond 相比 Rancher 最大的优点就是易用性，不需要学习 K8s 和容器相关技术和概念，另外，Rainbond 提供的一体化开发环境和模块编排功能，能大幅度提高定制开发的效率。Rancher 最大的优点是完全兼容 K8s 体系，如果了解 K8s 能很快上手。

Helm 和应用模版比较

Rainbond 的应用模版 跟 OAM 的设计思路完全一致，“以应用为中心”的设计理念，屏蔽掉容器基础设施的复杂性和差异性，为平台的使用者带来低心智负担的、标准化的、一致的应用管理与交付体验。

综合对比，在离线交付场景 Rainbond+应用模版的方案优势明显，下面我们结合实际例子，来讲解 Rainbond+应用模版交付离线客户的整个过程。

使用 Rainbond 应用模版进行离线环境的应用交付​

基于 Rainbond 进行离线环境的应用交付，只需将开发环境已开发好的业务发布至应用市场，基于应用市场导出应用模板的离线包，在交付环境中进行导入操作，导入后基于应用市场一键安装即可自动运行。

预先准备环境​

• 拥有两套 Rainbond 集群，模拟开发环境及交付环境(开发环境为在线环境，交付环境为离线环境)。

• 开发环境安装，参考 在线安装文档；

• 交付环境安装，参考 离线安装文档；

• 拥有 U 盘、光盘等离线环境下应用模板离线包传输介质。

1.业务部署

整个流程始于开发环境，我们首先需要将业务搬迁至 Rainbond 之上。在开发环境基于部署自己的业务，可以支持源代码或是镜像。当前以 Spring Cloud 微服务框架 Pig 为例，部署参考SpringCloud Pig 在 Rainbond 部署及应用制作。

2.应用发布

将开发测试环境已开发完成的应用发布至内部组件库：点击应用左侧导航栏 发布 按钮，选择 发布到组件库 ，该过程需要 新建应用模板，应用模板定义了以下信息:

创建应用模板后定义应用发布版本：

发布组件模型配置：

发布插件模型信息：

要发布的应用中其组件携带有插件时，会进行展示并在发布过程中跟随组件发布。

所有信息配置完毕后，点击发布按钮进行发布，业务开发过程中定义的组件间依赖关系、环境配置、持久化存储、插件、运行环境及上述定义的所有信息都将会被打包发布。

3.应用导出

将应用模板进行本地化导出，在首页应用市场中找到已发布的应用，点击最后方扩展按钮，选择导出应用模板，选择应用版本后点击应用模板规范下的导出按钮，导出过程完全自动化，待导出完成后点击下载按钮即可将应用模板下载至本地，保存至 U 盘等移动存储设备中，带到离线交付环境中去。

接下来进入离线交付流程，交付人员携带着装有离线包的 U 盘等移动存储设备，开始导入应用模版。

4.应用导入

使用已导出的应用模板在交付环境中导入，点击应用市场界面的离线导入按钮，选择本地的应用模板上传，上传完毕后选择导入范围： 企业或团队，企业为当前交付环境所有人可见，团队为指定团队下的人员可见；点击确认导入即进入自动化导入步骤。

5.一键部署

应用导入后点击安装按钮在当前交付环境即可一键部署该业务系统，该环境业务运行环境与开发环境完全一致，到此完成离线环境下的软件交付。

6.增量升级

软件在更新迭代过程中需要进行某些模块的升级，进行此类升级时即可使用增量升级来节省发布及导入导出时间。

要达成增量升级的效果，需要重新进行应用发布操作，选择之前已创建的应用模板，修改版本号，如之前版本设置为 2.9，则此次发布设置为 3.0。

在应用发布步骤选择需要进行升级的组件进行发布，而不需要选择所有组件。发布完成后，导出新版本的应用模版离线包，在交付环境中再次导入。

交付环境导入后，平台会对应用模板不同版本进行对比，并通过应用拓扑图中的待升级选项提示用户进行升级。展示版本间属性变更情况，用户选择需要升级的版本进行升级即可，平台将自动执行升级操作，变更组件构建版本。

升级过程中不会变动环境配置类信息，这类信息需要人为改动才会生效：

• 环境变量的值

• 配置文件的内容

• 持久化存储

7.一键回滚

在升级版本上线后出现异常情况需要回滚时，平台提供了一键回滚功能，在升级记录界面选择对应记录点击回滚按钮即可对升级操作进行回滚。

在回滚的过程中，新增组件并不会被删除，如需变更，需要人为操作。

8.应用运维功能

软件产品交付完成以后需要进行长期的运维，在运维层面，交付人员需要考虑服务的可用性、可伸缩性、资源监控，Rainbond 提供了诸多运维功能，例如：

• 服务性能分析

通过 Rainbond 插件机制扩展性能分析功能，服务实时性能分析插件运行在目标分析服务同一个网络空间内，监控网卡的流量来统计分析服务的工作性能，对服务本身的工作流程和性能无影响，收集服务的平均响应时间，吞吐率等主要指标。

• 资源监控报警

  基于 Prometheus 对平台及业务进行监控，基于 ETCD 动态发现 需要监控的 targets，自动配置与管理 Prometheus 服务。

• 实例伸缩

  对服务组件进行垂直伸缩或水平伸缩，在流量高峰期灵活进行扩容。

• 网关管理

  应用网关支持灰度发布和 A/B 测试功能。

场景拓展​

上面的例子主要针对常见的离线软件交付场景，但在真实的离线交付场景中，还可能存在以下场景，如：

• 离线模块定制，每个客户交付的模块不一定，根据需要在客户现场开启或关闭模块，或者模块编排。

• 离线定制开发，在离线场景下进行完整的软件开发过程，包括源码管理、源码编译、开发测试环境管理、团队协作、版本发布流程等。

总结​

本文我们分析了离线交付场景的问题，对比了可能的技术方案，并使用一个例子完整讲解离线交付全过程，整个过程自动化程度很高。使用 Rainbond 进行离线交付肯定可以提高效率，但到底在哪些方面提高我们的效率，我再总结一下：

• 离线环境应用系统一键导出和导入 交付过程中只需要携带基于 Rainbond 导出的应用模板离线包在交付环境进行导入，即可一键安装整套业务系统。

• 开发环境和离线环境完全一致 Rainbond 屏蔽了底层环境的差异，基于应用模板进行交付，模板对应用的运行环境、依赖关系进行打包，开发环境和离线环境完全一致，不需要进行重复性测试。

• 一体化客户定制环境 软件交付过程中，不同的客户会有不同的定制需求，也就意味着需要为不同客户开发不同的模块，这些定制的模块在不同项目中都不尽相同，通过 Rainbond 提供的应用编排，就可以针对不同客户编排和开启不同功能模块；如果需要定制开发，就可基于交付环境已部署的 Rainbond 直接进行离线代码开发工作，包括源码编译、配置组件运行环境等，在交付环境中完成所有定制工作。

• 离线环境客户持续交付 对于项目实施团队而言，在实施过程中需要不断将 新功能、缺陷修复 等快速落实到交付环境或用户手中，传统的持续交付过程中，离线环境下需要交付人员驻场，手动执行更新上线操作，该过程不仅增加了交付时间，且长期的手动执行操作会增加部署的风险；而 Rainbond 的持续交付能力，能够实现应用后续的增量导入、导出和版本升级，能够带来以下优势:

  • 通过自动化方式实现，有效缩短代码提交到部署上线的时间。

  • 软件在整个生命周期内都处于可部署升级的状态。

  • 简化升级步骤，使软件版本更加清晰。

  • 让交付过程成为可预期的、可视化的过程。

• 离线环境下自动化运维

  服务高可用，自容错和自恢复机制，减少人工运维，提高业务系统稳定性。

架构精简​

为了提升平台在各种场景下的稳定性与灵活性，同时减少资源占用，Rainbond v6 对底层组件进行了全面优化和整合，从根本上优化了平台的架构设计。

组件变动​

v5 包含 19 个组件，而 v6 精简至 12 个组件，新增 2 个、移除 9 个，同时合并部分功能以提升性能和易用性。

- dashboard-metrics-scraper
- kubernetes-dashboard
- metrics-server
- nfs-provisioner
+ local-path-provisioner
+ minio
rainbond-operator
rbd-api
rbd-app-ui
rbd-chaos
- rbd-etcd
rbd-db
- rbd-eventlog
rbd-gateway
rbd-hub
rbd-monitor
rbd-mq
- rbd-node-z7cpd
- rbd-resource-proxy-bf75d46df-nlqbv
- rbd-webcli-58f99f7fc5-kmxfz
rbd-worker

✅新增组件：

• local-path-provisioner：替代本地存储的实现，减少对外部存储的依赖。
• minio：替代 nfs-provisioner ，移除 v5 版本中对于存储的强依赖挂载，将部分共享读取的文件存储在 minio 中。

❌移除组件：

• kubernetes-dashboard：作为插件支持，移除默认安装。
• rbd-node：简化架构，优化服务治理模式。
• rbd-eventlog：日志存储功能被移除，部分功能合并至 rbd-api。
• rbd-resource-proxy 和 rbd-webcli：部分功能合并至 rbd-api。

🔄 优化整合：

• 移除对 ETCD 的依赖。

功能详细变动​

UI 样式调整​

在 Rainbond v6 版本中，UI 上有很多细节发生了改变，例如统一侧边栏、Tab 样式、全局字体以及全局样式等，同时在 v6.1.0 版本中优化了团队视图页面，提升用户体验和视觉一致性。

网关改进​

Rainbond v6 使用 APISIX 替代 OpenResty 作为默认网关，带来以下改进：

• 性能更高，支持动态配置。
• 扩展性更强，便于支持更多场景。

主机安装​

Kubernetes 版本升级至 1.30，采用注册安装替代传统的主动安装方式，提升了易用性。

在线升级​

新增一键在线升级功能，无需再通过命令行操作，降低维护门槛。

治理模式变更​

在 Rainbond v6 版本中，rbd-node 组件被移除，与之相关的内置 Service Mesh 功能也一并取消。

Rainbond v5 中的内置 Service Mesh 基于 Envoy 进行改造，但在实际使用中发现其在高并发场景下存在性能瓶颈，且维护成本较高。为提升系统性能并降低复杂性，Rainbond v6 默认采用了更轻量化的 Service 模式通信，简化了服务治理逻辑。

此外，为满足用户在服务治理上的多样化需求，v6 提供了灵活的扩展能力，用户可根据实际场景选择集成主流开源解决方案，如 Istio 或 Linkerd，从而更好地支持企业级流量管理和微服务治理需求。

日志管理优化​

在 Rainbond v5 版本中，系统会收集并存储每个组件的日志，这一设计虽然提升了部分场景下的用户体验，但也对底层架构带来了显著压力。特别是在日志量较大或组件数量较多的情况下，rbd-node 和 rbd-eventlog 组件容易因负载过高而成为系统瓶颈，甚至影响整个 Rainbond 平台的运行稳定性。

为了解决这一问题，Rainbond v6 对日志管理功能进行了优化：

1. 移除日志存储功能：不再对组件日志进行集中存储，仅保留日志展示功能。
2. 精简组件：移除 rbd-node 和 rbd-eventlog，进一步优化架构稳定性和性能表现。

支持扩展日志收集插件，可以采用现有的成熟方案，例如 ELK 等。

移除对 ETCD 依赖​

在 Rainbond v5 版本中，系统默认启动一个 etcd 服务供集群使用。然而，etcd 在实际运行中的作用有限，主要由于历史遗留问题，导致其在 v5 中无法轻松移除。为优化系统架构和减少不必要的资源占用，Rainbond v6 对此进行了全面调整，移除了对 etcd 的依赖。

性能优化​

Rainbond v6 对平台的整体性能进行了全面优化，重点提升了接口的响应速度，并针对高并发场景进行了深度调优。

默认注入环境变量​

在 Rainbond v5 版本中，组件启动时会默认注入环境变量，例如 TENANT_ID 等。然而，这种方式在实际使用中暴露了一些问题。例如，与 Nacos 的环境变量 TENANT_ID 发生冲突。为彻底解决此类冲突问题，Rainbond v6 对默认注入的环境变量命名方式进行了调整，所有默认注入的环境变量均以 _ 开头，例如 _TENANT_ID。

存储改进​

在 Rainbond v5 版本中，系统依赖底层的 NFS 服务来提供共享存储功能。Rainbond v6 对存储架构进行了优化，不再依赖底层存储，同时也移除了 NFS 服务，这意味着 v6 版本中没有共享存储，默认提供 local-path 本地存储供组件使用。如集群中扩展了其他存储，组件存储中会展示集群的 StorageClass 名称。

镜像、Git仓库调整​

在 v6.1.0 版本中对镜像仓库、Git 仓库配置都进行了调整，支持以用户为中心的个人配置，每个用户都可以配置自己的镜像仓库和 Git 仓库。

源码构建增强​

源码构建支持 Dockerfile 和其他语言共存，v5 版本中如果项目内存在 Dockerfile 和 Pom.xml 则 Dockerfile 优先，在 v6 版本中支持选择。

升级说明：从 Rainbond v5 到 v6​

由于架构和功能的重大变化，Rainbond v5 无法直接升级到 v6 版本。为了顺利过渡，您需要进行全新安装 v6 版本，并将 v5 中的应用迁移到新的环境。迁移过程分为以下几步：

1. 安装 v6 版本：首先，您需要全新安装 Rainbond v6 版本。请确保新环境已经设置并配置完毕。
2. 发布应用到本地组件库（v5）：在 v5 版本中，进入 应用视图 -> 应用发布，然后选择 发布到本地组件库。
3. 导出应用（v5）：在 v5 中，进入 平台管理 -> 应用市场，选择并导出应用。您可以将应用导出为文件，以便在 v6 环境中导入。
4. 导入应用到 v6 版本：在 v6 版本中，进入 平台管理 -> 应用市场，选择 导入应用；选择从 v5 导出的应用文件，将其导入到 v6 环境中，完成应用迁移。
5. 数据库迁移：如果您在 v5 中部署了数据库类应用，迁移时需要手动迁移数据库数据。请根据数据库类型和配置，执行相应的数据迁移操作，确保数据在新环境中能够正常访问和使用。

最后​

Rainbond v6 相较于 v5 版本，做出了显著的架构和功能优化。通过精简和优化，平台更加易于使用，且能够满足企业和开发者在不同应用场景下的需求。如果您正在考虑升级到 Rainbond v6，建议根据本文提供的迁移步骤，顺利过渡到新版本，以便享受更加稳定、灵活和高效的云原生应用管理体验。

当前业务模块化和解耦的问题​

• 架构耦合度还是太高，解耦的不彻底 。比如通过微服务架构拆解的微服务，受开发语言和微服务框架限制，跨开发语言不能调用，跨框架也无法使用，还受限于部署环境，换个环境需要重新解决部署问题。
• 从开发者角度定义模块，而不是从使用者角度定义模块，导致使用体验不好 。现在我们定义的模块通常都是开发定义的，由于开发离实际使用场景比较远，主观的认为模块拆的细和小，不管有什么场景需求我的模块都能复用和满足，但从使用者角度，模块拆分的越小越细，学习和使用的成本就越高，甚至根本使用不起来，很多模块化是过度的拆解和过度的设计。
• 模块化发布复杂，维护和升级成本高 。现在的模块化本身是一个开发过程，定义和打包过程都需要开发参与，导致成本高。

基于 Rainbond 应用模型的解耦和实现思路​

Rainbond 是一个云原生应用管理平台，可以管理应用全生命周期。下面我们详细讲解一下 Rainbond 如何解决上述问题。

Rainbond 的核心抽象和定义了一套应用模型，通过应用模型从架构上解决解耦问题，应用模型将应用、运维特性和底层基础设施彻底解耦，应用又由多个业务组件拼装而成，每个业务组件可以是不同开发语言和不同构建方式，只要符合业务契约就可以拼装。通过以上解耦方式，彻底将业务组件、运维能力和部署环境解耦，业务组件只需要专注纯业务，不再关心由于使用场景差异需要匹配不同开发框架、服务治理功能、运维工具和部署环境，业务组件、运维能力和部署环境实现根据使用场景自由组合和拼装。

基于业务组件的拼装场景：

• 从业务功能开发上，业务组件提供的是基于业务协议的服务，不受框架和开发语言限制，可以供其他业务场景复用；
• 从运维管理上，在开发测试环境不需要开启运维的特性，在生产环境对业务的治理、监控、性能、稳定性和安全性有更高的要求，按需开启通过插件机制实现的运维特性；
• 从部署环境上，应用模型底层实现对接标准 k8s API，所有符合 k8s 标准 API 的基础设施都可以实现对接和部署，也就实现了业务组件不需要改动就可以部署到公有云、私有云和边缘设备上。

解耦不仅能提高各种场景的灵活性，还能让业务组件、运维插件和基础设施复用率大幅度提高，当积累的可复用的能力越多，我们面对不同场景、不同用户和不同市场的响应能力也越强。

Rainbond 应用模型遵循“以应用为中心”的设计理念，将应用无关的底层复杂技术封装，简化理解和使用体验。应用模型可以以应用模版的形式展现和存储，以上可复用的能力通过应用模版发布到应用市场，供其他人使用，从而实现模块复用。通常我们实现模块化主要考虑开发者，而应用模版更多考虑使用者，从使用者角度抽象定义，让使用者能用起来，从而拉动应用模版的生产。从使用体验上，应用模版可以一键安装和一键升级，通过“拖拉拽”的方式实现业务拼装。应用模版有很强灵活性，应用模版支持不同颗粒度大小，模版和模版能拼装出新的模版，新的模版还可以持续拼装，颗粒的大小由使用者决定，由使用者赋予它意义。

应用模版具备可打包业务的能力，有四个特点：

1. 模块化，可以形成可复用的能力单元，按需拼装使用场景。
2. 自治，自给自足，可以独立安装、升级和管理，确保组合的灵活性。
3. 可编排，模版和模版可以拼装出新模版，具备无限拼装能力。
4. 可发现，通过内部服务和外部服务两种方式体现，可供业务和技术、开发者和其他应用访问。

应用模版的定义和实现内容：

• 应用基本的元数据
  • 名称
  • 时间戳
  • 版本号和别称
  • 资源占用情况
• 应用治理模式（ k8s service 模式、Service Mesh 内置和 Istio）
• 应用网关信息
  • 对外端口
  • 域名和证书
  • 发布策略
• 应用全局配置
• 一个或多个业务组件
  • 业务组件的依赖关系
  • 业务组件类型（源码、镜像、Helm 和第三方 API）
    • 组件的构建方式
    • 组件的存储方式
    • 组件的配置方式
    • 组件的运行方式
  • 业务组件的插件
  • 组件端口和协议
  • 组件环境变量

模块发布和拼装流程​

在 Rainbond 中应用模版是模块的表现形式，模块发布和拼装流程就是应用模版的发布和拼装过程。模块建设是一个长期过程，强调积累，更多是在实践过程中的沉淀，同时需要根据反馈来持续迭代。 这个过程分四步：

第一步： 模块以应用模版的形式一键发布，所见即所得​

发布业务组件首先需要从业务角度定义颗粒度和业务接口，然后将要发布的组件在 Rainbond 构建，Rainbond 支持各种构建源，构建的同时也在定义应用模版，只要构建成功，就可以一键发布成应用模版，也就意味着任何在使用平台的开发者都具备发布应用模版的能力，发布的门槛低有利于知识和经验的分享。

第二步： 通过应用市场存放不同颗粒度的模块​

应用模版支持不同颗粒度，针对不同使用场景包装不同颗粒度：

• 面向内部研发场景，主要积累技术模版，模版颗粒度相对较小，为了提高开发效率。
• 面向客户交付场景，主要积累业务模版，模版颗粒度较大，通过模版可以快速拼装客户解决方案，提高交付效率。
• 面向销售场景，主要积累可以销售的产品模版，颗粒度最大，能帮助销售快速演示、使用和整体交付。

第三步：通过应用模版实现模块化拼装​

从应用市场一键安装需要拼装的模块（应用模版），通过“拖拉拽”将多个模块拼装成需要场景，拼装后原模块发布新版本，在拼装好的场景里按需升级。新拼装好的场景发布成应用模版，可以是更大的模块支持更大场景的拼装，也通过应用模版实现后续客户交付流程。

第四步：在真实应用场景中，持续积累和迭代​

模块的建设过程，要避免过度设计和提前过度拆解，模块提早拆解或拆解的粒度太小，会导致模块开发和维护成本高，使用体验不好。所以，模块前期设计和开发只能占少部分，大部分模块在真实场景中才能看到它的价值，这时候再发布成可复用的模块，更加具备实用性。同时，模块的边界和功能在真实场景中才有意义，需要根据实际需求不断迭代。

使用场景​

可拼装的业务模块，提高开发效率和客户交付速度​

对于软件公司的研发和客户交付场景，通过可拼装的业务模块，在新项目研发和新客户交付过程中复用，减少重复性开发，能大幅度提高效率。

行业业务中台，实现行业能力积累和复用​

对于行业用户，实现数字化的过程，会建设很多套系统，这些系统有很多能力是通用的，把这些能力积累下来，后续建设过程直接复用，不仅减少了建设周期，复用成熟的能力还能提高系统成熟度。另外，需要业务融合和数据融场景，可以通过业务编排，实现系统之间的互联互通。

2B 软件公司的产品化包装和模块化销售​

对于 2B 软件公司，会面对项目个性化和产品标准化的矛盾，要解决这对矛盾有两个解决方案：一个是让个性化的项目也能快速沉淀出产品，这个过程通过发布应用模版能快速实现；另一个是将个性化的项目按模块化拆解，不同客户选择不同模块，实现根据客户需求个性化销售；这两个方案可以进一步融合，在早期，个性化项目是驱动力，项目的模版可以作为给其他客户演示和交付的产品基础，在不断的交付客户过程中，发现和拆解可复用的模块和个性化的模块，等交付客户越多，积累的可复用模块也就越多，也知道哪些模块有商业价值，模块化成为产品的基础，更好服务销售和交付，产品化也就越成熟。

多云痛点​

• 多云环境的统一监控和运维管理：：

  企业使用多云增加了统一运维管理的复杂性，对于单云架构，可使用云服务商提供的管理工具，但对于多云架构，如何使用统一平台进行运维管理，进而提升 IT 服务交付效率、增加资源利用率，降低运维成本，成为值得关注的问题。

• 多云环境下的应用管理：

  单机环境下，应用的部署、管理相对简单，对于多云的分布式环境，应用的部署、运维、标准化管理成为难点，同时，传统的应用、基于微服务架构的应用、以及近来发展迅猛的 Serverless 应用，不同类型的应用也为一站式应用管理增加了难度。

• 多云环境中核心业务迁移和部署：

  使用多云后，无法避免数据的跨云迁移，在异构的云、数据中心之间进行数据迁移，如何保证数据的一致性及低时延，又成为了新的挑战。

多云应用管理平台 Rainbond​

企业除了资源管理之外，其实应用程序管理是更贴近于企业的需求，应用有多种类型，包括传统的应用，像 Mysql、Tomcat、Nginx，还有基于微服务架构的应用、以及 Serverless 应用等。

企业需要一个可以管理各类计算资源和各类应用程序的一站式管理平台 ——— Rainbond 应运而生。

Rainbond] 是“以应用为中心“的多云应用管理平台，提供的容器多云和混合云的解决方案，为您提供跨云的多集群统一管理、应用在多云环境下的统一部署和管理。基于 Rainbond 上开发的任何运行的应用，都能够交付给任何基于 Rainbond 的应用管理平台上去使用，也就是基于 Rainbond 可以将任何应用以任何规模部署到任何云上面，对开发者来说就是 只需构建一次，即可随时随地运行。

Rainbond 与 CMP 对比​

上图中简述的绘画了 Rainbond 与传统 CMP 的对比，可以很直观看出 Rainbond 关注的是应用层面，CMP 关注的是底层计算资源。

CMP 是基于“资源”的多云管理，可以实现多云下所有资源的统一管理。例如：在 CMP 中可开通某云厂商的虚拟机，包括订单的管理等。但 CMP 对于应用的管理就相对来说弱一些，无法将多个云上的应用进行统一运维、管理。

Rainbond 是“应用级”的多云管理，通过统一的应用模型，应用可以透明在多云上运行和迁移。例如：应用在物理服务器上开发和测试，不用任何改动就可以部署到各类公有云或客户的私有云上。

多云应用管理的四个典型场景​

在 Rainbond 中实现多云目前有以下四个典型场景：

• 开发和生产环境分离：

  在 CI/CD 的场景中，一些用户出于安全的考虑，希望开发环境和测试环境部署在本地的私有云集群，生产环境部署在公有云上。通过 Rainbond 可以将开发环境、测试环境和生产环境的集群统一管理，配合容器开发流水线，完成业务上线流水化作业，提高企业代码交付和部署的效率。

• 多云应用统一管理：

  通过 Rainbond 对接和管理多云，统一管理多云下的所有应用，通过拓扑图查看业务的状态，管理应用的全生命周期，提高应用运维的效率。

• 通过应用市场实现多云应用交付：

  在行业云或 ISV 场景中，应用需要交付到各种客户场景，Rainbond 的应用市场，可以将应用以模版的形式存放到应用市场，根据需要一键交付到客户环境，根据需要还能按需升级。

• 多云应用备份和迁移：

  通过 Rainbond 实现应用从一个云备份和迁移到其他云。

具体实现​

1、通过 Rainbond 对接多云

首先需拥有可用的 Rainbond 。

完成 Rainbond 控制台的安装后，进入 Rainbond 控制台 企业视图 >> 集群 >> 添加集群，在公有云或私有云的服务器上安装 Rainbond 集群端 ，可添加并对接多个集群。

多集群对接后效果图👇

2、多云应用统一管理

当 Rainbond 对接多集群后，在 Rainbond 上可以创建和管理多团队，并为每个团队在多集群中分配资源，在团队空间中就可以管理应用全生命周期。

3、开发环境和生产环境分离

A 云上做测试/开发，B 云上进行生产 是最常见的环境分离。一般是在云上做测试/开发，在本地进行生产。但有时候可能颠倒过来，因为你可能需要云的多区域能力或者像 CDN 这种高级功能来为生产环境加速。

**例如：**在私有云环境中，部署开发环境，快速复制出测试、生产环境。快速复制支持跨团队、跨集群。

4、通过应用市场实现多云应用交付：

用户可将已部署的业务通过 Rainbond 应用发布 功能一键发布到内部应用商店，可通过应用模板对应用进行版本管理以及应用详情介绍。也可通过应用模板可在多云环境中一键部署。