这个版本主要修改了一些bug

详细变更点：​

BUG修复​

• 添加新节点不生效。
• HELM 创建组件部分中的 k8s 资源创建失败。 #1958
• 多架构集群导出helm图表包失败。 #1955
• 修复团队列表视图显示不正确的问题
• 从团队列表视图中删除多余的显示
• 为部分表添加索引，优化查询速度

感谢

感谢用户 MISAKIGA、jeanphorn 等用户在社区中的参与与反馈，才能使产品变得更好，我们欢迎大家任何形式的参与和贡献。

这个版本主要修改了一些bug

详细变更点：​

功能优化​

• 每次部署或者升级已发布的应用程序时，共享存储就会消失 #1724
• 组件构建Openapi接口，调用异常 #1874
• 当一个团队绑定多个集群时，会显示多个团队。#1827
• nginx ssl_ciphers 漏洞
• helm 应用程序安装失败 #1777
• 修改插件配置组报错 #1934
• 港口仓库 webhook 错误
• 默认网关显示页面修改
• 支持全局私有镜像仓库配置

这个版本主要优化构建和用户安装体验。

详细变更点：​

功能优化​

• 基于主机安装支持通过表单自定义 Rainbond 集群安装参数
• 优化 Helm 安装，支持通过表单自定义 Helm 安装参数
• 优化 NodeJS 前端项目构建缓存策略，加快构建速度

为了更好地应对离线场景，提升私有仓库镜像部署体验。Rainbond v5.17 版本支持上传镜像包和使用本地镜像创建组件。同时对于私有镜像的部署也进行了优化，通过统一配置私有镜像仓库。用户无需重复输入账号密码，即可快速部署私有镜像。

主要功能

1. 离线场景支持多种部署方式​

Rainbond 之前版本中对于离线场景下的应用模版交付体验较好。但是对于离线环境的开发、部署上还有所欠缺。离线环境下会遇到没有Git仓库、没有私有镜像仓库等问题。在之前的版本中，需要单独在内网环境中部署私有镜像仓库，再将光盘中的镜像导入该仓库，才可以继续镜像部署。

在 v5.17 版本中，我们统一做了梳理：

• 镜像部署：Rainbond支持直接上传镜像压缩包进行部署，平台会自动解析压缩包中的镜像，用户可以选择压缩包中的镜像进行部署。此外，上传一次后，镜像会根据团队存储在平台上。在后续的创建过程中，用户可以轻松地从本地镜像库中选择之前上传的 tar 包，以便快速创建组件。

• 源码部署：Rainbond支持离线上传源码压缩包、Jar、War包，这意味着你可以将源码打成压缩包，在离线环境中直接上传进行构建。支持的语言和通过Git仓库构建一致，如Java、Go、Python、NodeJS、Php、.NetCore 等

• Helm部署：在之前的版本中，需要先对接外部的 Helm Chart 仓库，选择应用进行部署，现在支持直接上传 Helm Chart 包进行部署。平台会识别出 Helm Chart 包中的所有镜像，你可以选择已经上传到平台上的镜像进行替换。

通过以上几点优化，用户可以在离线环境中按需构建和测试。不必担心外部构建工具或依赖库的问题。

2. 统一管理私有镜像仓库​

在源码构建中，用户可以通过对接 Github、Gitlab、Gitee 等代码仓库，实现通过代码仓库一键构建运行的效果。但是对于私有镜像构建，却面临着每次构建都需要输入私有仓库的账号密码的问题。尤其是对于公有云镜像仓库或自建的镜像仓库来说。不仅需要记住镜像名，每次部署都需要输入镜像仓库的域名。

因此为了提升用户镜像部署的体验，现在平台可以统一设置私有镜像仓库的授权信息。在镜像部署时，只需要选择需要使用到的私有镜像仓库，输入镜像名称即可。账号密码以及镜像仓库域名不需要再次输入。后续 Rainbond 还将支持镜像仓库的列表或 tag 查询，实现更好的部署体验。

3. 提升平台稳定性​

在之前的版本中，用户经常会遇到集群通信异常问题，遇到问题时控制台将无法访问，虽然不影响用户实际运行的业务。但是也不便于管理和排查。这主要是底层组件依赖较多导致的。

在 v5.17 版本中，优化了平台的 API 服务，当底层资源故障时，仍然可以提供有限服务，即使底层依赖组件存在问题，API 也可以提供有限的服务，便于用户查看底层组件问题。在底层依赖组件正常后，API 服务也会自动重连。

详细变更点：

新增功能​

• 离线场景支持多种部署方式
• 支持统一管理私有镜像仓库账户密码。 #1821
• 组件支持 hostAliases #1812
• 支持分应用，分组件，按配置文件名称 ，过滤配置文件 #1838
• 支持自动构建时无需设置触发关键词，通过提交直接触发构建 #1770

功能优化​

• 提升稳定性，优化API服务依赖项，确保在依赖组件异常的情况下也可以提供有限服务 #1820
• 发布应用模版支持搜索 #1843
• 团队向导页从新建增加入口 #1850
• 支持删除共享配置文件时检查是否被其他组件依赖，支持挂载配置文件强制删除 #1837
• 优化网关参数校验规则，避免配置错误导致网关异常 #1840

