v6.9.0-release

Rainbond v6.9.0 发布：支持大模型私有化部署，提供 OpenAI 兼容接口

Rainbond v6.9.0 正式发布。本次版本的主要更新是新增 AI 大模型私有化部署能力，覆盖模型部署、实例管理、OpenAI 兼容调用和模型监控；同时对虚拟机能力进行了一轮增强，并修复了若干已知问题。

以下是本次更新的主要内容。

AI 大模型：在自己的平台上部署和运行模型

v6.9.0 新增 AI 大模型能力，面向企业和团队的大模型私有化部署场景，支持把模型部署在自己的集群和资源中，并通过 OpenAI 兼容接口接入业务系统。启用 AI 大模型插件后，工作空间 左侧导航会出现 AI大模型 入口，下面包含模型仓库、模型实例、API 密钥和模型监控四个模块。

模型准备与部署

在 模型仓库 中选择需要部署的模型，目前支持以下几种模型来源：

• 内置模型：平台预置一批常用模型；
• ModelScope：从模型社区拉取；
• HTTP 地址 / 本地路径 / 文件上传：使用自有模型文件。

模型状态变为"已下载"后，进入部署配置。文本大模型默认使用 vLLM 引擎；GPU 部署需选择 GPU 型号、数量和目标节点，也支持 CPU 部署（适合做轻量验证）。vLLM 的量化方式、显存利用率、最大上下文长度、额外启动参数等都可以在页面上配置，建议首次部署先使用默认配置完成验证。

当前 GPU 资源识别和分配以 NVIDIA GPU 为主，启用前请确认集群环境。

模型实例管理

部署完成后，进入 模型实例 模块管理已部署的模型实例：

• 查看实例状态、节点分布、运行详情和日志；
• 对实例执行启动、停止、删除操作；
• 对运行中的实例发起在线对话，验证模型响应；
• 实例异常时，结合运行详情和日志判断是模型加载、启动参数、资源不足还是服务响应方面的问题。

API 密钥与 OpenAI 兼容调用

在 API 密钥 模块创建密钥，页面提供 OpenAI 兼容的接入示例，包括 base URL、curl 示例和 Python OpenAI SDK 示例。业务系统在原有 OpenAI 调用链路基础上替换 base URL 和 API key 即可接入。请求中按模型名称调用，平台会查找对应的运行中实例。

模型监控

模型监控 模块包含两个层面：

• 服务层面：在线服务数、健康服务数、运行实例数、请求数、失败数、平均响应时间；
• GPU 层面：GPU 总览、节点汇总、设备列表、单卡趋势、实例与设备的占用关系。

虚拟机能力增强

本次版本对虚拟机能力进行了一轮增强，主要更新如下：

• qcow2 镜像直接部署：支持将其他虚拟化工具（如 VMware、KVM 等）导出的 qcow2 镜像直接部署到 Rainbond，便于已有虚拟机资产迁移。
• 规格热更新：运行中的虚拟机支持热扩容 CPU 或内存。注意 CPU 和内存不能在同一次操作中同时热更新、仅支持扩容不支持缩容；GPU 直通和 USB 透传虚拟机暂不支持热更新；不满足条件时平台会自动转为重启生效。
• 多虚拟机应用级编排：支持把多个虚拟机和其他组件按应用方式统一编排，在拓扑图中查看依赖关系，并保留连接信息、端口、存储等应用级配置。
• 整套应用模板交付：编排好的虚拟机应用可以发布成 Rainbond 应用模板，连同虚拟机系统数据一起打包，导出 rainbond-app 安装包后可在新环境导入恢复。发布前需先创建快照并关闭虚拟机；携带虚拟机类型的模板快照不支持回滚升级。
• Windows 驱动盘挂载：在组件存储视图中支持挂载 VirtIO 驱动盘，用于解决 Windows 安装阶段识别不到磁盘或网卡的问题。
• 监控与配置统一：组件视图中支持查看虚拟机的 CPU、内存、网络流量、磁盘读写流量与 IOPS、文件系统使用量等指标；CPU、内存、磁盘、网络、GPU 直通、USB 透传等运行配置统一在组件视图中管理。

当前虚拟机仅支持 amd64 架构，arm64 暂不支持。

---

其他变更

新增功能

• 新增 AI 大模型私有化部署能力，支持模型部署、实例管理、OpenAI 兼容调用和模型与 GPU 监控
• 虚拟机支持 qcow2 镜像直接部署
• 虚拟机支持规格热更新（CPU、内存运行态扩容）
• 虚拟机支持多虚拟机应用级编排
• 虚拟机支持整套应用模板交付（连同系统数据一起打包）
• 虚拟机支持 Windows VirtIO 驱动盘挂载
• 虚拟机组件视图支持监控指标查看与运行配置统一管理

Bug 修复

