信创环境中的应用管理：已验证范围与实施边界
Rainbond 当前公开文档覆盖 x86_64、ARM64、多架构节点和多集群管理。站内还有麒麟 V10 / ARM 的安装教程，以及历史案例中记录的鲲鹏 920、FT2000+/64 适配测试。其他 CPU、操作系统、GPU 和国产数据库组合没有完整的公开版本矩阵，项目落地前需要逐项验证。
最近更新时间：2026-10-25。
当前可以直接核对的能力
x86_64 与 ARM64
多架构文档说明了两种使用方式：
- 在同一个 Kubernetes 集群中加入 x86_64 和 ARM64 节点，按节点架构调度组件。
- 分别接入 x86_64 与 ARM64 集群，再通过团队和应用管理不同集群中的业务。
应用能否跨架构运行，取决于镜像 manifest、基础镜像、系统包和闭源依赖。平台识别节点架构，但不会把 x86 二进制自动转换为 ARM64 二进制。
麒麟 V10 / ARM 安装路径
站内提供麒麟 V10 / ARM 的离线安装流程，使用 ARM64 版本 ROI 准备安装物料。教程可以作为环境验证起点，但正式项目仍要确认服务器型号、操作系统小版本、内核、 容器运行时、网络和存储。
应用模板和离线交付
应用可以发布为模板，并携带组件、依赖和主要运行配置。离线环境还要准备业务镜像、数据库脚本、系统依赖和校验清单。模板不会自动包含生产数据或外部系统凭据。
历史材料如何使用
站内历史案例记录了 2020 年起针对鲲鹏 920 和 FT2000+/64 的 ARM64 适配测试。这些材料可以证明 Rainbond 曾在相应环境中运行，但不能代替当前版本与当前硬件组合的验收。
以下信息目前不能从仓库中获得完整、可复核的版本清单，因此本页不宣称默认支持：
- 龙芯、海光、兆芯等 CPU 的具体型号与 Rainbond 版本组合。
- 统信、中标麒麟、龙蜥、欧拉等操作系统的完整版本矩阵。
- 国产数据库与业务应用之间的驱动、SQL 和迁移兼容性。
- NVIDIA 之外 GPU 的模型框架、驱动和 Device Plugin 组合。
项目验收时检查什么
| 检查项 | 最低验证内容 |
|---|---|
| CPU 与镜像 | 节点架构、镜像 manifest、闭源二进制和本地扩展 |
| 操作系统 | 发行版、小 版本、内核、容器运行时和时间同步 |
| Kubernetes | 版本、网络插件、存储类、入口网络和证书 |
| 数据库 | 驱动、SQL 方言、字符集、备份和回滚 |
| 离线物料 | 平台包、镜像、系统包、模型文件、校验值和版本清单 |
| 升级 | 验收环境、配置合并、数据库迁移和回切步骤 |
两种异构管理方式
单集群混合节点
适合网络连通、Kubernetes 版本一致，并且希望在一个集群中逐步加入 ARM64 节点的环境。构建节点和业务镜像都要覆盖实际使用的架构。
多个独立集群
适合不同机房、网络隔离或已有独立 Kubernetes 集群的环境。Rainbond 可以统一接入和查看集群，但跨集群网络、数据库复制和容灾仍要单独设计。
公开材料
麒麟 V10 / ARM 部署
查看环境准备、ARM64 ROI、离线安装和控制台验证。
多架构集群部署
查看混合集群和独立多集群两种部署方式。
x86 到 ARM 迁移记录
历史测试记录仅用于说明已有实践，当前项目仍需重新验收。
常见问题
可以直接写“支持所有信创环境”吗？
不可以。信创环境包含不同 CPU、操作系统、数据库、GPU 和业务依赖。没有逐项验证记录时，只能说明架构方向和已有案例。
ARM64 节点加入后，应用会自动兼容吗？
不会。调度只能选择合适的节点，应用镜像和二进制仍要包含 ARM64 版本。
已有历史认证或案例，还需要重新测试吗？
需要。历史材料不能覆盖当前 Rainbond 版本、操作系统小版本、服务器固件和业务依赖。
应该先验证平台还是业务应用？
先确认平台能在目标环境安装和运行，再用一套有代表性的业务应用验证构建、存储、网关、数据库、升级和回滚。
继续验证
按目标环境选择安装、迁移或多架构文档。