Bug 修复​

• 修复构建任务未调度到构建节点的问题 #1842
• 修复批量选择组件时，组件运行状态变化导致选择的组件变为其他组件的问题 #1844
• 修复 Oauth 关闭后，仍可进行第三方登录的问题 #1841
• 修复组件 K8s 属性中，健康检测无法生效的问题 #1809
• 修复 Dockerfile 构建时，arg 参数不生效的问题 #1685
• 修复 Golang 构建时，GOPRIVATE 变量不生效的问题 #1794

感谢

感谢用户 sundaqiang、shun634501730、Juke-github、mx2913、1024find、2997215859、xggz、lian-yang 等用户在社区中的参与与反馈，才能使产品变得更好，我们欢迎大家任何形式的参与和贡献。

随着云原生技术的迅速发展，容器化已经成为现代应用部署和管理的主流方式。然而，在现实业务场景中，依然存在着大量传统的虚拟机应用，这些应用因其自身特性或遗留系统的需要，难以直接迁移到容器环境。Rainbond v5.16版本的发布支持了虚拟机组件部署，以容器方式运行虚拟机，旨在为用户提供更灵活、更开放的部署选择，提供一个整合、统一的的云原生应用管理解决方案。

主要功能点：​

支持虚拟机​

虚拟机创建​

应用安装引导视图新增虚拟机类型组件部署引导，同时支持了四种部署虚拟机组件方式，以下是针对每种部署方式的介绍：

• 公共：提供了四组常用的公共虚拟机镜像地址（CentOS 7.9、Anolis OS 7.9、Deepin 20.9、Ubuntu 23.10），以方便用户快速获取、部署和运行虚拟机。
• 链接：当公共镜像无法满足需求时，可通过下载镜像并按照镜像名称及下载地址配置，创建所需的虚拟机组件。
• 上传：若存在已打包的私有虚拟机镜像，可通过上传镜像的方式创建虚拟机组件。只需按步骤上传镜像，并配置相应的镜像名称即可创建虚拟机。
• 本地：在上述三种方式部署完成后，虚拟机镜像信息将在平台内保留。对于再次部署，可选择使用本地镜像，避免重复上传或下载的流程。

虚拟机管理​

与传统的云原生组件相比，虚拟机类型的组件在支持的操作上有所不同，删除了构建更新等按钮，保留了启动、关闭按钮，增加了增加了挂起和恢复操作。

虚拟机web终端​

通过点击 WEB 终端按钮，可以快捷跳转到虚拟机的操作管理界面。

虚拟机组件和容器组件编排​

虚拟机组件支持和平台容器组件进行编排，但是仅支持容器组件依赖虚拟机组件，通过依赖绑定虚拟机端口，从而达到快捷访问的效果。

功能优化​

• 支持虚拟机类型组件部署
• 支持JDK17
• Rainbond 报警支持开关设置
• 在创建团队、应用、组件过程中，自动为团队、应用、组件生成英文名。
• Golang 构建支持 GOPRIVATE、GOPROXY #1769
• 允许两种健康检测方式同时存在 #1548
• 配置ssl证书时校验证书和域名一致性为可选

BUG 修复​

• Rainbond buildkit 构建不成功尝试次数过少的问题
• nodejs 识别后没有默认构建命令
• 多个组件源码构建时会构建失败 #1775
• OAuth 配置在搭建的Gitlab 16.5版本中不能用 #1774
• 集群管理中磁盘数据错误
• 新增网关无法开启对外访问

修复多源码组件同时构建失败的问题​

详细变更点​

BUG 修复​

• 修复多源码组件同时构建失败的问题 #1775

1. 支持上传源码包构建组件​

在一些离线场景下，无法从代码仓库拉取代码。在 5.15.2 版本中，Rainbond 支持了直接上传源码压缩包进行构建。同时，对于前端项目，你也可以在本地打出 dist 包后，直接在平台上构建运行。

2. 优化前端项目 nodeJS 构建，支持默认构建和 Docker 构建两种模式​

在之前的版本中，前端项目 nodeJS 构建往往会遇到各种问题不易排查，因此 Rainbond 新增了 Docker 构建模式，在该构建模式下，将会根据你的前端代码自动生成 Dockerfile ，并利用 Dockerfile 帮你完成构建，提升构建成功率。

3. 优化镜像占用空间，默认保留组件最近5个构建版本的镜像​

由于 Rainbond 内置了一个镜像仓库，因此在一些业务构建过多时，存储在该镜像仓库的镜像无法及时清理，导致占用空间过多，造成集群不稳定。现在平台默认保留组件最近 5 个构建版本的镜像。对于其他版本会自动清理。

详细变更点​

新增功能​

• 支持上传源码包构建组件 #1287

功能优化​

• 优化前端项目 nodeJS 构建，支持默认构建和 Docker 构建两种模式 #1747
• 优化镜像占用空间，默认保留组件最近5个构建版本的镜像 #1739

BUG 修复​