• 修复 RainAgent 偶发断联、消息发送失败的问题（新增兜底机制和静默重试）
• 修复 RainAgent 接口密钥不修改时无法保存其他配置的问题
• 修复 opencode 使用 RainSkills 时 MCP 第二天过期的问题
• 优化 AI 助手更新提示信息
• 优化删除组件、端口、存储等操作的错误提示和引导
• 优化 RainAgent 错误信息的展示与稳定性
• 优化 RainAgent 操作组件时的识别准确率
• 修复 ROI 一些问题
• 修复快照/模板导入导出伸缩规则不生效
• 修复 UI 滚动条问题
• 修复对接 Harbor 无法展示更多的项目
• 修复 dockercompose 在 ARM 环境下无法构建
• 修复 Helm 默认安装无法选择节点

平台升级

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

Full Changelog: v6.8.0-release...v6.9.0-release

v6.8.1-release

What's Changed

• 平台插件支持arm和x86版本
• 优化平台插件安装流程
• 修复平台插件无法升级的问题
• RainAgent支持热更新skills
• 优化用户首次进入拓扑图页面提示
• 修复RainAgent页面卡死无响应的问题
• 优化RainAgent审批卡片展示效果
• 优化RainAgent风险操作等级

Full Changelog: v6.8.0-release...v6.8.1-release

v6.8.0-release

What's Changed

新功能

• 新增 Rainbond Agent 功能，页面内置 AI 小助手，对接大模型 API 即可在浏览器中进行部署、故障排错等
• 新增 Rainbond Skills，通过本地 Codex、Claude Code 等 AI 编程工具在本地与 Rainbond 进行交互

Bug 修复

• 修复离线环境下接口响应慢的问题
• 修复 k8s 原生资源没有展示 ingress 资源
• 修复滚动更新存储失败
• 修复发布快照的伸缩规则 CPU、内存不生效问题
• 修复 War 包部署默认端口不正确
• 修复 k8s 原生资源页面引导提示

平台升级

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

Full Changelog: v6.7.4-release...v6.8.0-release

v6.7.4-release

What's Changed

Bug 修复

• 修复离线模式下，因请求外部网络数据导致的接口阻塞及页面加载缓慢问题
• 修复 TCP 对外服务按钮的状态同步与显示逻辑
• 修复 Java 源码构建过程中，无法正确处理及打包包含中文名称文件的问题
• 修复多 Chaos 节点 SSH 密钥无法共享和丢失问题

功能优化

• 优化了组件快照发布时的交互流程
• 完善了第三方组件配置表单的校验逻辑
• 改进了前端构建源中“构建命令”表单的校验规则，避免填错
• 完善了构建源启动命令的提示信息，提供更清晰的配置引导
• 前端构建默认自动填充 .npmrc / .yarnrc 国内镜像配置
• 源码构建组件默认注入 TZ（时区）环境变量

Full Changelog: v6.7.3-release...v6.7.4-release

v6.7.3-release

What's Changed

• fix: support follow flag for pod log streaming by @yangkaa in #2562
• ci: add Go tests and manifest checks by @zzzhangqi in #2563
• fix: read event log history from jsonl store by @zzzhangqi in #2565
• chore: automate release publishing by @zzzhangqi in #2566

Full Changelog: v6.7.2-release...v6.7.3-release

v6.7.2-release

What's Changed

Bugs 修复

• 修复新增节点后没有自动处理 Hosts 解析 @zzzhangqi
• 修复 Slug Maven 默认配置前端误校验
• 修复 Slug Maven 版本无法保存
• 修复构建节点绑定了错误的 IPV6 地址
• 修复快照/模板安装的组件 TCP 端口重复问题
• 修复快照/模板安装之后组件配置文件的翻页报错
• 修复编辑组件环境变量修改 Key 不生效
• 修复大文件上传接口报错 404
• 修复组件端口是 HTTP 协议时自定义 TCP 端口无法访问 #2543
• 修复平台管理的应用市场安装的逻辑错误
• 修复底层使用自定义镜像仓库时源码构建的错误提示
• 修复DockerCompose安装后自动生成的端口无法删除
• 修复快照无法发布历史版本到本地组件库
• 修复团队管理员邀请的权限问题
• 修复快照发布时展示了错误的团队模板
• 修复二次上传压缩包没有解压
• 修复在 Arm64 架构下应用市场展示了 Amd64 应用
• 修复 HTTP 证书匹配规则 #2559 @hanxinhisen

功能优化

• 调整系统组件默认创建的 PVC 大小
• 优化组件配置文件添加的提示
• 支持组件存储修改存储配额

平台升级

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

Full Changelog: v6.7.1-release...v6.7.2-release

---

English

What's Changed

Bugs Fixed

