有些企业在信创改造时，为了兼顾现有 x86 应用、降低迁移成本，会选择采购搭载海光 CPU 的服务器。同时，也会为已经完成 ARM64 适配的业务采购鲲鹏服务器，于是同一环境中出现了两种架构并存的情况。

两类服务器上的应用各有运行要求，但部署、更新和日常运维又需要统一管理。如果这些服务器处于同一个网络和运维范围，就可以考虑搭建 Kubernetes 异构集群，让应用运行在对应架构的节点上，再通过 Rainbond 管理整套应用。

本文就以这一场景为出发点，介绍如何在离线环境中准备双架构环境、部署 Kubernetes 和 Rainbond，并验证应用的调度与通信。

一、环境准备

本文以三台服务器为例，一台搭载海光 CPU，另外两台搭载鲲鹏 CPU，操作系统均为 Anolis OS。

服务器	CPU 架构	操作系统	IP
海光服务器	x86_64	Anolis OS	172.17.6.202
鲲鹏服务器 1	ARM64	Anolis OS	172.17.6.201
鲲鹏服务器 2	ARM64	Anolis OS	172.17.6.200

在安装包和容器镜像中，x86_64 通常对应 amd64，ARM64 对应 arm64。后面下载离线包时，会同时用到这两种架构。

本次将海光服务器作为安装入口，也就是配置中的 bootstrap 节点，由它执行安装。三台服务器都承载业务负载，其中海光服务器和一台鲲鹏服务器同时作为源码构建节点，为两种架构的应用提供构建环境。

节点	本次配置的角色
node1：海光服务器	bootstrap、etcd、控制面、工作节点、网关、amd64 构建节点、NFS
node2：鲲鹏服务器 1	etcd、控制面、工作节点、arm64 构建节点
node3：鲲鹏服务器 2	etcd、工作节点

这套配置用于展示异构部署。网关和 NFS 均部署在单个节点上，不能仅凭三个 etcd 节点就将整套环境视为生产高可用方案。

安装前，需要确认三台服务器内网互通、主机名不同、时间同步，并按安装要求开放节点间通信端口。bootstrap 节点还需要能够通过 SSH 连接其他节点。

二、离线包准备

以下操作在有外网访问权限的环境中完成。

离线部署时，安装工具、系统组件镜像、Rainbond 镜像和源码构建环境都需要提前准备。混合架构还多了一项检查：是否同时覆盖 amd64 和 arm64。

1. 下载 ROI 安装工具

本例后续在海光服务器上执行安装，因此下载 amd64 版本的 ROI：

curl -fL -o roi https://get.rainbond.com/roi/roi-amd64
chmod +x roi

下载命令需要在能够运行该工具的环境中执行。安装工具自身的架构，与目标集群需要的离线包架构是两回事：这里使用 amd64 工具，准备的是两种架构的离线包。

2. 下载多架构离线安装包

./roi download --arch all

下载完成后，检查两种架构的程序包、运行时镜像和平台镜像是否齐全。本例的离线包目录如下，具体文件名以所用 ROI 版本的实际下载结果为准：

roi                                             # 安装工具
offline-packages/
├── install.sh                                  # RKE2 安装脚本
├── rke2.linux-amd64.tar.gz                       # amd64 RKE2 二进制包
├── rke2.linux-arm64.tar.gz                       # arm64 RKE2 二进制包
├── rke2-runtime-bootstrap-amd64.tar.zst          # amd64 RKE2 runtime 镜像包
├── rke2-runtime-bootstrap-arm64.tar.zst          # arm64 RKE2 runtime 镜像包
├── rke2-images-multiarch.tar.zst                 # 多架构 RKE2 镜像包
├── nfs-subdir-external-provisioner-4.0.18.tgz     # NFS Provisioner Chart
├── mysql-14.0.3.tgz                              # MySQL Chart
├── rainbond-images-multiarch.tar.zst             # 多架构 Rainbond 镜像包
├── rainbond.tgz                                 # Rainbond Chart
├── cnb-packages-amd64.tar.zst                    # amd64 源码构建包
├── cnb-packages-arm64.tar.zst                    # arm64 源码构建包
├── cnb-images-multiarch.tar.zst                  # 多架构源码构建镜像包
├── sha256sum-arm64.txt                          # arm64 校验清单
└── sha256sum-amd64.txt                          # amd64 校验清单

文件下载完成后，按照随包提供的校验清单核对完整性，传入离线环境后再次检查。

另外，本例使用 NFS，还需要提前准备操作系统对应架构的 NFS 主机侧依赖。不要只准备容器镜像，到了现场才发现系统缺少挂载所需的软件包。

3. 将离线包传入离线环境

将 roi 和完整的 offline-packages/ 目录复制到海光服务器 172.17.6.202，后续由这个 bootstrap 节点执行安装。

目录结构如下：

./
├── roi
└── offline-packages/

三、开始离线安装 K8s 和 Rainbond

1. 配置节点与角色

