购物网站订单状态模板,全国建筑行业资质平台查询,如何利用互联网宣传与推广,报价平台开源 vGPU 方案 HAMi
一、k8s 环境下 GPU 资源管理的现状与问题
#xff08;一#xff09;资源感知与绑定
在 k8s 中#xff0c;资源与节点紧密绑定。对于 GPU 资源#xff0c;我们依赖 NVIDIA 提供的 device-plugin 来进行感知#xff0c;并将其上报到 kube-apiserver…开源 vGPU 方案 HAMi
一、k8s 环境下 GPU 资源管理的现状与问题
一资源感知与绑定
在 k8s 中资源与节点紧密绑定。对于 GPU 资源我们依赖 NVIDIA 提供的 device-plugin 来进行感知并将其上报到 kube-apiserver。例如通过执行 kubectl describe node gpu01|grep Capacity -A 7 命令我们可以看到节点上的资源信息其中包括 nvidia.com/gpu: 8这表明该节点上有 8 个 GPU。这一机制使得 k8s 能够对 GPU 资源有一定的了解但也带来了后续的调度问题。
二资源申请与调度限制
当我们创建一个 Pod 并申请 GPU 资源时如以下示例
apiVersion: v1
kind: Pod
metadata:name: gpu-pod
spec:containers:- name: gpu-containerimage: nvidia/cuda:11.0-baseresources:limits:nvidia.com/gpu: 1command: [nvidia-smi]restartPolicy: OnFailurekube-scheduler 会根据 Pod 的资源请求将其调度到拥有足够 GPU 资源的 Node 上。但这里存在一个关键问题一旦 GPU 资源被某个 Pod 申请在 k8s 中就被标记为已消耗后续创建的 Pod 可能会因为资源不足而无法调度。实际上GPU 的性能可能足以支持多个 Pod 共同使用但 k8s 的这种调度限制导致了资源利用率不高的情况。
二、HAMi 方案的引入GPU 资源管理的新希望
一什么是 HAMi
HAMi 全称为 Heterogeneous AI Computing Virtualization Middleware是一个异构算力虚拟化平台。它最初源自第四范式的 k8s-vgpu-scheduler如今不仅开源还将核心的 vCUDA 库 libvgpu.so 开放出来。当前HAMi 在 NVIDIA GPU 的 vGPU 方案方面表现出色为我们提供了一种有效的 GPU 资源共享和切分解决方案。
二HAMi 的特性细粒度 GPU 隔离
HAMi 的一大亮点是能够实现 GPU 的细粒度隔离可对 core 和 memory 使用 1% 级别的隔离。例如在创建 Pod 时我们可以通过以下方式指定 vGPU 的资源请求
apiVersion: v1
kind: Pod
metadata:name: gpu-pod
spec:containers:- name: ubuntu-containerimage: ubuntu:18.04command: [bash, -c, sleep 86400]resources:limits:nvidia.com/gpu: 1nvidia.com/gpumem: 3000nvidia.com/gpucores: 30在这个示例中nvidia.com/gpu: 1 表示请求 1 个 vGPUnvidia.com/gpumem: 3000 表示每个 vGPU 申请 3000m 显存nvidia.com/gpucores: 30 表示每个 vGPU 的算力为 30% 实际显卡的算力。这种细粒度的资源控制能力使得我们能够更精准地分配 GPU 资源满足不同任务的需求。
三、HAMi 的工作原理基于 vCUDA 方案的创新
一软件层面的驱动重写
HAMi 通过软件层面的 vCUDA 方案对 NVIDIA 原生的 CUDA 驱动进行重写libvgpu.so。它将改写后的驱动挂载到 Pod 中进行替换从而在自己实现的 CUDA 驱动中对 API 进行拦截。这一拦截机制是实现资源隔离和限制的关键。例如原生的 libvgpu.so 在进行内存分配时只有在 GPU 内存真正用完时才会提示 CUDA OOM而 HAMi 实现的 libvgpu.so 则不同当检测到 Pod 中使用的内存超过了 Resource 中的申请量时就会直接返回 OOM从而有效地限制了资源的使用。
二资源信息的隔离展示
在执行 nvidia-smi 命令查看 GPU 信息时HAMi 也只会返回 Pod Resource 中申请的资源进一步实现了资源的隔离展示。这使得用户在查看 GPU 资源使用情况时看到的是经过隔离后的准确信息避免了不同 Pod 之间资源信息的混淆。
四、HAMi 的部署与配置轻松上手的实践指南
一部署前的准备
部署 GPU Operator 由于 HAMi 依赖 NVIDIA 的相关组件推荐先部署 GPU Operator为后续 HAMi 的部署打下坚实的基础。获取 k8s 版本 在安装过程中需要根据集群服务端版本来指定调度器镜像版本因此要先通过 kubectl version 命令获取 k8s 版本信息。
二HAMi 的部署步骤
添加 repo 仓库 执行 helm repo add hami-charts https://project-hami.github.io/HAMi/ 命令添加 HAMi 的 Helm Chart 仓库。安装 HAMi 根据获取到的 k8s 版本使用如下命令进行安装假设集群服务端版本为 v1.27.4
helm install hami hami-charts/hami --set scheduler.kubeScheduler.imageTagv1.27.4 -n kube-system安装完成后可以通过 kubectl get pods -n kube-system|grep hami 命令查看 vgpu-device-plugin 与 vgpu-scheduler 两个 pod 的状态若状态为 Running则表示安装成功。
三自定义配置参数
HAMi 提供了丰富的自定义配置选项通过在安装过程中使用 -set 参数来修改。例如
devicePlugin.deviceSplitCount整数类型预设值是 10用于设置 GPU 的分割数每个 GPU 上最多可同时存在指定数量的任务。devicePlugin.deviceMemoryScaling浮点数类型预设值是 1可设置 NVIDIA 装置显存使用比例大于 1 时启用虚拟显存实验功能。devicePlugin.migStrategy字符串类型支持 “none” 与 “mixed” 两种工作方式用于指定是否使用 MIG 设备。devicePlugin.disablecorelimit字符串类型“true” 为关闭算力限制“false” 为启动算力限制默认为 “false”。scheduler.defaultMem整数类型预设值为 5000表示不配置显存时使用的默认显存大小单位为 MB。scheduler.defaultCores整数类型0 - 100默认为 0代表默认为每个任务预留的百分比算力。scheduler.defaultGPUNum整数类型默认为 1用于在 pod 资源中未设置 nvidia.com/gpu 时根据其他相关资源键的值添加默认的 nvidia.com/gpu 键和值。resourceName、resourceMem、resourceMemPercentage、resourceCores、resourcePriority 等分别用于设置申请 vgpu 个数、显存大小、显存比例、算力、任务优先级的资源名均有默认值。
此外容器中也有对应配置如 GPU_CORE_UTILIZATION_POLICY字符串类型“default”、“force”、“disable” 分别代表不同的容器算力限制策略和 ACTIVE_OOM_KILLER字符串类型“true” 或 “false” 表示容器是否会因超用显存而被终止执行。
五、HAMi 的验证确保资源管理的有效性
一查看 Node GPU 资源
在部署 HAMi 后虽然环境中可能只有一个物理 GPU但 HAMi 默认会对其进行扩容。例如通过执行 kubectl get node xxx -oyaml|grep capacity -A 7 命令我们可以查看 Node 的资源信息理论上能看到 nvidia.com/gpu 的数量有所增加默认扩容 10 倍这表明 HAMi 已经成功对 GPU 资源进行了虚拟切分。
二验证显存和算力限制
使用以下 YAML 文件创建一个 Pod 来验证显存和算力限制
apiVersion: v1
kind: Pod
metadata:name: gpu-pod
spec:containers:- name: ubuntu-containerimage: ubuntu:18.04command: [bash, -c, sleep 86400]resources:limits:nvidia.com/gpu: 1nvidia.com/gpumem: 3000nvidia.com/gpucores: 30创建完成后通过 kubectl exec -it gpu-pod -- bash 进入 Pod执行 nvidia-smi 命令。从输出结果中我们可以看到 GPU 的内存使用情况和算力使用情况是否符合我们在 Pod 资源请求中设定的限制。例如在上述示例中我们期望看到 GPU 内存使用量不超过 3000MiB算力使用不超过 30%。同时注意到命令执行后的日志中会有 HAMi 的 CUDA 驱动打印信息如 [HAMI-core Msg(16:139711087368000:multiprocess_memory_limit.c:434)]: Calling exit handler 16这也进一步证明了 HAMi 在资源管理方面的作用。
通过以上对 HAMi 方案的全面介绍我们可以看到它在 k8s 环境下 GPU 资源管理方面具有显著的优势和实用性。无论是解决资源利用率不高的问题还是实现细粒度的资源隔离与限制HAMi 都为我们提供了一种可行的解决方案。希望这篇博客能够帮助大家更好地理解和应用 HAMi在实际工作中充分发挥 GPU 资源的潜力提升计算任务的执行效率。
