CXL内存池化：K8s调度实战指南

阅读收获

• 掌握CXL内存池化的核心逻辑：理解"可组合内存"如何打破单机内存容量天花板，实现跨Fabric的动态内存分配
• 理解K8s与CXL融合的技术路径：通过NRI和OFMA中间件实现非侵入式集成，避免修改K8s核心代码的工程风险
• 区分JRL方案与CXL 3.0原生能力：前者提供Pod级调度智慧，后者提供物理通道能力，二者的协同是落地关键

全文概览

数据中心正面临内存资源的结构性瓶颈——CPU核心因内存带宽或容量不足而闲置（"核心搁浅"）的现象日益普遍。传统服务器主板绑定的内存架构已难以满足云原生环境对弹性资源的需求。

CXL（Compute Express Link）技术通过实现内存池化与解耦，为这一困境提供了突破路径。然而，硬件就绪只是第一步——如何让CXL内存像本地资源一样被Kubernetes原生调度，仍是行业面临的核心挑战。

本文基于JRL在FMS25大会的技术分享，深入剖析K8s环境下CXL Fabric连接内存的调度架构，解读中间件层如何实现非侵入式集成，并探讨2026年CXL技术爆发的时间节点与落地路径。对于存储架构师、云基础设施工程师及行业研究者而言，这是一次理解下一代数据中心内存编排技术的绝佳机会。

👉 划线高亮 观点批注

• CXL 技术已进入商用实用阶段： 演讲者强调 CXL 不再仅仅是一个实验室概念或未来的愿景（Shining city on a hill），而是现在就可以部署并产生价值的成熟技术。这反映了 2025 年计算行业对 CXL 落地的高度信心。
• 有效解决“核心搁浅（Core Stranding）”问题： 在现代数据中心中，CPU 核心常因为内存带宽或容量不足而处于闲置状态，造成计算资源的巨大浪费。CXL 通过实现内存池化和扩展，打破了传统的内存边界，有效解决了计算资源与内存资源不匹配带来的“核心搁浅”痛点。
• 中间件（Middleware）是生态爆发的关键： 硬件的就绪只是第一步，要让 CXL 的内存池化、共享等特性在应用层透明运行，必须依赖强大的中间件支持。分析师认为目前中间件市场仍有空缺，急需更多的软件工具链来简化 CXL 的部署与管理。

过去一段时间，CXL内存池化一直被厂商广泛讨论，但在实际应用场景中被落地的很少。其核心原因是除了技术成熟度之外，有很多生态使用场景的问题没有得到解决，导致应用厂商在拥抱CXL的过程中，有很多顾虑。JRL发布了基于K8s的CXL管理调度工具，为数据中心原生调用CXL内存开辟了新的简易路线

幻灯片聚焦于 Kubernetes (K8s) 与 CXL Fabric 连接内存（Fabric Attached Memory） 的结合，探讨了现代云原生环境下的内存编排问题。

• 内存资源的“可组合化”定义： 图片将 CXL Fabric 连接内存定义为 "Composable"（可组合）。这意味着内存不再是绑定在特定服务器主板上的固定资源，而是可以通过 CXL 网络根据需要动态分配给计算节点的独立资源池。这与 K8s 调度计算资源的方式高度契合。
• 现有调度架构面临挑战： 演讲者指出，虽然 K8s 在调度 CPU 和标准内存方面非常成熟，但面对 CXL 这种具有 Fabric 特性的解耦内存（Disaggregated Memory）时，现有的调度逻辑可能会“失效”或面临挑战。这反映了从“以服务器为中心”到“以资源池为中心”转变过程中的技术断层。
• K8s 与 CXL 融合的必然性： K8s 既然是数据中心级别的调度器，那么它必然需要进化以支持 CXL 内存池。图片预示了讨论的重点将在于如何改造 K8s 的资源模型，使其能够识别并动态挂载 CXL Fabric 上的内存资源，从而提升大规模数据中心的资源利用率。

当K8S与CXL融合的时间线被行业接受，相当于CXL在数据中心资源编排被上游社区承认。这个时候需要推动的就是更多的应用厂商去兼容和大规模使用了

幻灯片深入探讨了在 Kubernetes (K8s) 环境下实现 可组合内存（Composable Memory） 的技术挑战与落地路径