在 bootstrap 节点创建 cluster.yaml。配置主要分为两部分：

• hosts：服务器名称、连接地址和 SSH 信息。
• roleGroups：节点承担的集群与平台角色。

下面保留本例的完整角色配置。更多选项可参考 Rainbond 离线安装文档。

hosts:
  - name: node1
    address: 172.17.6.202
    internalAddress: 172.17.6.202
    user: root
    password: "${NODE1_SSH_PASSWORD}"
    port: 22
    bootstrap: true

  - name: node2
    address: 172.17.6.201
    internalAddress: 172.17.6.201
    user: root
    password: "${NODE2_SSH_PASSWORD}"
    port: 22

  - name: node3
    address: 172.17.6.200
    internalAddress: 172.17.6.200
    user: root
    password: "${NODE3_SSH_PASSWORD}"
    port: 22

roleGroups:
  # etcd 节点
  etcd:
    - node1
    - node2
    - node3

  # Kubernetes 控制面节点
  master:
    - node1
    - node2

  # 业务负载节点
  worker:
    - node1
    - node2
    - node3

  # Rainbond 网关节点
  rbd-gateway:
    - node1

  # 分别配置 amd64 和 arm64 源码构建节点
  rbd-chaos:
    - node1
    - node2

  # 集群内 NFS Server
  nfs-server:
    - node1

storage:
  nfs:
    enabled: true
    sharePath: /nfs-data/k8s
    storageClass:
      enabled: true

这里有两个配置值得注意。

bootstrap: true 只设置在执行安装的海光节点上，该节点同时属于控制面。

rbd-chaos 则选择了海光和鲲鹏各一个节点。如果后续需要同时构建 amd64 和 arm64 应用，就要为两种架构分别提供构建节点及对应的离线源码构建包。如只配置一种架构的构建节点，并不能满足另一种架构的源码构建需求。

2. 执行安装

确认 bootstrap 节点上的目录结构：

./
├── roi
├── cluster.yaml
└── offline-packages/

然后执行：

./roi up --mode offline --multiarch

安装过程中关注日志中的离线包检查、节点连接和组件部署结果。如果出现失败，先确认具体阶段，再检查对应架构的安装包或镜像，避免直接重复执行而忽略真正的错误原因。

四、访问 Rainbond 并检查集群

安装完成后，根据日志打印的地址访问控制台。本例的访问地址为：

http://172.17.6.202:7070

控制台能打开后，再检查节点和平台组件：

# 查看节点状态及所在架构
kubectl get nodes -o wide

# 查看 Kubernetes 系统组件
kubectl get pods -n kube-system

# 查看 Rainbond 组件与存储
kubectl get pods -n rbd-system

节点列表中应同时包含 amd64 和 arm64，并确认三台节点处于 Ready 状态。

五、离线环境下使用源码构建

如果还需要通过 Rainbond 源码构建应用，在 bootstrap 节点加载源码构建离线包：

./roi addon sourcebuild --multiarch

执行前，确认离线目录中包含本例所需的双架构构建包与镜像包：

offline-packages/
├── cnb-packages-amd64.tar.zst
├── cnb-packages-arm64.tar.zst
└── cnb-images-multiarch.tar.zst

如果缺少这些文件，需要返回联网环境补充下载。可以使用所选 ROI 版本支持的源码构建组件下载选项，并明确覆盖两种架构；下载后再将离线包传入 bootstrap 节点。

加载构建镜像，只是准备好了构建环境。 项目代码和 Maven、npm 等依赖也需要有内网可用的来源。如果项目仍指向公网 Git 仓库或依赖源，在完全离线的环境中，构建仍然可能失败。

六、验证应用部署

平台安装完成后，可以分别部署一个 amd64 和 arm64 应用，验证两种架构的节点是否能够正常运行组件。

在 Rainbond 中选择通过「容器镜像」创建组件，填写镜像地址，并在「CPU 架构」中选择对应类型：海光节点选择 amd64，鲲鹏节点选择 arm64，如下图所示。

需要注意，镜像本身必须支持所选架构。截图中的公网镜像地址仅用于展示配置方式，实际离线部署时，应使用内网可访问的镜像仓库，或上传提前准备好的镜像包。

完成创建后，查看组件的运行状态、实例所在节点和日志，并通过访问地址检查应用是否正常响应。分别完成两种架构的部署与访问验证，即可确认这套异构集群的基本应用运行能力。

最后

海光和鲲鹏采用不同的 CPU 架构，但在满足兼容性和网络条件的情况下，可以加入同一个 Kubernetes 集群，再通过 Rainbond 统一部署和管理应用。对于同时使用两类服务器的企业，这提供了一种组织现有资源的方式。

整个部署过程中，重点是提前准备齐两种架构的离线安装包，并为应用选择匹配的镜像和运行架构。后续接入实际业务时，也可以沿用这套流程，逐步验证应用依赖、存储和服务间通信，让不同架构的服务器共同承载业务。