3 篇博文 含有标签「版本发布」

如果说此前的 Rainbond 更擅长以应用为中心，帮助团队快速完成云原生应用的构建、交付与运维，那么从 v6.7.0 开始，Rainbond 又向 Kubernetes 原生工作流迈进了一大步。

这一版本最重要的更新，是正式支持 K8s 原生资源管理。这意味着 Rainbond 不再只服务于平台内部的应用模型，也开始更完整地承接 Kubernetes 原生对象、原生 YAML、Helm Release 以及既有 Namespace 的管理需求。对于已经深度使用 Kubernetes 的团队来说，这是一次非常关键的能力补齐。

与此同时，v6.7.0 也继续推进了 Rainbond 在开发交付链路和应用运维链路上的能力升级：

• 在构建侧，源码构建全面支持 CNB（Cloud Native Buildpacks）
• 在应用运维侧，新增 应用快照，补齐应用版本留档、导出、发布和回滚能力

支持 K8s 原生资源管理：让原生工作流也能自然融入 Rainbond​

v6.7.0 最重要的更新，是正式支持 K8s 原生资源管理。通过这组能力，Rainbond 开始提供一条更完整的 Kubernetes 原生资源管理路径，用户现在可以：

• 对接已有 Namespace，并继续按原生方式管理资源
• 通过原生 YAML 直接创建和维护 Kubernetes 对象
• 以 Helm Release 的方式安装、升级和管理应用
• 在团队视角下统一查看工作负载、容器组、网络、配置和存储等资源
• 在平台管理视角下进一步管理 StorageClass、PV、PVC 等平台级资源

这意味着，无论是已有集群资源的接管，还是后续的原生运维和问题排查，都可以在 Rainbond 中获得更统一的入口和视角。

与之前版本相比，最大的不同在于，Rainbond 不再只围绕平台内部的应用模型来承接交付流程。在过去，如果团队希望把已有 YAML、Helm Chart 或 Namespace 纳入平台管理，往往需要先适配到平台模型；而在 v6.7.0 中，用户已经可以直接保留 Kubernetes 原生语义，沿用熟悉的 YAML 和 Helm 工作流。

也就是说，从这个版本开始，Rainbond 同时承接了两种路径：既可以继续使用应用模型完成标准化交付，也可以保留 Kubernetes 原生对象结构，按原生方式进行管理。

源码构建全面支持 CNB：更快、更小、更标准​

在开发交付链路上，v6.7.0 也完成了一次重要升级：源码构建全面支持 CNB（Cloud Native Buildpacks），并采用 Paketo Buildpacks 作为核心实现。

需要特别说明的是，自 v6.7.0 起，新建的源码组件默认使用新的 CNB + Paketo Buildpacks 构建体系；由旧版本升级而来的已有组件，会继续保留原有构建方式并可继续使用。如果没有兼容性约束，建议后续优先使用新的 CNB 构建路径。

相比传统的 Slug 构建方式，这次升级带来的变化非常明确：

• 构建速度更快：在常见源码构建场景下，可以显著缩短从代码到镜像的交付时间。

• 最终镜像更小：构建产物更加精简，减少不必要的运行时负担，也更有利于镜像分发与部署。

• 构建结果更标准：基于 Cloud Native Buildpacks 生成的镜像，更符合云原生生态的标准实践，在后续运维、迁移与生态集成中也更顺畅。

其中，Paketo Buildpacks 作为目前业界较为成熟的一套 Buildpacks 实现，能够帮助 Rainbond 进一步提升源码构建能力的标准化程度。这并不只是一次底层构建方式的替换，更意味着 Rainbond 的源码构建链路正在从“能构建”走向“更标准、更现代、更云原生”。

目前，这套新的源码构建体系已经覆盖 Java、Python、PHP、.NET 等常见语言场景。对于开发者来说，这项升级最直接的感受会是构建效率更高、镜像更轻量；对于平台侧来说，它也为后续的构建能力扩展和统一治理打下了更稳定的基础。

新增应用快照：让应用版本留档、流转和回滚更清晰​

除了 K8s 原生资源管理和源码构建升级，v6.7.0 还新增了 应用快照 能力。

应用快照用于保存应用在某一时刻的版本状态，记录组件编排、配置、依赖关系和版本信息。它解决的核心问题是：当应用在持续变化时，如何保留一个可追踪、可对比、可回滚的版本基线。

基于应用快照，用户可以：

• 保存当前应用状态，形成版本时间线
• 查看历史版本与当前状态之间的差异
• 从某个快照直接导出应用
• 将快照发布到内部组件库
• 在发生问题时回滚到某个历史快照

