GPU Operator 是怎么来的

一句话总结

GPU Operator不是能快速加速GPU的东西。每个节点手动进行的五六种安装都搬到了一个群集对象上，作为便利性的代价，操作员会替换节点容器运行时设置。

为什么需要这个？

将一个GPU节点变成“可用的状态”的过程以前是这样的。

1. 调整并安装内核头文件，然后构建并上传驱动程序。如果失败，从内核版本开始重新查看。
2. nvidia-container-toolkit打开了。
3. 在containerd设置中nvidia注册运行时处理器。
4. 重新启动containerd。
5. nvidia-device-plugin上传GPU，让GPU成为资源进行广告。
6. dcgm-exporter上传并提高使用率。

一个节点需要30分钟，七个节点需要一天。问题不是时间，而是漂移。3月份制作的节点是驱动器535，8月份追加的节点是550。如果核心自动更新，只有那个节点的驱动器就会崩溃。人重复的程序必须分裂，分裂的群集每周都会提出“为什么只有那个节点不行”的问题。

GPU Operator 将整个这个程序改成想要的状态声明。ClusterPolicy写下一张定制资源后，操作员会设置所需的DEMONSET，如果节点新进来，就会自动按照同样的程序进行。即使重新创建节点，结果也一样——这就是这个操作员卖的唯一商品。

怎么行动

ClusterPolicy在下面一个下面，有几个恶魔阵列。每个负责上述步骤的一个步骤。

恶魔症	做的事情	如果没有的话会出现的症状
nvidia-driver-daemonset	在集装箱内建造、装载驱动器	nvidia-smi没有本身
nvidia-container-toolkit-daemonset	在节点的containerd设置中注册运行时处理器	PADRuntimeHandler由于错误生成失败
nvidia-device-plugin-daemonset	在节点status上nvidia.com/gpu广告	永远的帕德Pending
gpu-feature-discovery	GPU模型·内存作为节点标签	不能用调度条件作为标签
nvidia-dcgm-exporter	使用率、温度、ECC指标暴露	不知道谁掌握着GPU

这里存在顺序依赖。在驱动程序准备好之前，如果出现toolkit，那就毫无意义了，在toolkit注册启动时间之前，如果device plugin广告GPU，则调度器会发送板，但节点无法制作那个板。所以操作员会发送节点标签（nvidia.com/gpu.deploy.*）通过阶段进行控制。是让人们不必记住顺序的装置。

而且这里必须抓住的一个事实是。**2号恶魔阵是节点的/etc/containerd/直接修改。**不是创建集群内的对象，而是使用主机文件系统。这个课程的另一半都是从那句话中出来的故事。

在现场相遇的样子

第一，驱动程序通常提前设置在节点上。driver.enabled=false有很多组织在OS映像上预烧制驱动程序。在容器中构建驱动程序的方式是，每次内核升级时，都会在没有GPU的情况下创建几个分钟的节点运行区间，在封闭网络中，从接收头文件包开始就被阻止。那么GPU Operator所做的实际上就减少到“toolkit + device plugin +指标”这三个方面。

**第二，版本矩阵是真正的限制。**驱动程序·CUDA·toolkit·操作器·Kubernetes彼此都有支持范围。升级操作器是一次性移动这五个东西，如果放在和其他升级一样的窗口里，就无法区分原因。

**第三，从感谢的角度来看，这个操作员是特权软件。**它使用节点的文件系统，查看主机的PID命名空间，加载内核模块。在这里，直观上认为“因为是浮在Kubernetes上的板块，所以是隔离的”是不通的。如果在批准安装时没有在文件中留下这一事实，以后一定会出现问题。

在接下来的文章中可以看到

在后面的一篇文章中ClusterPolicy以下的恶魔套装们RuntimeClass哇nvidia.com/gpu看看如何通过资源连接。这两条分支是完全不同的门户，如果弄混了，就会陷入“Padd处于Pending状态，但找不到原因”的状态。