• 修复快速复制时服务端异常的问题 #1391
• 修复 rbd-monitor 挂掉后，团队视图无法进入的问题 #1752
• 修复基于主机安装时无法设置节点角色的问题 #1749

概述​

这个版本主要修复Bug和优化用户体验，如果没有遇到下列bug可暂时不升级。

1. 通过主机安装-预检查节点连接情况​

用户通过主机安装的时候，可能免密登陆没有配置好或者免密登陆出现问题，导致k8s集群装不起来，苦苦寻找问题并没有找到解决方案，最后定位在无法免密登陆，实属浪费时间！

该版本通过主机安装的时候，如果所有节点公网ip检测全部通过，则会直接去安装k8s集群，如果有节点连接失败，可以再去失败的节点配置免密登陆。或者移除连接失败的节点。

2. helm命令一键安装​

在 5.15 版本中，Rainbond 新支持了从应用市场复制命令行进行安装。现在你可以在应用市场中随意浏览，找到自己想要安装的应用后通过复制命令到 Rainbond 平台，便可一键安装应用市场的应用到你的集群。

但是，可能需要您先添加仓库，否则无法安装，该版本支持预先检查本地是否有helm仓库，如果有仓库我们会直接执行install命令，如果没有则会弹出页面提示您添加仓库。

3. 构建缓存支持全局共享​

大大减小缓存占用的储存空间。分不同的语言共用缓存目录。

详细变更点​

新增功能​

• 通过主机安装节点链接失败提示#72
• helm 一键安装不需要每次添加仓库

功能优化​

• 优化集群通信异常和组件端口列表页的提示信息 #1276
• 构建缓存支持全局共享

BUG 修复​

• 修复在 arm 环境下，helm应用部署失败的问题 #1388
• 修复应用升级后，再回滚，配置文件内容丢失的问题 #1371
• 修复在 arm 环境下，添加组件监控图表服务端异常的问题 #1372
• 修复企业下错误的角色信息 #1374
• 修复 openapi 多次创建应用失败的问题 #1376
• 修复低版本平台导出的应用模版在新版本无法导入的问题 #1377
• 修复在 arm 环境下，上传 jar 包构建，组件架构错误的问题 #1367
• 修复在 arm 环境下，Docker Compose 构建架构错误的问题 #1369
• 修复删除构建版本，事件信息中没有记录操作人的问题 #1642
• 修复有状态组件使用外部storageClass，存储类型错误的问题 #1737

概述​

最近有太多同学对 Rainbond 的构建速度提出了疑惑，构建速度太慢了，而且还存在使用过多内存的问题，这也是导致低配置环境构建失败的原因，所以我们对构建这一部分进行了调整优化。同时，我们还将平台所支持的 k8s 版本从 1.25 升级到1.27，以便让更多的用户也能够享受平台带来的便利和优势。

1. 开源应用商店的应用支持命令行安装​

该版本还优化了用户从应用市场安装应用的体验，在之前，想要安装应用市场中的应用时，需要在 Rainbond 平台中对接应用市场后才可安装，对接完成后，如果想要查看应用的详细介绍，还需要跳转到应用市场页面才能浏览。 而在 5.15 版本中，Rainbond 新支持了从应用市场复制命令行进行安装。现在你可以在应用市场中随意浏览，找到自己想要安装的应用后通过复制命令到 Rainbond 平台，便可一键安装应用市场的应用到你的集群。

2. 支持 Kubernetes 版本 1.26、1.27​

Kubernetes 即将发布 1.28 版本，作为一个云原生应用管理平台，为了让更多的用户在不同场景能体验到 Rainbond 管理应用的便捷性和交付的易用性。本次版本新支持了 1.26-1.27 的 Kubernetes 集群对接和使用。现在可以使用 Helm Chart 在 1.19-1.27 的集群上快速部署 Rainbond。

3. 优化构建速度​

下面是在4核16G的环境中对常用的几种构建方式进行的测试对比数据。

Dockerfile （首次构建时间缩减60%）

Java Maven（首次构建时间缩减30%）

Node.js（首次构建时间缩减50%）

详细变更点​

新增功能​

• 平台支持的 k8s 最高版本由1.25升级到1.27
• 开源应用商店的应用支持命令行安装

功能优化​

• 支持自定义共享存储实现 #1705
• 优化 Rainbond node 组件日志产生太多问题 #1675
• 组件Kubernetes属性支持配置 securitycontext #1636
• 优化 Helm 命令的体验
• 优化构建体验

BUG 修复​

• 修复组件容器中中文编码乱码的问题 #1701
• 修复创建组件时修改端口别名不生效的问题
• 修复containerd日志乱序问题
• 修复arm 架构下多模块构建架构识别为 amd 问题 #1683
• 修复修复多个组件实例时滚动更新失败的问题 #1643
• 修复上传yaml文件时创建重复资源名称的问题
• 修复存储表类型字段过短的问题 #1545
• 修复安装helm应用失败的问题 #1714

概述​

