本系列相关文章：
容器服务GPU监控2.0基于NVIDIA DCGM实现对集群GPU节点的全方位监控，您可以通过它监控：
-
集群维度的GPU资源使用情况，包括利用率、显存使用、XID错误检测等
-
节点池维度的GPU资源使用情况，包括利用率、显存使用、XID错误检测等
-
节点维度的GPU资源使用情况，包括利用率、显存使用、温度与功率、Profiling等
-
Pod维度的GPU资源使用情况，包括利用率，显存使用等
本篇文档将向您介绍如何使用容器服务GPU监控2.0监控ACK集群中的GPU资源。
前提条件
在使用容器服务GPU监控2.0之前，您需要：
-
GPU监控2.0本身支持专业版集群、标准版集群、Pro版集群、边缘集群，但是本文档中演示了GPU监控2.0支持共享GPU调度相关指标，而共享GPU调度仅支持Pro版集群，所以本文档演示所使用的集群为Pro版集群，另外集群版本不限
-
确保容器服务GPU监控2.0相关组件已经安装完成，如果没有安装，请参考文档： 开启集群GPU监控
注意事项
在使用容器服务GPU监控2.0之前，有如下的几点注意事项需要说明：
-
当前GPU监控指标的采集间隔时间为15s，且在Grafana监控大盘展示的数据相比指标产生的时候有一定的延迟，所以可能出现这种情况：某个时间点，从监控大盘显示某个节点明明没有可分配的显存，但是某个pod还是能够调度到该节点上。可能的原因是指标产生的时间点到下一次产生的15s间隔时间内，有pod完成了任务，释放了GPU资源，调度器感知到以后，将处于Pending的pod调度到这个节点上。
-
监控大盘仅能够监控通过 Pod resources.limits方式申请的GPU资源，如果节点存在如下几种方式使用GPU资源的情况，可能会导致监控大盘的数据不准确：
-
直接在节点上运行GPU应用
-
通过“docker run”命令直接启动容器运行GPU应用
-
在Pod的env中直接添加环境变量“NVIDIA_VISIBLE_DEVICES=all” 或“NVIDIA_VISIBLE_DEVICES=”等通过环境变量NVIDIA_VISIBLE_DEVICES直接为pod申请GPU资源，并且运行了GPU程序
-
Pod securityContext中设置 "privileged: true"，并且运行了GPU程序
-
Pod yaml中未设置环境变量NVIDIA_VISIBLE_DEVICES，但Pod所使用的镜像在制作时，默认设置环境变量NVIDIA_VISIBLE_DEVICES=all，并且运行了GPU程序
-
有两个概念需要明确，GPU卡的 已分配的显存和 已使用的显存，可以通过一个例子了解一下：假设某一张卡总共有16GiB显存，为某个pod分配了5GiB显存，但是这个pod的启动命令为“sleep 1000”，也就是说pod处于Running后并没有使用GPU，此时可以说，这张卡已分配的显存为5GiB，已使用的显存为0GiB
创建节点池
不管Pod是按整张卡方式申请GPU资源，还是按显存维度申请GPU资源（包括申请GPU算力资源），GPU监控大盘都能展示其相关指标。为了演示GPU监控2.0支持这些pod，将在一个集群中创建3个节点池来运行这些类的pod，每个节点池存在一个节点（方便展示效果），三个节点池信息如下：
节点池名称 |
支持运行pod类型 |
申请GPU资源示例 |
exclusive |
按整张卡的维度申请GPU资源 |
nvidia.com/gpu：1 申请1张GPU卡 |
share-mem |
按GPU显存维度申请GPU资源 |
aliyun.com/gpu-mem: 5 申请5GiB显存 |
share-mem-core |
按GPU显存维度申请GPU资源且同时支持申请算力申请 |
aliyun.com/gpu-mem: 5 申请5GiB显存 aliyun.com/gpu-core.percentage: 30 申请一张卡30%算力 |
对于创建3个节点池说明如下：
-
exclusive节点池：创建一个普通节点池，节点机型选择GPU机型即可
-
share-mem：集群需要安装共享GPU组件，节点机型选择GPU机型，并且给节点池打上标签ack.node.gpu.schedule=cgpu，具体请参考文档 安装并使用共享GPU组件
-
share-mem-core：集群需要安装共享GPU组件（整个集群只安装一次），节点机型选择GPU机型，并且给节点池打上标签ack.node.gpu.schedule=core_mem，具体请参考文档 共享GPU调度支持算力分配
三个节点池创建完成后的效果如下：
部署GPU应用
节点池创建完成后，为了验证节点GPU相关指标是否正常，需要在节点上运行一些GPU应用，本次示例选择运行项目tensorflow benchmark（需要说明：运行tensorflow benchmark项目至少需要9GiB显存）。在每个节点池创建一个任务，任务信息如下：
任务名称 |
运行在哪个节点池内 |
申请的GPU资源 |
tensorflow-benchmark-exclusive |
exclusive |
nvidia.com/gpu: 1，申请1张GPU卡 |
tensorflow-benchmark-share-mem |
share-mem |
aliyun.com/gpu-mem: 10，申请10GiB显存 |
tensorflow-benchmark-share-mem-core |
share-mem-core |
aliyun.com/gpu-mem: 10 ，申请10GiB显存aliyun.com/gpu-core.percentage: 30，申请1张卡的30%算力 |
使用kubectl apply -f ，创建每一个任务。
tensorflow-benchmark-exclusive的yaml如下：
apiVersion: batch/v1
kind: Job
metadata:
name: tensorflow-benchmark-exclusive
spec:
parallelism: 1
template:
metadata:
labels:
app: tensorflow-benchmark-exclusive
spec:
containers:
- name: tensorflow-benchmark
image: registry.cn-beijing.aliyuncs.com/ai-samples/gpushare-sample:benchmark-tensorflow-2.2.3
command:
- bash
- run.sh
- --num_batches=5000000
- --batch_size=8
resources:
limits:
nvidia.com/gpu: 1 # 申请1张GPU卡
workingDir: /root
restartPolicy: Nevertensorflow-benchmark-share-mem的yaml如下：
apiVersion: batch/v1
kind: Job
metadata:
name: tensorflow-benchmark-share-mem
spec:
parallelism: 1
template:
metadata:
labels:
app: tensorflow-benchmark-share-mem
spec:
containers:
- name: tensorflow-benchmark
image: registry.cn-beijing.aliyuncs.com/ai-samples/gpushare-sample:benchmark-tensorflow-2.2.3
command:
- bash
- run.sh
- --num_batches=5000000
- --batch_size=8
resources:
limits:
aliyun.com/gpu-mem: 10 # 申请10GiB显存
workingDir: /root
restartPolicy: Nevertensorflow-benchmark-share-mem-core的yaml如下：
apiVersion: batch/v1
kind: Job
metadata:
name: tensorflow-benchmark-share-mem-core
spec:
parallelism: 1
template:
metadata:
labels:
app: tensorflow-benchmark-share-mem-core
spec:
containers:
- name: tensorflow-benchmark
image: registry.cn-beijing.aliyuncs.com/ai-samples/gpushare-sample:benchmark-tensorflow-2.2.3
command:
- bash
- run.sh
- --num_batches=5000000
- --batch_size=8
resources:
limits:
aliyun.com/gpu-mem: 10 # 申请10GiB显存
aliyun.com/gpu-core.percentage: 30 # 申请1张卡的30%算力
workingDir: /root
restartPolicy: Never任务提交后等待任务的pod处于Running，可以使用kubectl get po查看：
# kubectl get po
NAME READY STATUS RESTARTS AGE
tensorflow-benchmark-exclusive-7dff2 1/1 Running 0 3m13s
tensorflow-benchmark-share-mem-core-k24gz 1/1 Running 0 4m22s
tensorflow-benchmark-share-mem-shmpj 1/1 Running 0 3m46s使用GPU监控2.0
集群维度GPU监控大盘
打开集群维度GPU监控大盘，具体步骤如下：
-
在 集群列表 页面中，单击目标集群名称或者目标集群右侧 操作 列下的 详情 。
-
在集群管理页左侧导航栏中，选择 运维管理 > Prometheus监控 。
-
在 Prometheus监控 大盘列表页面，单击 GPU监控 页签，您分别可以看到 集群维度的GPU监控大盘 和 节点维度的GPU监控大盘 ， 点击“集群维度GPU监控大盘” 。
从如下的监控大盘中可以看到：
-
集群总共有3个GPU节点
-
集群总共有3张GPU卡，已分配1.6张卡（如果是按整张卡维度申请GPU，一张卡分配的比例为1；如果是共享GPU调度，分配比例为某张卡已分配的显存与这张卡总的显存的比例）
-
已分配显存的百分比
-
已使用显存的百分比
-
集群中所有卡的平均利用率
-
集群中所有卡的内存控制器利用率
从大盘中的“GPU Pod Details”这个面板可以显示集群中申请GPU资源的Pod，包括：
-
pod名称、所属的namespace，运行在哪个节点上
-
已使用的显存
-
为该pod分配的显存，需要注意的是，如果是共享GPU调度，因为节点在上报api server每张卡总的显存时，仅支持上报整数，所以上报的显存数为节点的真实显存向下取整，举个例子：节点上某张卡的总显存为31.7GiB，节点上报给api server时，只能上报31GiB，如果pod申请了10GiB，那么为该pod分配的真实显存为31.7 * (10 / 31) = 10.2 GiB
-
为该pod分配的算力，如果pod没有申请算力，那么该值显示为“-”，可以看到tensorflow-benchmark-share-mem-core-k24gz这个pod申请了30%的算力
-
SM利用率、内存控制器利用率、编解码器的利用率
从大盘中的“GPU Node Details”这个面板可以显示集群中GPU节点的信息，包括：
-
节点名称
-
GPU卡索引号
-
GPU利用率
-
内存控制器利用率
-
已使用的显存
-
已分配的显存占总显存的比例
-
总显存大小
-
功率、温度、内存控制器温度
上面显示的是整个集群的GPU相关信息，也可以展示节点池维度的GPU信息，只需在左上角的“NodePool”选择目标节点池就行，从下面的图中可以看到，指定节点池后，监控大盘上的数据有变化，例如：总GPU节点变成了“1”，总GPU数变成了1，已分配数变成了1等。
节点为GPU监控大盘
也可以显示某个节点的GPU资源信息，有两种方式：
-
点击 Prometheus监控 大盘列表页面的 集群维度GPU监控大盘
-
在 集群维度监控大盘 的右上角，有一个“GPU Node Details”按钮，可以跳转过去
进入节点维度监控大盘以后，可以在右上角选择显示哪个节点，下面这张图显示的是cn-beijing.192.168.10.167这个节点，从中可以看到：
-
节点启用的GPU模式为Share，即共享GPU。如果是独占GPU，会显示成Exclusive。如果当前节点没有GPU Pod在运行，那么会显示成None。
-
节点的驱动版本
-
节点已分配GPU卡数与总的卡数
-
GPU平均利用率
-
显存已分配的比例
-
显存已使用的比例
-
节点已分配的算力比例，需要说明的是，只有在节点开启算力分配的情况下，这个面板才有数据显示，也就是说，本次示例中的三个节点，只有一个节点有数据显示（即cn-beijing.192.168.10.167，0号GPU卡已分配30%算力）。
在Utilization这个面板组可以看到与利用率有关的几个指标。
在Memory & BAR1这个面板组可以看到与显存和BAR1相关的指标。
在GPU Process这个面板组可以显示节点上运行的GPU线程信息。
除此以外，还有一些高级指标也做了展示，包括：
-
剖析（Profiling）
-
温度 & 能量（Temperature & Energy）
-
时钟频率（Clock）
-
GPU上停用的内存页（Retired Pages）
-
违规行为（Violation）
总结
本篇文档介绍了GPU监控2.0的一些基本使用方法，后续将会提供一些GPU监控2.0的最佳实践。