• 回避直接修改 K8s 上游代码： 面对 CXL 等新型内存技术，与其尝试改变 K8s 庞大的底层调度逻辑，不如寻找“非侵入式”的替代方案。这反映了工业界在追求技术领先性的同时，对生产环境稳定性的高度妥协。
• NRI 成为关键接入点： NRI (Node Resource Interface) 被视为将 CXL 内存引入 K8s 生态的“救命稻草”。通过 NRI，开发者可以在不修改 K8s 核心的情况下，在容器运行时（Runtime）级别拦截资源请求，从而动态地将 CXL 内存池分配给特定的容器。
• 强调解耦与生命周期管理： 可组合内存的成功落地，关键在于它能否像普通内存一样被 K8s 挂载和回收。通过将 CXL 内存定义为一种特殊的资源类型，并结合 K8s 的生命周期钩子，可以实现内存资源像“云硬盘”一样按需分配，解决之前提到的“核心搁浅”问题。

与编排管理目前数据中心已有的资源相比，调度 CXL 内存资源会遇到哪些问题？

幻灯片展示了 CXL Fabric 连接内存栈（CXL Fabric-Attached Memory Stack） 的详细架构，是理解 CXL 如何在 Kubernetes 环境中实际落地的关键技术蓝图

该架构将系统划分为三个核心节点：控制节点（Controller Node）、数据面节点（Data plane node） 和 编排节点（Orchestrator node）

• 分层解耦的控制逻辑： 架构图展示了典型的“三权分立”：控制节点负责 K8s 业务逻辑，编排节点负责内存资源的全局调度，数据面节点负责最终的 I/O 执行。这种设计允许 CXL 内存池独立于计算节点进行扩展和管理。
• OFMA 协议的中心地位： Open Fabric Management Architecture (OFMA) 是贯穿三个节点的纽带。它定义了如何通过标准的 API 和 Agent 来发现、分配和监控跨织网（Fabric）的内存资源。这正是前几页 PPT 提到的“中间件”的具体表现形式。
• 内存作为“一等公民”接入 K8s： 通过在数据面节点引入 libdaxctl 和 CXL 驱动，系统将远程 Fabric 内存伪装成本地的 DAX（直接访问）设备。再结合编排节点的调度，使得 K8s 能够像分配 CPU 一样，动态地将 Fabric 上的内存块切分给不同的 POD 使用。

幻灯片是前一页详细架构图的抽象化与简化版，旨在通过逻辑分块来强调不同节点的功能重心以及对 Linux 内核版本的依赖

• 明确了内核准入门槛（Linux Kernel 6.3+）： 从技术分析角度看，这是最重要的信息点。CXL 2.0+ 的织网管理（Fabric Management）和内存热插拔特性需要较新版本的 Linux 内核原生支持。对于企业级用户，这意味着必须升级底层的 OS 环境才能开启 CXL 内存池化。
• 中间件（Middleware）的无处不在： 在简化图中，中间件横跨了所有三个节点。这呼应了第一页 PPT 的核心观点——“我们需要更多的中间件”。它在编排节点充当“大脑”，在控制节点充当“翻译官”，在数据面节点充当“执行者”。
• 标准化与模块化： 通过将复杂的组件（如 Kubelet, OFMA Agent 等）简化为“Resource Scheduler”和“Middleware”，演讲者试图向听众传递一个信号：CXL 架构正在走向模块化。只要软件栈符合这种逻辑分层，就可以实现对异构内存资源的统一调度。

幻灯片是该系列中最核心的一张架构逻辑图，详细展示了 可组合内存（Composable Memory）与 Kubernetes 之间的资源请求流转路径，以及各个关键组件如何协作

• 资源请求的“带外”异步编排： 图中展示了一个关键逻辑：K8s 原生调度器负责 Pod 的初步调度，但涉及 CXL 内存的分配时，是由 CXL Resource Monitor pod 捕获需求，并交给专门的 Fabric Orchestrator 去处理。这种设计避免了对 K8s 核心代码的侵入性修改，同时实现了对动态内存织网的精准控制。
• 解耦内存的动态绑定过程： 通过 Fabric Orchestrator 与各节点上 Fabric Daemon 的通信，系统可以实时地将远程 CXL 资源池中的指定内存块“绑定”到特定的计算节点操作系统中，使得 Pod 能够像访问本地内存一样使用这些 Fabric 资源。
• OFMA 实现了硬件资源的软件定义： OFMA 作为代理层，将复杂的物理 CXL 设备抽象为可调度的逻辑资源。这使得整个数据中心的内存变成了一个巨大的、可按需切割的“资源池”，彻底解决了传统架构中单机内存容量固定的限制。

幻灯片列举了能够从 CXL 内存池化与编排技术 中受益的典型应用场景和工作负载。它将前几页讨论的底层架构演进与实际的业务应用联系了起来