信创产业即信息技术应用创新产业，是我国数字化转型的重要组成部分，也是关键基础设施的重要支撑。而 Rainbond 长期深耕国产化 IT 生态，已经与多家国产 CPU 架构完成兼容性认证，能够在不同的架构下快速部署运行。现在为了全面降低应用系统向信创环境中迁移的技术成本，助力信创应用零成本迁移上云。Rainbond 专门针对国产化信创场景推出了 Rainbond “信创”版本。信创应用可以被轻松地发布成为适用于不同架构的应用模板，在国产化信创环境中一键安装。

1. “一云多芯”，统一管理异构集群​

顾名思义，“一云多芯”的异构集群，指的是在同一个集群中的计算节点中，其 CPU 芯片架构不唯一。在之前的版本中，大家使用 Rainbond 主要管理的都是 X86_64 的集群，这种单架构的集群在部署和使用时相对简单。但在信创环境下，就会面临如下问题：

• 信创场景下，如何快速部署一套基于 arm64 的集群？
• 传统 X86 应用如果未改造完成时，如何在信创场景下使用？ 在面对这类问题时，Rainbond 的解决思路如下：

首先，Rainbond 支持部署和管理多个单架构集群。你可以通过填写机器的 IP 地址，快速部署出一套 arm64 信创集群，你可以通过 Rainbond 单独部署 amd64普通集群和 arm64 信创集群。并统一纳管，此时你可以用同一套源码，在两个集群中分别部署业务，用于验证业务在两种架构下的可用性。 其次，传统 X86 架构下开发的应用都需要很长时间的调整甚至重构才能完全在国产化芯片上运行，可能一套业务系统会同时存在已改造的模块和未改造的模块。如果使用多个单架构集群管理的方式，那么对于整套业务系统的管理和通信也会存在一定的问题。

在这种情况下，“一云多芯” 就非常重要，业务已改造的模块和未改造的模块同时运行在多架构混合集群上，可以实现整套业务系统的统一管理和集群内通信，可以通过逐步改造，将业务完整迁移到 arm64 架构下。

目前 Rainbond 也支持了 amd64集群、arm64 集群、amd64 & arm64混合架构集群的一键部署和管理。

2. 国产化操作系统和芯片适配​

Rainbond 还是一个符合信创要求的一体化应用管理平台，兼容主流国产化 CPU，获得了国内各大 CPU 厂商的认证。同时与多个国产化操作系统进行了适配。目前 Rainbond 已适配的国产化 CPU 主要包含鲲鹏、龙芯、飞腾等；已适配过的国产化操作系统主要有超聚变、中科方德、统信软件、龙蜥操作系统、麒麟软件等。

3. 传统应用快速迁移到信创环境​

在传统应用迁移到信创环境的过程中，往往可以提供的介质有源代码、镜像、Jar、War包这几类，而对于这几类业务系统的迁移和部署，Rainbond 提供了以下解决方式：

• 源代码：对于提供了源代码的应用系统，只需要提供代码托管地址，选择 arm64 架构，Rainbond 将自动配置合适的构建环境、运行环境，将其运行到对应的计算节点中去，基本可以实现不改业务代码，构建出对应架构的镜像。
• Jar、War包：对于 Java 类型的业务而言，其 Jar/War 包本身与 CPU 架构无关，只要提供合适的运行环境即可。因此，只需要选择部署架构，Rainbond 将会自动将其打包成对应架构的镜像并运行到指定的计算节点中去。
• 镜像：对于提供了 arm64 架构的容器镜像，通过指定 arm64 架构，就可以拉取对应版本的镜像并将其部署到对应的计算节点中去。

4. 应用市场机制全面支持 arm64 架构​

为了更好的助力信创应用、遗留业务系统零成本完成向国产化信创环境迁移，我们进一步拓展了云原生应用商店的功能，使其支持发布和安装 arm64 架构的应用。现在开源应用商店中已上架了 Mysql、Redis、Nacos 等可以在 arm64 架构下可以运行的信创应用。可以在arm64 架构下一键部署和运行。

未来我们还将会逐渐把一些常用的中间件应用上架到开源应用商店，并在开源应用商店设立信创专区。同时也欢迎大家通过 Rainbond 的发布功能，一键制作出适合在arm64 架构下安装的应用模板，并将其发布到开源应用商店，助力国产化信创迁移改造。

如何安装？​

信创版本的安装和普通安装方式一致，如果你想在arm64 架构下快速安装体验，你可以通过执行以下脚本一键部署和使用。

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

如果需要搭建多架构混合集群，可以参考基于主机安装，主要流程如下：

1. 首先运行起来 Rainbond 控制台容器，并注册登录
2. 登录后，进入 平台管理 > 集群 -> 添加集群 -> 从主机开始安装 进入图形化安装页面
3. 填写节点信息，此处不需要关注各个节点的 CPU 架构信息，只需要填写各节点 IP 即可
4. 节点信息填写完毕后，根据页面提示复制节点初始化命令在集群内所有节点上执行
5. 初始化完成后，点击 下一步，等待 Kubernetes 集群安装成功即可，待状态为 运行中 状态时进行下一步操作
6. 勾选 我已阅读并已清楚认识上述注意事项 后，点击 开始初始化 ，等待安装完成即可。

如何使用？​

