ARM64架构下RAGFlow部署与64KB内存页兼容性问题解决

1. RAGFlow ARM64 部署问题背景与挑战

在ARM64架构的Linux系统上部署RAGFlow时，我们遇到了一个相当棘手的问题：当系统使用64KB内存页大小时，核心组件sandbox或sandbox-executor-manager无法正常启动。这个问题在标准4KB页大小的系统上不会出现，但在某些ARM服务器和开发板上却很常见。

1.1 核心错误现象分析

系统日志中主要出现两类关键错误：

第一类是直接导致服务崩溃的panic错误：

code复制panic: Only 4K page size is supported on arm64!

这个错误明确告诉我们，gVisor（即runsc运行时）目前不支持64KB页大小的ARM64内核。gVisor作为Google开发的容器安全沙箱，其ARM64实现目前仅适配了最常见的4KB页大小配置。

第二类是连锁反应导致的次生错误：

code复制[Errno 8] Exec format error: 'docker'
Container pool is busy

即使我们尝试绕过gVisor，系统仍然无法正常工作。这是因为沙盒管理器内部的Docker客户端与宿主机架构/内核存在兼容性问题，导致无法创建子容器。这种兼容性问题在跨架构容器环境中相当常见。

1.2 问题根源剖析

深入分析这个问题，我们需要理解几个关键技术点：

1. 内存页大小的影响：ARM64架构支持多种内存页大小配置（4KB、16KB、64KB等），64KB页大小在某些场景下能提升性能，但会导致与某些软件的兼容性问题。

2. gVisor的限制：gVisor通过实现用户空间的内核来提供额外的安全隔离层，但其ARM64端口目前只支持4KB页大小，这是问题的直接原因。

3. 容器嵌套的复杂性：当容器内部需要调用宿主机Docker时，涉及二进制兼容性、文件系统映射和权限控制等多重挑战。

2. 完整解决方案设计与实施

2.1 解决方案总体思路

由于硬件环境限制无法更改页大小，我们必须调整软件架构：

1. 彻底弃用gVisor：强制所有容器使用标准Docker运行时（runc）
2. 解决Docker调用兼容性：将宿主机的Docker二进制文件直接挂