• 解决内存密集型应用的容量瓶颈： 对于 Redis、Memcached 以及类 TPC-H 的分析型数据库，单台服务器的物理内存插槽是有限的。通过 CXL Fabric，这些应用可以访问远超单机物理上限的内存池，从而处理更大规模的数据集，而无需通过缓慢的网络 I/O 进行分片。
• 提升云原生环境的资源利用率： 对于微服务和 Web 工作负载，资源需求往往是波动的。CXL 配合 K8s 编排，可以让这些应用在高峰期动态获取内存，在低谷期释放。这解决了由于预留过多内存导致的“内存搁浅”问题，显著降低了云供应商的 TCO（总拥有成本）。
• 加速大规模数据处理： Spark 和 pandas 等数据科学工具在处理 TB 级数据时，传统模式需要频繁交换到磁盘（Swapping）。CXL 提供的近内存级延迟让这些应用能够在内存中完成绝大部分计算，大幅提升数据分析效率。

国内CXL主控厂商和笔者交流说，26年下半年可能是CXL爆发的一个比较明显的时间点。当下数据中心内存和存储单价高涨、采购困难，是促进厂商愿意考虑利就或者池化内存的方案的直接原因

幻灯片展示了 JRL 在 Kubernetes (K8s) 中的集成架构图。它详细描绘了 CXL 控制逻辑如何嵌入到 K8s 的控制平面和数据平面中

• Reflector 机制实现了声明式管理： 通过在控制平面引入 Reflector，该架构遵循了 K8s 的“声明式”哲学。用户只需在 YAML 中定义所需的 CXL 内存，Reflector 就会捕获这一意图并驱动底层的 CXL Fabric 进行资源分配，实现了软件定义内存（SDM）的自动化。
• Init Pod 确保了内存挂载的同步性： OFMA Init pod 的设计非常巧妙。它利用 K8s 的初始化容器机制，在应用程序启动前完成 CXL 织网内存的“插拔”和“格式化”操作。这意味着应用程序无需修改任何代码，就能像使用本地物理内存一样使用 CXL 扩展内存。
• 非侵入式的集成方案： 从图中可以看出，JRL 方案并没有修改 K8s 的核心二进制文件（如 API Server 或 Kubelet），而是通过 Controller（Reflector） 和 Sidecar/Init Pod 的模式进行扩展。这种“插件化”的集成方式极大降低了在现有生产集群中部署 CXL 技术的门槛。

图进一步细化了 JRL OFMA 在集群中的组件分布，展示了“管理服务器（Mgmt Server）”与多个“数据面服务器（Dataplane Server）”的级联关系

• Mgmt Server (管理服务器 - 左上角)：
  • 运行 Memory Orchestrator（即 JRL 的 "Jack"）。
  • 核心逻辑： 维护 Fabric State（织网状态），通过 Open Fabric Management API 提供控制接口。它像一个中央大脑，知道整个 CXL 织网中有多少内存、被谁占用了。
• K8s 控制平面 (Mgmt Server - 左下角)：
  • Reflector (重点圈出)： JRL 的核心控制器。它监听 K8s API 的资源声明。
  • OFMA Monitor： 作为一个守护进程，实时反馈 CXL 织网的健康状况给 K8s。
• Dataplane Server (数据面服务器 - 右侧)：
  • OFMA Init pod (重点圈出)： 每一个工作节点上都运行这个初始化容器。
  • Memory Orchestration Data Plane： 这是该图的新亮点。每个节点都有一个私有的管理栈（TCP sock -> MEM CLI -> OFMA Agent），它负责将中央管理器的指令转化为底层的 libcxl 或 libdaxctl 调用，完成内存的物理挂载。
  • CXL Resources controlled by the OS： 明确了最终内存是由 OS 内核驱动（DAX/CXL driver）接管并提供给容器的。

理解 JRL 与 CXL3.0 原生Pooling 的能力差异

理解 JRL 与 原生 CXL 3.0 的关系，最核心的逻辑是：CXL 3.0 提供了“分配的能力”（物理通道），而 JRL 提供了“调度的智慧”（业务逻辑）

延伸思考

这次分享的内容就到这里了，或许以下几个问题，能够启发你更多的思考，欢迎留言，说说你的想法~

1. 在生产环境中部署CXL内存池化时，哪些中间件层的可靠性问题会直接影响业务的稳定性？
2. K8s调度CXL内存资源时，如何在"内存搁浅"与"调度开销"之间取得平衡？现有的调度策略是否需要重新设计？
3. 随着CXL技术从"概念验证"走向"规模商用"，传统存储厂商的市场定位将如何重构？是否会出现新的产业链分工？

原文标题：CXL Orchestration: Taming the Fabric

Notice：Human's prompt, Datasets by Gemini-3-Pro[1]

#FMS25 #CXL内存扩展

---【本文完】---

丰子恺-护生画集- 呦呦鸣鹿得食相呼