平台整体使用流程与体验和之前保持一致，对于信创方面的能力，可以参考官方文档的使用指南，它将详细指引你如何通过 Rainbond 轻松部署异构集群，并实现业务的快速迁移和高效管理。

概述​

在之前的版本中，由于快速安装的镜像过大以及启动速度慢给用户快速上手体验带来了一定的门槛。因此，为了降低使用门槛。同时提升用户构建和排错的体验。我们缩减了控制台的镜像大小，优化了组件创建的引导流程，将异常信息直接展示在组件事件列表。

优化快速安装体验​

该版本在之前快速安装版本的基础镜像之上，删除了一些不需要的依赖包，对平台集群端的各个组件进行了缩减。整体镜像大小锐减 60%，启动速度提升 60%。目前可以做到两分钟启动，半小时内快速上手。以下是新旧版本安装的数据对比。

新增团队视图组件部署引导页​

在团队中没有应用时，默认跳转到组件部署引导页，该引导页中提供了多种在 Rainbond 中部署业务的方式。你可以根据实际需求从外部应用市场快速安装应用体验，或使用 Docker 镜像、源代码、Yaml 文件等方式将你的业务快速部署起来。 同时，平台新增了镜像部署的示例，以及优化了示例代码的部署流程。在团队下有应用时，你也可以点击左侧的新建跳转至该引导页。

优化源码构建流程，支持多步配置​

在之前版本的代码构建流程中，检测通过后即可直接创建组件。看起来相对简单，但实际却会遇到各种各样的问题，例如：未设置资源，由于资源不够导致业务无法启动；不知道在哪里配置访问入口，业务如何访问；启动命令或配置文件在哪里设置等。 因此该版本优化了源码创建流程，让源码创建的流程更清晰直观。你可以在创建时根据指引调整相关参数，提升构建和运行的成功率。如不需要调整，也可使用默认参数构建和运行。

目前引导流程主要分为两部分，基础配置和高级设置。基础配置中你可以设置业务的资源，以及构建参数和启动命令。高级设置中则可以配置业务的访问端口、配置文件、环境变量和存储。

详细变更点​

功能优化​

• 优化控制台镜像大小和启动速度
• 支持快速安装的单机版本升级
• 新增团队视图组件部署引导页
• 优化源码构建流程，支持多步配置
• 组件构建和运行提示优化，异常信息直接展示在组件事件列表 #1648
• 默认团队使用的命名空间更换为 default #1649
• NodeJS 前端代码构建时支持设置默认打包目录 #1665
• 优化平台源码示例构建流程，新增镜像示例
• 更换前端项目构建时默认加速源地址

BUG 修复​

• 修复部分组件创建后数据中心异常问题 #1655
• 修复单机版使用 sqlite 遇到的锁库问题 #1312
• 修复 OpenAPI 添加/更新证书失败的问题 #1663
• 修复 Rainbond 文件上传格式未严格限制的问题
• 修复 Rainbond 权限控制问题
• 修复单机版创建 LoadBalance 类型的 Service 导致的平台网关不可用的问题 goodrain/rainbond-console@ ed755d5

概述​

在这个版本中，我们升级并调整了多种语言类型的构建包版本, 支持直接删除应用以及应用下的所有资源，

各语言构建包版本调整：​

这个版本对服务组件构建的基础镜像进行了升级，从 ubuntu1404 升级到 ubuntu2204, 新的镜像会包含最新的安全补丁和更新，可以提供更高的安全性，也支持最新的软件库、框架和标准，可以提供更好的兼容性。

不同语言的发行版本不断升级，而平台之前的版本中各个语言的构建包版本相对较低，可能会对组件构建造成一些影响，因此在这个版本中我们对各个语言的构建包进行了调整升级，以此来兼容更高版本的语言。具体调整如下:

注意事项​

平台从旧版本升级到新版本，例如从 v5.13.0 升级到 v5.14.0，之前服务组件的构建包版本如果在平台升级后被删除，那么对服务不会造成影响，不过想要重新构建组件的话则只能选择已有版本。

删除应用：​

在之前的版本中执行删除应用之前需要关闭并且删除所有组件，流程比较繁琐；在删除应用后，应用下对应的一些资源则没有处理，如 k8s 资源等，这样会导致资源占用浪费。 所以这这次版本中对删除应用做了优化，在应用视图中通过删除按钮可以直接删除应用以及应用下的所有资源，包括应用的所有组件、应用模版发布记录、网关、K8s 资源以及应用配置组。 在执行删除操作之前，我们罗列了这些资源的相关内容，方便用户了解应用中已存在的资源。

注意事项​

在执行确认删除操作时，务必确认应用下每一种资源，看是否还有存在的意义和作用，以免误删对业务造成影响。

详细变更点​

新增功能​

• 支持 直接删除应用及应用下所有资源
• 升级多种语言的构建包版本

功能优化​

• 使用集群命令行，创建的pod有合理的回收机制 #1599
• 域名配置https证书时，增加搜索功能或优先匹配与域名相同的证书 #1606
• 应用端口页面，添加证书成功后没有任何提示 #1605
• 支持配置日志存储路径

BUG 修复​

