什么是真的，什么是装的
一句话总结
这个实习板没有任何真正的GPU、真正的containerd、GPU Operator。取而代之的是TOML解析器和真正的容器控制平面，这次事故中抓获的人几乎全部都用这两个东西重现了。
为什么在假环境里做这个
如果逐一列举在GPU事故中实际需要学习的东西，就会是这样的。
- 判断两个设置文件是否在同一表格上碰撞的方法→解析就可以了
- 使用查看加载的而不是文件的检查脚本的方法→只要是shell就可以
- 如果没有资源广告，帕德在哪里会卡住→日程安排器必须是真的
- 在时间切片设置中计算插槽数和内存的方法→算术就可以了
- 滚动在一个节点停止的样子→恶魔集控制器必须是真的
在这个列表中nvidia-smi没有。只有实际触摸GPU设备才能学习，那就是驱动程序构建和实际内核运行性能，这两者并不是这次事故的原因。原因全部在设置和对象上。
什么是真正被验证的，什么是模仿的？
| 在实习中做的事情 | 在这个环境中的地位 |
|---|---|
| 用TOML写containerd设置并解析 | 实体。真正的解析器会读懂 |
| 主设置和Dropin表格冲突判断 | 实物。计算完全正确 |
| 检查脚本动作验证 | 搭建真实的、假的containerd，实际运行两次 |
| RuntimeClass注册 | 实体。真正的API服务器存储 |
| GPU资源广告和调度 | 实物。真正的调度器来判断 |
| 恶魔阵滚动更新停止 | 实体。真正的控制器停止工作 |
| GPU实际上是否安装在节点上 | **模仿。**只在节点status上写数字 |
| 在容器中使用GPU | 无。 容器未运行 |
| 重新启动containerd，让handler注册 | **无。**只处理概念和检查脚本 |
特别是最后一句要明确一下。SIGHUP不能那样做，必须重新开始的事实**无法在该板块中实证。**所以实习，取而代之的是制作“无论是否重新开始，都告知真相的检查脚本”。在现场，知识通过手来表达的地方就是那个脚本。
直接在现场使用的
在实习中制作的成果中，三个可以直接带到公司。
check-runtime.sh—节点启动后直接交给检查或CI门。判断标准不是文件而是dump，其特性与环境无关。- 老虎机计算表——在打开时间切片之前显示给用户的表格。两行“座位20个，保证内存0”结束对话的一半。
- 部署停止报告——只剩下看了哪个栏位，判断了什么。事故报告的骨架就是这个。
真正在GPU节点上变化的东西
如果在练习中留下模仿的部分中了解现场有什么不同，以后站在实物面前就不会慌张。
驱动程序和内核一起移动。 GPU驱动程序是内核模块，所以内核版本变更后需要重新构建。因此，如果设置为节点自动更新内核，重新启动后GPU就会消失，节点会升到Ready状态。虽然设备被安排，容器出现，但只有设备没有状态，所以症状只表现为“找不到GPU”的应用程序错误。在节点标签上贴上驱动程序版本，如果它消失，阻止安排是标准的防御措施。
资源广告经过多个层。 设备插件注册在kubelet上，kubelet将它上传到节点status上，调度器会查看它。无论在哪个层中断，结果都是一样的“Padds Pending”。所以调查是从上到下的。节点status上有资源吗→如果没有，kubelet日志→设备插件Padds状态→该Padds是否正确地挂载了socket目录。如果不确定这个顺序，每次都会从其他地方开始。
**GPU有多种共享方式。**时间切片是轮流使用的，所以内存不会隔离，如果一个片段用完内存，剩下的也会一起死掉。MIG是完全在硬件上分开的，所以隔离是确定的，但可以分开的组合是固定的，更换时必须清空节点。如果需要隔离，MIG，如果利用率是目的，时间切片是实务的基准线，应该向用户解释这个选择。
总结一下，在这个练习中熟练掌握的是留下判断顺序和依据的方式。这两个与GPU是真的还是模仿的无关，直接使用，在实物面前需要重新学习的只有上述三段左右。
下次实习要做的事情
从八个步骤开始重新踏上事故的道路。前四个步骤涉及节点的设置文件，后四个步骤涉及群集对象。最后两个步骤将前面制作的东西汇总起来，通过计算和报告结束。