阿里云容器服务GPU监控2.0基础篇1：基本功能使用

• 集群维度的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，每个节点池存在一个节点（方便展示效果），三个节点池信息如下：

对于创建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显存）。在每个节点池创建一个任务，任务信息如下：

使用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: Never

tensorflow-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: Never

tensorflow-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监控大盘，具体步骤如下：

1. 登录 容器服务管理控制台 。
2. 在 集群列表 页面中，单击目标集群名称或者目标集群右侧 操作 列下的 详情 。
3. 在集群管理页左侧导航栏中，选择 运维管理 > Prometheus监控 。
4. 在 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的最佳实践。