• Fixed issue where newly added nodes didn’t automatically handle Hosts resolution. @zzzhangqi
• Fixed incorrect frontend validation for Slug Maven default configuration.
• Fixed inability to save Slug Maven versions.
• Fixed binding of wrong IPv6 address on build nodes.
• Fixed duplicate TCP ports when installing components via snapshots/templates.
• Fixed page-flipping errors in component configuration files after snapshot/template installation.
• Fixed environment variable key changes not taking effect when editing a component.
• Fixed 404 error for large file upload interface.
• Fixed custom TCP ports not accessible when component port uses HTTP protocol. #2543
• Fixed logical errors in platform-managed application market installation.
• Fixed incorrect error messages during source builds when using custom image registries.
• Fixed auto-generated ports after Docker Compose installation being undeletable.
• Fixed inability to publish historical snapshot versions to the local component repository.
• Fixed permission issues when inviting team administrators.
• Fixed incorrect team templates displayed during snapshot publishing.
• Fixed uploaded compressed files not being extracted on re-upload.
• Fixed AMD64 applications showing in the App Market on Arm64 architecture.
• Fixed the HTTP certificate matching rule #2559 @hanxinhisen

Optimizations

• Adjusted default PVC sizes for system components.
• Optimized prompts when adding component configuration files.
• Supported modifying storage quotas for component storage.

Platform Upgrade

• Online Environment: Go to Platform Management -> Enterprise Settings -> Upgrade and execute one-click upgrade.
• Offline Environment: Please read the Offline Upgrade Documentation.

v6.7.1-release

What's Changed

Bugs fix

• Fix compatibility issues with Java Slug build mode in the new version #2547
• Fix the issue where Python CNB build parameters do not take effect

Platform Upgrade

• Online Environment: Go to Platform Management -> Enterprise Settings -> Upgrade and execute one-click upgrade.
• Offline Environment: Please read the Offline Upgrade Documentation.

Full Changelog: v6.7.0-release...v6.7.1-release

v6.7.0-release

Rainbond v6.7.0 Release | Native K8s Resource Management with YAML and Helm Workflows

If previous versions of Rainbond were stronger on application-centric delivery, helping teams build, ship, and operate cloud-native applications efficiently, then v6.7.0 takes another major step toward Kubernetes-native workflows.

The biggest update in this release is the official introduction of native K8s resource management. Rainbond no longer serves only its internal application model. It can now more fully accommodate Kubernetes native objects, raw YAML, Helm releases, and existing namespaces. For teams already working deeply with Kubernetes, this is a very meaningful capability upgrade.

At the same time, v6.7.0 also continues to strengthen Rainbond across both delivery and operations:

• On the build side, source-code builds now fully support CNB (Cloud Native Buildpacks)
• On the application operations side, application snapshots are now available, completing the workflow for version archiving, export, publishing, and rollback

Native K8s Resource Management: Bringing Native Workflows into Rainbond Naturally

The most important update in v6.7.0 is the official support for native K8s resource management. With this capability set, Rainbond now provides a more complete path for managing Kubernetes-native resources. Users can now:

• Connect existing namespaces and continue managing resources in a native way
• Create and maintain Kubernetes objects directly from raw YAML
• Install, upgrade, and manage applications as Helm releases
• View workloads, pods, networking, configuration, and storage resources from a unified team-level view
• Manage platform-level resources such as StorageClass, PV, and PVC from the platform administration side

This means that whether you are taking over existing cluster resources or handling ongoing Kubernetes-native operations and troubleshooting, Rainbond can now provide a more unified entry point and management view.

Compared with previous versions, the biggest difference is that Rainbond is no longer limited to platform-specific application models when handling delivery workflows. In the past, if a team wanted to bring existing YAML, Helm charts, or namespaces under Rainbond management, they often had to adapt them into the platform model first. In v6.7.0, users can keep native Kubernetes semantics and continue using familiar YAML and Helm workflows directly.

In other words, from this version onward, Rainbond supports two parallel paths: teams can continue using the application model for standardized delivery, or preserve native Kubernetes object structures and manage them in a Kubernetes-native way.

Source-Code Builds Now Fully Support CNB: Faster, Smaller, and More Standardized

On the delivery side, v6.7.0 also introduces an important upgrade: source-code builds now fully support CNB (Cloud Native Buildpacks), with Paketo Buildpacks as the core implementation.

One important note: starting from v6.7.0, new source-based components use the new CNB + Paketo Buildpacks pipeline by default. Existing components upgraded from older versions will keep their previous build mode and can continue running as-is. If there are no compatibility constraints, the new CNB path is recommended going forward.

Compared with the traditional slug-based build approach, the benefits of this upgrade are clear:

• Faster builds: in common source-code build scenarios, the time from code to image can be significantly reduced
• Smaller final images: build outputs are more compact, reducing unnecessary runtime overhead and improving image distribution and deployment efficiency
• More standardized artifacts: images generated through Cloud Native Buildpacks align more closely with cloud-native best practices, making later operations, migration, and ecosystem integration smoother