• 应用下k8s资源service资源安装失败 #1629
• 无法创建第三方组件api注册 #1622
• 使用ceph存储导致monitor统计Disk出错 #1621
• yaml文件上传中没有数据 #1616
• 安装平台时，不创建无用的pvc #1614
• 创建组件在高级设置页面，点击确认后数据中心异常 #1569
• 通过仓库构建dockerfile项目时，推送镜像失败 #1603
• gateway 配置文件生成错误，导致gateway起不来 #1604
• 已有的k8s项目导入 rainbond 导入失败 #1521
• 无法删除异常组件 #1539
• 选择代码语言后，如果进入高级设置，代码语言的选择没保存 #I6Z2AP

感谢​

感谢用户 hanxinhisen、lihao6666、hbinr、xggz、loyabe、青青子衿 等用户在社区中的参与与反馈，才能使产品变得更好，我们欢迎大家任何形式的参与和贡献。

在这个版本中，我们支持了k8s Gateway API来扩展网关能力，优化了 Operator 组件使用体验

概述​

Gateway API：​

Gateway API 是 Kubernetes 1.19 版本中引入的一种新的网关类型资源，可以将其看作为 Ingress API 的更高级，其目标是建立一套表现力强、易扩展、面向角色的服务网络模型。相较于原有的 Ingress API ，Gateway API 具有更灵活、规范、可扩展等特性, 解决了 Ingress API 不规范、移植性差等问题。 在之前的版本，平台仅提供了一种网关创建方式，该创建方式是由 Ingress API 以及 Rainbond 的 rbd-gateway 组件所实现；为了解耦用户业务与平台关系，平台支持了 k8s Gateway API ，将其作为平台的扩展网关能力进行使用，默认情况扩展网关不会展示，只有安装 k8s Gateway API 及其下游实现后才会展示。平台在应用商店中上架了 k8s Gateway API 基础组成的插件应用以及由 envoy 提供的下游实现插件应用，通过部署插件应用，可快速使用 k8s Gateway API 扩展网关能力。

Operator：​

Operator 是一种自定义 Kubernetes API 的扩展，他通过监控一组声明的自定义 CRD 资源来管理应用，大大简化 Kubernetes 集群中复杂应用程序的管理和运维。 平台提供了 Helm、Yaml 等多种方式对 Operator 类型组件进行部署，在旧版本中 Operator 所管理的资源并非平台所创建所以无法在平台中得到展示，因此平台在该版本优化了 Operator 的使用体验，将 Operator 所管理的 Workload 类型资源在应用视图以浅灰绿色组件的形式进行展示，并且会将 Service 类型的资源通过第三方组件的方式暴露出来供用户访问。

详细变更点​

新增功能​

• 支持 k8s Gateway API
• 优化 Operator 组件使用体验

功能优化​

• 支持 k8s 资源批量删除

BUG 修复​

• 组件基于 dockerfile 构建时，从私有仓库中拉取镜像失败 #1594
• rbd-monitor 申请1G存储满了后出错 #1525
• 命令行工具 pod 启动失败 #1595
• 通过git仓库创建组件可以设置英文名称 #1194
• 集群节点列表获取不到角色标签报错 #1282

在这个版本中，我们主要支持了平台级的插件和能力扩展。希望能通过外部插件扩展平台能力，实现微内核的效果；同时以后将会继续精简安装，能让用户按需扩展平台功能。在 Kubernetes 兼容性这方面，我们也通过平台级的能力将对应资源暴露出来，交给用户处理。

概述​

在之前的版本中，用户一开始会依赖于平台的功能简化管理，但到了高级使用场景，就有可能遇到平台当前已有的功能无法满足用户需求，此时给用户扩展平台能力的机制就非常重要。如果为了扩展平台功能，升级整个底层平台，将会面临复杂性和稳定性的挑战。 同时由于 Rainbond 主要在应用这一层进行抽象，所以对于 Kubernetes 中集群所提供的一些能力，并不能全部在平台上进行展示，如 StorageClass、GatewayAPI 等能力也无法在平台上直接进行管理。为了给用户提供更高级的功能，在之前的版本中，我们在 Kubernetes 生态的兼容性上做了许多工作，如应用级别的 K8s 资源创建、组件级的 K8s 属性配置等。 而在 5.12 版本以后，我们将通过 Rainbond 的插件体系扩展平台的功能。在这里有以下两个概念，平台级的插件和能力。

插件：​

插件在 Rainbond 中其实对应的是应用市场中的应用，但是该应用包含插件的元数据定义（通过 CRD 资源定义），这样当用户安装该插件时，可以在平台管理-扩展-插件中获取到该插件的信息，并可以快速跳转到该应用进行管理。这样可以利用已有的应用商店体系，实现平台插件体系的分发和管理。 通常来说，一个插件包含以下内容：

