如果说此前的 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
- 修复自动签发证书失败
- 修复同名软件包上传构建二次无法解压
平台升级
- 在线环境：
平台管理 -> 企业设置 -> 升级，执行一键升级。
- 离线环境：请阅读 离线升级文档。
