openFuyao使能灵衢超节点：：让容器业务丝滑释放节点能力

1. 摘要

在AI算力规模持续扩展的背景下，灵衢超节点（UB）通过共享内存、内存借用、URMA高速通信等机制，重构了计算节点内外的数据交互范式。然而，K8s原生资源模型仍以单节点为边界，缺乏对超节点总线架构及新型编程模型的原生支持，无法直接释放UB在性能与效率上的优势。

为此，openFuyao在K8s体系内构建了面向超节点的系统级使能能力，涵盖设备接入、网络通信、存储与共享内存抽象，以及基于总线拓扑的调度增强等关键组件；通过扩展Device Plugin、CNI、CSI及调度框架，引入超节点资源建模与运行时适配机制，使容器业务能够极简、无缝地使用共享内存、内存借用与高速通信能力。

2. K8s生态对超节点支持存在GAP

灵衢超节点引入了UB内存池化、高速网络、DPU/SSD池化等全新能力，但K8s原生生态在资源抽象和调度编排上存在明显GAP，主要体现在：

2.1 硬件资源抽象与接入GAP

K8s原生资源模型以节点为固定边界，与超节点的池化特性存在根本冲突：

内存池化：超节点支持邻居节点间内存动态借用，导致单节点可用容量随时变化，而K8s的kubelet和调度器均基于静态容量做决策，无法感知这种变化。
网络管理：超节点支持URMA语义的高速通信网络，但当前无CNI能力供给给容器业务使用，需要构建URMA网络的设备插件，管理分配URMA网卡设备。
DPU与SSD池化：DPU物理拉远部署，SSD纳入池化管理，均需通过专门的Device Plugin和CSI插件实现跨节点发现、分配与挂载，K8s原生插件体系无法直接支持。

因此，必须针对UB硬件形态构建特有的CSI、CNI及Device Plugin，并对K8s资源监控体系进行适配，才能将超节点资源纳入统一管理。

2.2 调度编排与资源优化GAP

即便完成硬件接入，K8s原生调度器仍以单节点为调度粒度，缺乏超节点级的协同与优化能力，核心差距体现在四个方面：

静态资源 vs 动态池化

K8s假设节点资源固定不变，资源不足时只能让Pod持续等待或触发驱逐。超节点支持邻居内存借用和节点级垂直扩缩容，可在资源紧张时临时扩展容量，避免业务中断。
单节点调度 vs 拓扑感知

K8s调度器无法感知超节点内部拓扑（如上下半柜、邻居节点）的性能差异。超节点需要将互补型负载（资源波动大与资源平稳型）部署为邻居以平衡内存借用压力，同时将高带宽需求业务部署在同一内存池内，降低访问延迟。
故障重启 vs 无感迁移

面对硬件故障或资源压力，K8s只能重新调度Pod导致业务中断。超节点支持毫秒级容器热迁移，可在业务无感知的情况下完成切换与恢复。
固定预留 vs 弹性超分

K8s按配置全额预留资源，利用率受限且易产生浪费。超节点支持按需预留和动态超分，结合历史负载建模自动调优，在保障稳定的前提下显著提升资源利用率。

3. openFuyao灵衢超节点使能方案

3.1 超节点URMA网络支持

openFuyao对接K8s生态，提供超节点URMA网络设备对容器的供给能力。URMA高性能网络设备支持超大带宽的通信，容器业务通过URMA网络设备进行通信，可大幅度提升容器间网络通信效率。

构建URMA网络设备插件，支持发现并上报节点中的URMA网络设备。在业务Pod申请使用时，分配指定设备相关列表，并通过PreStartContainer接口提前设置URMA网络设备的网络命名空间，将URMA设备供给容器，支持业务通过UBSocket进行高带宽、低时延的通信。

容器业务申请使用URMA网卡示例如下：

yaml 复制代码

apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  containers:
  - name: demo
    resources:
      requests:
        cpu: 500m
        memory: 512Mi
        unifiedbus.com/ub_net_device: 1
      limits:
        cpu: 1
        memory: 1Gi
        unifiedbus.com/ub_net_device: 1

3.2 超节点内存池化能力

openFuyao对接 K8s生态，提供集群级的内存池化与共享能力。其中，内存共享机制用于提升进程间的数据交互与通信效率，内存借用机制用于在集群范围内实现内存资源的动态调度与弹性复用，从而提高整体内存利用率并降低节点 OOM风险。

3.2.1 内存无感借用

通过感知节点内存使用情况，基于内存逃生策略，触发内存借用，并使能容器内存冷热流动，提供基于借出状态和可用内存变化的调度能力，提升集群稳定性。

主要应用场景是当节点内存超分时，可以通过内存借用来扩容节点内存，当业务的短期峰值来临时，业务仍可正常运行，降低节点发生OOM的风险，且应用无感。matrixcontroller负责根据各节点的资源使用情况来决策借用还是归还；matrixagent负责节点资源使用情况的采集上报和决策的履行。

在使用时，首先需要配置水位线来告诉控制器借用和归还的条件，业务负载中需要新增标签来配置业务可以使用的远端内存的比例，业务使用的内存分配会变成75%的本地内存和25%的远端内存，25%是目前的最佳实践，保证业务性能损耗小于5%。

节点资源使用水线配置示例：

yaml 复制代码

apiVersion: v1
kind: ConfigMap
metadata:
  name: watermark-config
data:
  returnLine : 80   # 归还水位线
  secondLine: 90    # 内存借用水位线

Pod使用远端内存配置：

yaml 复制代码

apiVersion: v1
kind: Pod
metadata:
  name: demo
  labels:
    remote-mem-allocation-ratio: 25
spec:
  containers:
  - resources:
      limits:
        memory: 100Mi
        cpu: 100m

3.2.2 内存共享

共享是指将一块物理内存映射给多个业务，让业务可以进行数据的读写，来达到数据传输的目的。共享内存以设备的形式呈现，按需创建，通过标准的CSI的能力，将共享内存设备以卷的方式挂载给业务Pod，方便业务进行读写访问；此外还代理了共享内存的管理接口，做容量限制，保证可靠性的同时，也使得业务代码在虚机和容器场景保持一致，减少业务适配点。

常见的使用场景如大数据等业务间需要交换大量数据，走传统的网络数据搬迁效率较低，可以通过共享内存交换数据，提升业务通信效率。

在使用时，首先我们需要创建一个共享内存声明，在负载中以卷的方式将共享内存设备挂载到设备目录下，业务就可以进行共享内存的读写来进行数据交换。

共享内存的声明与引用示例：

yaml 复制代码

apiVersion: resource.ubsvirt.huawei.com/v1
kind: ShareMemoryVolume
metadata:
  name: my-sharememory
  namespace: kube-system
spec:
  storage: 5Gi  # 限额
---
containers:
  - volumeMounts:
    - name: my-volume
      mountPath: /dev
  volumes:
  - name: my-volume
    csi:  
      driver: shm-csi-driver 
      volumeAttributes: 
        type: matrixShareMem 
        identity: my-sharememory