1. 一个能正常运行的应用：这个应用是插件的完整实现，即使单独部署也可以正常进行工作。
2. 插件的描述文件（CRD）：这个文件主要定义了插件的基本信息、如名称、描述、版本、作者等。
3. 能力的描述文件（CRD）：这个文件主要定义了该插件可以提供哪些能力，在这个 K8s 集群中所有该能力的实现都会被展示出来。如 ServiceMesh 类型的插件提供了应用治理的能力，那么在安装这类插件时，将会列出其能够提供的能力资源。 这样安装插件后，我们就可以一目了然的知道当前 k8s 集群提供的能力，比如支持应用治理的各类 ServiceMesh 框架、不同的 GatewayAPI 实现，不同的存储能力等等。

能力：​

能力扩展主要是将 Kubernetes 底层所提供的一些能力展示给用户。通过 CRD 资源定义，将 Kubernetes 集群中一些资源同步到平台内，可以快速预览和编辑这些资源。如定义集群中的 storageClass 作为存储能力的展现，那么就可以在这里预览到所有的 storageClass 资源并进行操作。 而插件中则可以包含能力这种资源的定义，这样在安装插件时，即可同时暴露出该插件可提供的能力，由用户处理。如下图所示：

为什么使用插件​

对于用户而言，安装插件与安装应用的体验完全一致。那为什么还要使用插件呢？主要可以从以下几点来看：

1. 插件可以实现全局的管理，对于企业管理员而言，更关注于平台提供了哪些能力，这些都可以一目了然。而仅仅使用应用时，管理员无法对这些提供能力的应用做统一管理。
2. 插件可以按需安装，与平台解耦，不会与平台一起安装，这样不需要该插件时则不会占用资源。
3. 利用应用商店的分发体系，可以单独升级插件，Bug 修复也会更及时。
4. 不同的插件都可以为平台的用户提供不同的能力，如 GatewayAPI 插件，可以为平台提供额外网关的能力；各类 ServiceMesh 插件，可以为平台提供应用治理模式注入的能力；云厂商的各类云服务，可以为平台提供存储的能力等等。 后续我们也会继续发布一些平台级的插件和能力，通过应用市场进行分发，供用户使用。目前已有Rainbond Pipeline 插件可以丰富平台的 CI 流程。

详细变更点​

新增功能​

• 支持平台级插件和能力扩展 #1480
• 新增流水线插件，扩充平台 CI 能力 #1180

优化功能​

• 支持通过 OpenAPI 创建组件 #1266
• 优化 Helm 仓库安装应用逻辑 #1570

BUG 修复​

• 修复Gitlab OAuth 仓库最多只显示20个仓库的问题 #1560
• 修复团队页面排序问题 #1571 #1274
• 修复 DockerCompose 放弃创建后，应用名重复的问题 #1573

感谢​

流水线插件由 拓维信息 提供，感谢 丁鹏、刘进文、朱智阳 在社区中的贡献，才能使产品变得更好，我们欢迎大家任何形式的参与和贡献。

详细变更点​

BUG 修复​

• 修复多节点集群资源信息错误的问题 https://github.com/goodrain/rainbond/pull/1537
• 修复低版本集群中，组件多个端口打开对内服务不生效的问题 https://github.com/goodrain/rainbond/pull/1552
• 修复出口网络治理插件不可用的问题 https://github.com/goodrain/rainbond/pull/1547
• 修复无法获取节点角色的问题 https://github.com/goodrain/rainbond/pull/1535
• 修复不安全的镜像仓库无法构建的问题 https://github.com/goodrain/rainbond/issues/1469
• 修复使用Helm安装应用而不创建CRD资源的问题 https://github.com/goodrain/rainbond/pull/1556
• 修复 netcore 构建失败的问题 https://github.com/goodrain/rainbond/pull/1551
• 修复多模块组件，启用自动构建不生效的问题 https://github.com/goodrain/rainbond/issues/1532
• 修复 helm 安装平台时指定 nfs 镜像不生效的问题 https://github.com/goodrain/rainbond/issues/1553

在这个版本中，我们主要关注用户集群管理、平台扩展能力的加强，以及更好的与 Kubernetes 生态结合。该版本主要变化有：新增集群和节点管理面板；支持将应用导出 Helm Chart 包在 K8s 集群中一键部署。

主要功能点解读：​

1. 支持导出 Helm Chart 包​

Helm 作为 Kubernetes 上应用的包管理工具，有许多用户使用其部署应用。但是 Helm Chart 的编写门槛较高。而 Rainbond 作为一款应用管理平台，可以方便的发布应用模版并用于部署和交付，但是由于交付客户环境不同，所以如何根据客户环境匹配交付方式也是一大难点。所以为了解决这类问题，这个版本支持了导出 Helm Chart 包，用户可以不需要了解 Helm Chart 细节即可一键导出。

在之前的版本中，Rainbond 已经支持将发布的应用模版导出以下三种类型的包: Rainbond 应用模型包、非容器包、DockerCompose 包。分别可以在 Rainbond、Linux 以及 DockerCompose 环境中运行。

而本次新增的导出 Helm Chart 包则可以在不安装 Rainbond 的情况下，直接在 Kubernetes 上运行。用户只需要通过将应用发布成应用模版，即可生成对应的 Helm Chart，并且包含组件所需的所有镜像。这样在交付环境只有 Kubernetes 集群时，也可通过 Helm 一键交付。并且由于包含了所需镜像，该导出包在离线环境也可以正常使用。