这项能力特别适合以下场景：

• 应用完成一轮功能迭代或配置调整后，需要保留阶段性版本
• 在升级、改造、迁移前，先留存一个稳定快照
• 需要把某个版本导出交付，或沉淀到内部组件库中复用
• 发生异常变更后，希望快速恢复到已验证的稳定状态

需要说明的是，应用快照保存的是应用层元数据和编排状态，并不等同于虚拟机快照、磁盘快照或数据库备份。它适合做应用版本管理，但不能替代业务数据备份或灾备方案。

有了应用快照之后，Rainbond 在应用运维这条链路上，也进一步补齐了从版本留档、版本流转到版本回退的关键能力。

最后​

Rainbond v6.7.0 是一个方向非常明确的版本。它最重要的变化，是正式支持 K8s 原生资源管理，让 Rainbond 可以更自然地承接 YAML、Helm、Namespace 以及 Kubernetes 原生对象管理场景；与此同时，源码构建全面拥抱 CNB + Paketo Buildpacks，让构建更快、镜像更小、交付更标准；再加上 应用快照，应用版本管理链路也变得更加完整。

如果说此前的 Rainbond 更擅长“把应用跑起来”，那么从 v6.7.0 开始，Rainbond 也在更进一步地帮助团队把 原生资源、源码构建和应用版本 这三件事一起管好。

其他变更​

• Helm Chart 支持 OCI #2495
• 修复 Helm 创建应用失败 #2514
• 修复自动签发证书失败
• 修复同名软件包上传构建二次无法解压

平台升级​

• 在线环境：平台管理 -> 企业设置 -> 升级，执行一键升级。
• 离线环境：请阅读 离线升级文档。

距 Rainbond v6.0 发布已有两个月，但一直未详细说明 v5 到 v6 的具体变化。本文将重点解析两者在架构、功能及性能上的主要差异，帮助用户更好地理解升级后的优势。

架构精简​

为了提升平台在各种场景下的稳定性与灵活性，同时减少资源占用，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 源码构建服务的域名进行了调整。现将具体变更内容及相关注意事项通知如下：

变更内容​

• 原服务域名：buildpack.oss-cn-shanghai.aliyuncs.com

• 新服务域名：buildpack.rainbond.com

新域名用于在线安装模式下源码构建服务的依赖包获取，包括但不限于JDK、Node.js等构建包。

变更范围​

• 使用在线安装的 Rainbond 环境，源码构建过程中所需的 JDK、Node.js 等构建包将通过新域名 buildpack.rainbond.com获取。如果在线环境中仍使用旧域名，可能导致构建失败或依赖包无法下载的问题。
• 本次变更不影响离线安装的源码构建。在离线模式下，构建所需的依赖包已预置于本地，无需访问上述域名。

操作指导​

Rainbond v5 版本​

在 v5 版本中，您需要手动替换 rbd-resource-proxy 镜像。具体操作如下：

1.使用以下命令编辑组件：

kubectl edit rbdcomponent -n rbd-system rbd-resource-proxy

2.在编辑器中找到 spec.image部分，将镜像地址替换为以下内容：

spec:
  ...
  image: registry.cn-hangzhou.aliyuncs.com/goodrain/rbd-resource-proxy:v5-latest
  ...

3.保存并退出编辑器。

4.执行以下命令，检查镜像是否替换成功：

kubectl get pod -n rbd-system -l name=rbd-resource-proxy -o yaml

5.完成镜像替换后，尝试执行源码构建操作以验证服务是否正常工作。

Rainbond v6 版本​

自 v6.1.0 版本起，源码构建服务已默认使用新域名 buildpack.rainbond.com。如果您使用的是早期版本，请按照以下步骤进行修改。

1.编辑 APISIX Upstream 配置：

kubectl edit apisixupstream -n rbd-system buildpack-upstream

2.将 externalNodes 部分的域名替换为：

spec:
  externalNodes:
  - name: buildpack.rainbond.com
  ...

3.编辑 APISIX Route 配置：

kubectl edit apisixroute -n rbd-system lang-proxy

4.在plugins部分，将host替换为：

plugins:
  - config:
    host: buildpack.rainbond.com
  ...

5.完成配置更新后，尝试执行源码构建任务以确认服务正常。

平稳过渡​

为保证平稳过渡，旧域名 buildpack.oss-cn-shanghai.aliyuncs.com 将在2025年01月25日前继续有效。

我们强烈建议您在此日期之前尽早完成相关配置调整，以避免构建服务中断。