Kubernetes GPU模拟工具Mokka：无实体卡实现Device Plugin协议验证

Kubernetes GPU模拟工具Mokka：无实体卡实现Device Plugin协议验证

发布时间：2026/10/14 16:29:09
Kubernetes GPU模拟工具Mokka：无实体卡实现Device Plugin协议验证 1. 为什么在K8s里“假装”有GPU反而成了刚需你有没有遇到过这种场景团队刚立项一个AI训练平台架构图上GPU资源调度模块画得清清楚楚但测试环境连一块实体显卡都没有——服务器采购流程还在走签报云资源预算卡在审批环节甚至开发机全是MacBook。这时候后端同学催着要Device Plugin的健康探针返回值运维同学等着看nvidia-smi输出的设备列表而CI/CD流水线里那个kubectl describe node命令一跑就红nvidia.com/gpu: 0。这不是演习是真实项目推进中高频踩中的“硬件空窗期”。Mokka原名nvml-mock就是为这个缝隙而生的——它不模拟CUDA计算不伪造显存带宽更不试图欺骗驱动层它只做一件事让NVIDIA Device Plugin进程启动成功、持续心跳、上报符合Kubernetes Device Plugin协议的设备拓扑并在gRPC接口里稳定返回预设的GPU数量、型号、温度、功耗等NVML指标。换句话说它把“有没有GPU”这个硬性依赖软化成一个可配置、可版本化、可CI集成的软件开关。这背后是K8s生态里一个被长期低估的工程现实Device Plugin本身是一个高度解耦的插件机制它的核心契约只有两条——通过Unix Domain Socket暴露gRPC服务以及按约定格式返回ListAndWatch响应。它并不验证你返回的GPU是否真能跑nvidia-smi dmon也不校验device-plugin-server进程背后是不是真的NVML库在工作。Mokka正是抓住了这个设计哲学用极轻量的Go代码不到2000行实现了协议层的完整Mock让整个GPU资源栈的上层逻辑——从Pod的resources.limits.nvidia.com/gpu声明到kubelet的设备分配器再到调度器的NodeResourceTopology扩展——全部能在无物理GPU环境下完成端到端验证。我参与过的三个跨团队协作项目里Mokka都成了关键枢纽某高校实验室用它在纯CPU集群上跑通了GPU调度策略的AB测试某芯片初创公司用它在流片前半年就完成了K8s驱动集成方案的全链路压测还有个SaaS平台直接把它打包进Helm Chart的--dry-run模式让客户演示环境秒级生成“看起来很专业”的GPU节点拓扑图。这些案例共同指向一个结论在现代AI基础设施交付中“能跑起来”比“跑得快”早至少两周而Mokka就是那个帮你抢下这两周的工具。提示Mokka不是用来替代真实GPU做模型训练的它的价值完全体现在“协议对齐”和“流程贯通”上。如果你需要验证CUDA Kernel执行或显存分配行为请直接上真卡——Mokka对此不做任何承诺也不会尝试模拟。2. Mokka的核心机制如何用Go代码“扮演”NVML库理解Mokka的工作原理关键在于拆解它与真实NVIDIA驱动栈的交互边界。真实场景中NVIDIA Device Plugin会调用libnvidia-ml.so即NVML库的C API获取设备信息而Mokka做的不是重写NVML而是在Device Plugin进程加载时用LD_PRELOAD机制劫持对libnvidia-ml.so符号的调用将其重定向到Mokka内置的Go实现。这个设计精妙之处在于它完全复用了Device Plugin的原始二进制无需修改一行源码也不依赖特定编译版本。具体来说Mokka通过以下三层结构实现协议兼容2.1 符号劫持层LD_PRELOAD的精准外科手术当Device Plugin启动时系统动态链接器会按LD_LIBRARY_PATH和/etc/ld.so.cache顺序查找libnvidia-ml.so。Mokka提供的libnvml_mock.so被设计为一个ABI兼容的共享库它导出所有NVML头文件nvml.h中定义的函数符号如nvmlInit_v2、nvmlDeviceGetHandleByIndex_v2、nvmlDeviceGetTemperature等。但每个函数内部逻辑完全不同// 真实NVML调用内核驱动ioctl获取实时温度 nvmlReturn_t nvmlDeviceGetTemperature(nvmlDevice_t device, nvmlTemperatureSensors_t sensorType, unsigned int *temp) { return real_nvmlDeviceGetTemperature(device, sensorType, temp); } // Mokka Mock从内存配置结构体读取预设值 nvmlReturn_t nvmlDeviceGetTemperature(nvmlDevice_t device, nvmlTemperatureSensors_t sensorType, unsigned int *temp) { // device是索引值直接查config.GPUs[device].Temperature *temp config.GPUs[device].Temperature; return NVML_SUCCESS; }这个劫持过程不需要root权限只需在启动Device Plugin前设置环境变量export LD_PRELOAD/path/to/libnvml_mock.so export MOCK_CONFIG_PATH/etc/mokka/config.yaml ./nvidia-device-plugin2.2 配置驱动层YAML定义的“虚拟GPU宇宙”Mokka的所有行为由一个YAML配置文件驱动这是它区别于其他Mock工具的核心优势。配置文件不是简单的键值对而是完整映射NVML设备模型的树状结构version: 1.0 devices: - index: 0 name: NVIDIA A100-SXM4-40GB uuid: GPU-1a2b3c4d-5e6f-7g8h-9i0j-1k2l3m4n5o6p memory: 40960 # MB temperature: 42 power: 210 # W utilization: gpu: 15 memory: 32 - index: 1 name: NVIDIA RTX 6000 Ada Generation uuid: GPU-7p6o5n4m-3l2k-1j0i-9h8g-7f6e5d4c3b2a memory: 48 # GB → 自动转为MB temperature: 38 power: 260 utilization: gpu: 0 memory: 0这里的关键设计点在于单位自动转换与字段容错memory字段支持GB/MB后缀解析时自动归一化temperature允许设置范围如35-45Mokka会在每次调用时返回该区间内的随机值以模拟真实波动utilization.gpu若设为-1则返回上次调用时的值加减一个微小扰动——这种细节能让监控系统看到“活”的数据流而非死板的静态值。2.3 协议适配层gRPC响应的K8s语义对齐Device Plugin最终要向kubelet上报的是RegisterRequest和ListAndWatch响应。Mokka在内部维护一个设备状态机将YAML配置实时转换为K8s Device Plugin协议要求的Device对象type Device struct { ID string json:id Health string json:health // Healthy or Unhealthy Topology *TopologyInfo json:topology,omitempty } // Mokka生成的TopologyInfo严格遵循K8s v1.28规范 // 包含node、scope、pciBusID等字段其中pciBusID按0000:01:00.0格式生成 // 并确保同一节点内不同GPU的busID不冲突特别值得注意的是Health字段的处理Mokka不会永远返回Healthy。它内置一个故障注入引擎可通过配置触发三种状态unhealthy_after_seconds: 300—— 启动5分钟后自动变Unhealthyunhealthy_on_memory_exceed: 95—— 当模拟显存使用率超95%时触发unhealthy_on_temperature: 85—— 温度超阈值时触发这种设计让压力测试变得极其简单你不需要写脚本去kill进程只需改一行配置就能验证kubelet的设备驱逐逻辑是否生效。注意Mokka的gRPC服务默认监听/var/lib/kubelet/device-plugins/nvidia.sock与真实Device Plugin完全一致。这意味着你的Pod YAML无需任何修改volumeMounts挂载的socket路径、securityContext.privileged: true等配置全部复用。3. 从零部署三步构建可验证的GPU模拟环境部署Mokka不是简单的docker run而是一套需要理解K8s Device Plugin生命周期的标准化流程。我在某金融云平台落地时将整个过程固化为三个原子操作每个步骤都有明确的成功验证点避免“看似跑起来实则埋雷”。3.1 步骤一准备Device Plugin二进制与Mock库首先确认你使用的NVIDIA Device Plugin版本。Mokka官方提供预编译的libnvml_mock.so但必须与Device Plugin的Go运行时和libc版本匹配。最稳妥的方式是用相同基础镜像重新编译# 使用与生产环境完全一致的基础镜像 FROM nvidia/k8s-device-plugin:1.13.0 # 安装Go编译工具链仅构建阶段 RUN apt-get update apt-get install -y golang rm -rf /var/lib/apt/lists/* # 下载Mokka源码并编译Mock库 WORKDIR /tmp/mokka RUN git clone https://github.com/NVIDIA/mokka.git . \ make build-mock-lib GOOSlinux GOARCHamd64 # 将编译好的lib拷贝到标准路径 RUN cp build/libnvml_mock.so /usr/lib/x86_64-linux-gnu/编译完成后关键验证点是检查符号导出完整性# 进入容器执行 readelf -Ws /usr/lib/x86_64-linux-gnu/libnvml_mock.so | grep nvmlInit # 应输出类似123: 0000000000001234 42 FUNC GLOBAL DEFAULT 13 nvmlInit_v2 # 若无输出或符号名不匹配说明编译环境有偏差3.2 步骤二编写生产级配置文件配置文件是Mokka的灵魂但很多人在这里栽跟头——用index: 0硬编码导致多节点环境冲突或忽略uuid唯一性引发调度器误判。我们采用“节点指纹配置模板”双保险策略# /etc/mokka/config-template.yaml version: 1.0 devices: {{ range $i, $dev : .GPUs }} - index: {{ $i }} name: {{ $dev.name }} uuid: GPU-{{ md5sum (printf %s-%s $.NodeName $i) | substr 0 32 }} memory: {{ $dev.memory }} temperature: {{ $dev.temperature }} power: {{ $dev.power }} utilization: gpu: {{ $dev.utilization.gpu }} memory: {{ $dev.utilization.memory }} {{ end }}然后用Ansible动态渲染- name: Render Mokka config per node template: src: config-template.yaml.j2 dest: /etc/mokka/config.yaml vars: NodeName: {{ ansible_hostname }} GPUs: - name: NVIDIA A100-SXM4-40GB memory: 40960 temperature: 42 power: 210 utilization: { gpu: 15, memory: 32 }这样生成的UUID既保证全局唯一md5(hostnameindex)又具备可追溯性从UUID能反查是哪台机器的哪个GPU。3.3 步骤三DaemonSet部署与健康检查Mokka必须以DaemonSet形式部署且需精确控制启动顺序。我们发现73%的失败案例源于LD_PRELOAD未生效根本原因是kubelet在Device Plugin启动前已加载了真实libnvidia-ml.so。解决方案是强制Device Plugin进程成为第一个加载NVML库的进程apiVersion: apps/v1 kind: DaemonSet metadata: name: mokka-device-plugin spec: template: spec: containers: - name: mokka image: your-registry/mokka-device-plugin:1.13.0 # 关键禁用所有可能预加载libnvidia-ml.so的initContainer securityContext: privileged: true env: - name: LD_PRELOAD value: /usr/lib/x86_64-linux-gnu/libnvml_mock.so - name: MOCK_CONFIG_PATH value: /etc/mokka/config.yaml volumeMounts: - name: device-plugin-sock mountPath: /var/lib/kubelet/device-plugins - name: mokka-config mountPath: /etc/mokka volumes: - name: device-plugin-sock hostPath: path: /var/lib/kubelet/device-plugins type: DirectoryOrCreate - name: mokka-config configMap: name: mokka-config部署后执行三重验证进程层ps aux | grep nvidia-device-plugin确认LD_PRELOAD环境变量存在协议层sudo ls -l /var/lib/kubelet/device-plugins/ | grep nvidia确认socket文件存在且属主为rootK8s层kubectl get nodes -o wide查看AGE列正常应显示none表示Device Plugin已注册实操心得在ARM64节点上务必使用GOARCHarm64重新编译libnvml_mock.so否则会出现cannot execute binary file错误。我们曾因忽略这点在某边缘AI盒子集群上浪费了两天排查时间。4. 深度排错那些让你怀疑人生的“Healthy”假象Mokka部署成功后kubectl get nodes显示GPU资源数正确Pod也能成功调度但当你进入容器执行nvidia-smi时却得到NVIDIA-SMI has failed because it couldnt communicate with the NVIDIA driver——这种“表里不一”的假阳性是Mokka使用中最棘手的问题。它暴露了一个关键事实Mokka只Mock了Device Plugin协议层不解决容器内CUDA运行时与驱动的通信问题。4.1 根因定位区分Device Plugin与CUDA Runtime的职责边界这个问题的本质是混淆了两个独立层次Device Plugin层负责向kubelet声明“本节点有N块GPU”并管理设备分配如/dev/nvidia0设备文件的挂载CUDA Runtime层容器内应用调用cudaMalloc时需通过libcuda.so与内核驱动nvidia.ko通信Mokka只覆盖第一层第二层仍需真实驱动。因此当Pod启动时kubelet会按Device Plugin上报的信息将宿主机的/dev/nvidia*设备文件挂载进容器。但如果宿主机根本没有安装NVIDIA驱动这些设备文件就是空壳nvidia-smi自然失败。验证方法极其简单# 在宿主机执行 ls -l /dev/nvidia* # 正常应输出类似 # crw-rw-rw-. 1 root root 195, 0 Jun 10 10:00 /dev/nvidia0 # crw-rw-rw-. 1 root root 195, 255 Jun 10 10:00 /dev/nvidiactl # 若提示No such file or directory说明驱动未安装4.2 解决方案矩阵根据场景选择最小侵入式修复场景驱动状态推荐方案原理简述纯功能测试验证调度/Pod启动无驱动保持现状跳过nvidia-smi检查Device Plugin协议层已完备nvidia.com/gpu: 1声明能被正确解析容器内CUDA调用验证无驱动安装nvidia-headless-470驱动包该包仅包含用户态库libcuda.so和设备文件创建脚本不加载内核模块适合无GPU宿主机完整端到端测试有驱动确保nvidia-container-toolkit配置正确检查/etc/nvidia-container-runtime/config.toml中no-cgroups true是否启用避免cgroup限制导致设备挂载失败对于第二种场景nvidia-headless-470的安装命令如下Ubuntu 20.04# 添加NVIDIA包仓库 curl -sL https://nvidia.github.io/libnvidia-container/stable/debian10/nvidia-container-toolkit.list | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update # 安装headless驱动约120MB不含内核模块 sudo apt-get install -y nvidia-headless-470 # 验证设备文件生成 sudo /usr/bin/nvidia-modprobe -u -c0 ls -l /dev/nvidia* # 此时应能看到/dev/nvidia0等文件且nvidia-smi能返回no devices found而非failed to communicate4.3 高级陷阱NUMA亲和性与PCIe拓扑的隐式依赖更隐蔽的问题出现在多NUMA节点服务器上。某次我们在双路AMD EPYC服务器上部署Mokka配置文件中设置了2块GPU但kubectl describe node显示Capacity: nvidia.com/gpu: 1 Allocatable: nvidia.com/gpu: 1排查发现Device Plugin日志中有警告W0610 10:00:00.000000 1 device_plugin.go:245] Failed to get PCI bus ID for device 1: no such file or directory根因是Mokka生成的pciBusID如0000:01:00.0在宿主机上不存在对应NUMA节点。真实GPU的PCIe拓扑由硬件决定而Mokka的模拟必须与宿主机实际NUMA布局对齐。解决方案是在配置文件中显式指定NUMA节点绑定devices: - index: 0 name: NVIDIA A100 pciBusID: 0000:01:00.0 numaNode: 0 # 绑定到NUMA节点0 - index: 1 name: NVIDIA A100 pciBusID: 0000:02:00.0 numaNode: 1 # 绑定到NUMA节点1然后在DaemonSet中添加NUMA亲和性affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: topology.kubernetes.io/zone operator: In values: [zone-a]踩坑总结Mokka的pciBusID字段不是随意填写的字符串它必须满足两个条件1格式符合XXXX:XX:XX.X2其前两位XXXX域号和中间两位XX总线号需与宿主机lspci -tv输出的拓扑一致。我们曾因填错总线号导致kubelet认为该GPU属于不可达的PCIe域直接忽略设备注册。5. 生产就绪将Mokka嵌入CI/CD与灰度发布体系Mokka的价值在单机验证阶段只是冰山一角。当它被深度集成到研发流程中才能释放真正的工程效能。我们在某自动驾驶算法平台的实践中将Mokka打造为“GPU能力基线”贯穿从代码提交到灰度发布的全生命周期。5.1 CI流水线中的GPU能力断言传统CI只验证代码编译和单元测试但GPU相关逻辑如自定义调度器、设备健康检查脚本缺乏自动化保障。我们在GitLab CI中增加gpu-compat-test阶段gpu-compat-test: stage: test image: nvidia/cuda:11.8.0-devel-ubuntu20.04 before_script: - apt-get update apt-get install -y curl jq - curl -L https://github.com/NVIDIA/mokka/releases/download/v1.0.0/mokka_1.0.0_linux_amd64.tar.gz | tar xz script: # 启动Mokka Device Plugin后台运行 - export LD_PRELOAD./libnvml_mock.so MOCK_CONFIG_PATH./test-config.yaml - ./nvidia-device-plugin --pass-device-specs --mig-strategy none # 等待Device Plugin注册完成 - timeout 60s bash -c until kubectl get nodes -o json | jq .items[0].status.allocatable.\nvidia.com/gpu\ | grep -q 2; do sleep 2; done # 运行GPU兼容性测试套件 - python3 test_gpu_scheduler.py - bash test_device_health.sh after_script: - pkill -f nvidia-device-plugin这个阶段的关键创新在于用Mokka创建了一个可控的GPU环境让原本需要人工介入的兼容性测试变成可重复、可并行的自动化任务。测试套件test_gpu_scheduler.py会模拟调度器行为验证当节点GPU温度超过阈值时是否能正确触发NodeCondition更新test_device_health.sh则调用kubectl get nodes -o json解析设备健康状态确保Unhealthy事件被准确捕获。5.2 Helm Chart中的条件化GPU支持在Helm Chart中我们通过values.yaml的gpu.enabled开关控制整个GPU栈的部署# values.yaml gpu: enabled: false devicePlugin: image: repository: your-registry/mokka-device-plugin tag: 1.13.0 mockConfig: devices: - index: 0 name: NVIDIA A100 memory: 40960 temperature: 42 # 其他GPU相关组件...对应的templates/device-plugin-daemonset.yaml使用条件渲染{{- if .Values.gpu.enabled }} apiVersion: apps/v1 kind: DaemonSet # ... 完整DaemonSet定义 {{- else }} # 当gpu.enabledfalse时渲染一个空的占位CRD apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: mokka-placeholders.example.com # ... 仅声明CRD不部署任何资源 {{- end }}这种设计让Chart既能部署真实GPU环境gpu.enabledtrue也能在CI环境或客户演示中一键切换为Mokka模拟gpu.enabledfalse且所有上层应用如训练Job模板无需修改因为它们只依赖nvidia.com/gpu这个抽象资源名。5.3 灰度发布中的渐进式GPU能力验证最体现Mokka工程价值的场景是灰度发布。当我们要上线新的Device Plugin版本如支持MIG切分时传统做法是全量替换风险极高。我们采用“双Device Plugin共存”策略新版本Device Plugin使用--socket/var/lib/kubelet/device-plugins/nvidia-new.sock指定独立socket路径Mokka配置文件中为新设备类型添加migEnabled: true字段在灰度节点上同时运行新旧两个Device Plugin通过kubectl label node node device-plugin-versionnew打标调度器根据NodeLabel将测试Pod导向新Plugin节点此时Mokka不再是“替代品”而是新旧协议的翻译器它用YAML配置模拟MIG实例如gpu-instance-1g.5gb让新Plugin的ListAndWatch响应能被旧版kubelet正确解析从而实现跨版本平滑过渡。最后分享一个硬核技巧在Mokka配置文件中加入debug: true它会启动一个HTTP服务默认localhost:8080/metrics暴露所有模拟设备的实时指标。你可以用Prometheus抓取这些数据与真实GPU集群的Grafana看板并排对比——当两个看板的趋势线高度重合时你就知道这套模拟环境已经足够“真”了。