当前仅支持应用治理模式为原生 Service 的应用模版进行导出，目前支持的配置参数有 storageClass 、镜像地址以及环境变量(应用配置组)。参考文档

2. 新增集群和节点管理​

在之前的版本中，Rainbond 缺少对集群和节点的管理，虽然支持了命令行，可以从平台直接操作 Kubernetes 集群，但对于平台管理员而言，对集群进行基本的管理和监控仍不够友好。因此新增了集群和节点管理面板，用于管理集群。在平台管理-集群，点击对应集群即可进入。

集群管理面板向用户展示了集群和节点的基本信息和资源使用情况；如CPU、内存、存储等，同时列出了 Rainbond 自身组件的运行状况，用户可以根据这些信息进行资源监控以及排错。如果用户安装的集群是通过 Rainbond 主机对接的方式进行安装，那么还可以在该页面进行节点的添加和删除。

对于用户自建的集群，也支持修改对应节点的标签、污点等属性，同时还可以在页面上一键禁止调度和排空操作。参考文档

详细变更点​

新增功能​

• 支持从应用市场导出 Helm Chart 包
• 新增集群和节点管理面板
• 支持平台级插件和能力扩展

优化功能​

• 默认应用治理模式变更为原生 Service 模式
• 优化平台页面加载速度
• 组件健康监测支持存活命令探针
• 离线版本加入集群命令行镜像
• 支持jar、war包上传多个文件可携带相关配置文件
• 为 api 提供单独的健康监测路由 #1500
• 优化了组件创建高级设置的流程

BUG 修复​

• 修复指定外部数据库迁移失败问题 #1509
• 修复离线环境安装应用市场应用失败问题 #1508
• 修复应用页面组件更新后展示效果问题 #1479
• 修复用户管理界面查看详细信息服务端异常问题 #1475
• 修复应用内部选择从组件构建无法选择应用导致无法进入下一步问题 #1474
• 修复个人中心跳转至企业管理页面无法展示的问题 #1467
• 修复对docker仓库注册密码长度的限制问题 #1459
• 修复开发者用户点击总览页面显示空白页问题 #1481
• 修复组件打印两遍日志问题 #1448

感谢​

感谢用户 zhishiguai、mumudadi、epower-cloud、lihao6666、William-ZXS、huihui-hb、srcio 等用户在社区中的参与与反馈，才能使产品变得更好，我们欢迎大家任何形式的参与和贡献。

详细变更点​

新增功能​

• 新增k8s特殊属性(shareProcessNamespace,dnsPolicy,resources,hostIPC,lifecycle)设置 #1343
• 源码构建 nodejs 项目时，支持自主选择构建前端或后端项目

优化功能​

• 优化前端页面样式
• 优化工作空间查询速度
• 工作空间新增组件删除动态

BUG 修复​

• 修复应用视图下无法更新应用 k8s 资源问题
• 修复多节点集群中 dockerfile 构建失败问题 #1423
• 修复组件批量操作选项错误的问题 #1451
• 修复组件依赖页面展示问题 #1450
• 修复部分翻译问题 #1433 #1449
• 修复 mac intel 机器上安装失败的问题 #1439

详细变更点​

新增功能​

• 【视图管理】 增加工作空间，优化开发者使用体验
• 【视图管理】 重构平台管理视图，增加应用报警
• 【视图管理】 通过界面直接查看 Rainbond组件的日志
• 【应用管理】 支持集群命令行
• 【集群管理】 Helm 安装的应用自动转换为 Rainbond 应用模型

优化功能​

• 通过主机安装默认的K8s版本提升至 v1.23.10 #65
• 默认的K8s Dashboard 版本升级至 v2.6.1
• 优化单机版安装启动速度 #1188
• 支持在 Centos 8, Debian 11 上安装
• 离线安装包支持源码构建

BUG 修复​

• 【网关管理】修复网关策略在备份恢复后无法使用的问题(https://github.com/goodrain/rainbond/issues/1224)
• 【备份管理】修复备份管理状态错误问题(https://github.com/goodrain/rainbond/issues/1374)
• 【插件管理】修复服务实时性能分析-历史-undefined问题(https://github.com/goodrain/rainbond/issues/1378)
• 【部署管理】修复Helm 对接集群已经使用了外部数据库，安装还是会启动 rbd-db 问题(https://github.com/goodrain/rainbond/issues/1366)
• 【平台管理】修复了单机体验版重启后平台无法使用的问题(https://github.com/goodrain/rainbond/pull/1396)
• 【插件管理】修复从 Dockerfile 构建插件无法使用的问题(https://github.com/goodrain/rainbond/issues/1405)
• 【翻译管理】修复部分翻译问题(https://github.com/goodrain/rainbond/issues/1402)(https://github.com/goodrain/rainbond/issues/1375)
• 【组件管理】修复单机体验版 yaml 文件上传，部署组件失败的问题(https://github.com/goodrain/rainbond/issues/1370)
• 【安装管理】修复 helm 多节点安装时，仅指定网关节点，配置漂移的问题(https://github.com/goodrain/rainbond/issues/1264)