As one of the more mature Buildpacks implementations in the ecosystem, Paketo helps Rainbond move its source-code build pipeline toward a more standardized model. This is not just a replacement of underlying build technology. It marks a shift from simply "being able to build" toward a build system that is more modern, more standardized, and more cloud-native.

At present, this new build pipeline already covers common language stacks including Java, Python, PHP, and .NET. For developers, the most direct gains are higher build efficiency and lighter images. For the platform itself, it also creates a more stable foundation for future build capability expansion and governance.

Application Snapshots: Clearer Version Archiving, Distribution, and Rollback

In addition to native K8s resource management and source-code build upgrades, v6.7.0 also introduces application snapshots.

Application snapshots preserve the version state of an application at a specific point in time, recording component orchestration, configuration, dependencies, and version metadata. The core problem this solves is straightforward: when an application keeps changing, how do you keep a traceable, comparable, and rollback-ready baseline?

With application snapshots, users can:

• Save the current application state and build a version timeline
• Compare the current state with historical versions
• Export an application directly from a snapshot
• Publish a snapshot to the internal component library
• Roll back to a historical snapshot when problems occur

This capability is especially useful in scenarios such as:

• Preserving a milestone version after a round of feature or configuration changes
• Keeping a stable baseline before upgrades, migration, or refactoring
• Exporting a version for delivery or publishing it to an internal component library for reuse
• Quickly restoring a verified stable version after an unexpected change

It is worth noting that application snapshots store application-level metadata and orchestration state. They are not the same as VM snapshots, disk snapshots, or database backups. They are designed for application version management, not as a replacement for business data backup or disaster recovery.

With application snapshots, Rainbond further completes the application operations workflow, covering version archiving, version flow, and version rollback in a much clearer way.

Final Thoughts

Rainbond v6.7.0 is a highly focused release. Its most important change is the official support for native K8s resource management, allowing Rainbond to more naturally accommodate YAML, Helm, namespaces, and Kubernetes-native resource management scenarios. At the same time, source-code builds now embrace CNB + Paketo Buildpacks, making builds faster, images smaller, and delivery more standardized. With application snapshots added as well, the application version management workflow is now much more complete.

If previous versions of Rainbond were mainly about helping teams "get applications running," then starting with v6.7.0, Rainbond is going a step further by helping teams manage native resources, source-code builds, and application versions together.

Other Changes

• Helm Chart now supports OCI #2495
• Fixed a failure when creating applications with Helm #2514
• Fixed automatic certificate issuance failures
• Fixed the issue where re-uploading a package with the same name could not be extracted on the second build

Platform Upgrade

• Online environments: go to Platform Management -> Enterprise Settings -> Upgrade and perform the one-click upgrade.
• Offline environments: please refer to the offline upgrade documentation.

Full Changelog: v6.6.2-release...v6.7.0-release

v6.6.2-release

What's Changed

Bugs fix

• Fixed an issue where certain pages failed to reload during switching in offline environments.
• Fixed the incorrect error message displayed when adding TCP ports.
• Fixed a timing/sequencing issue with the creation of the rbd-api secret during installation.
• Fixed a syntax error in the standalone startup script.

Platform Upgrade

• Online Environment: Go to Platform Management -> Enterprise Settings -> Upgrade and execute one-click upgrade.
• Offline Environment: Please read the Offline Upgrade Documentation.

Full Changelog: v6.6.1-release...v6.6.2-release

---

Chinese

What's Changed

Bug 修复

• 修复在离线环境下个别页面切换无法重载
• 修复 TCP 端口添加错误提示语
• 修复安装时 rbd-api secret 创建的时序问题
• 修复 standalone 启动脚本语法问题

平台升级

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

v6.6.1-release

What's Changed

Bugs fix

• Fixed build failures when source code contains both a Dockerfile and Java Maven multi-modules (#2518).
• Fixed incorrect UI display of Java source build parameters.
• Fixed an issue where the cluster could not be re-entered after an initialization failure.
• Fixed issues with real-time streaming of build logs.
• Fixed the failure to automatically create private registry keys for new teams.

Platform Upgrade

• Online Environment: Go to Platform Management -> Enterprise Settings -> Upgrade and execute one-click upgrade.
• Offline Environment: Please read the Offline Upgrade Documentation.

Full Changelog: v6.6.0-release...v6.6.1-release

---

Chinese

What's Changed

Bug 修复

• 修复当源码同时存在 Dockerfile 和 Java Maven 多模块时无法构建 #2518
• 修复Java 源码构建参数 UI 展示不正确
• 修复集群初始化失败后无法再次进入
• 修复构建日志实时推送问题
• 修复新建团队没有自动创建私有仓库密钥

平台升级

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