测验：运行时注册与配置合并

配置片段文件中写有 nvidia 运行时，但 Pod 因运行时错误而终止。首先应该检查什么？

• 配置片段文件的所有者和文件权限
• toolkit DaemonSet Pod 的重启次数
• 通过 containerd config dump 检查已加载的处理器列表
• 节点上安装的 nvidia 驱动程序版本字符串

toolkit 写入配置并发送 SIGHUP 后，运行时处理器仍未注册，原因是什么？

• 因为配置文件存在语法错误时，SIGHUP 会被忽略
• 因为 SIGHUP 信号无法从容器内部传递到宿主机
• 因为系统禁止重新加载时再次读取配置片段目录
• 因为 CRI 插件只在初始化时读取运行时处理器列表

恢复 GPU 配置时，正确的顺序是什么？

• 先让 toolkit 重新写入配置，再重启 containerd
• 先重启 containerd，再删除 toolkit Pod 使其重新创建
• 删除 toolkit Pod 后立即重启 containerd
• 重启节点后手动重新创建配置片段文件

运行时配置已经损坏，却在一段时间内没有任何症状，原因是什么？

• 因为 kubelet 会定期刷新配置缓存
• 因为已经运行的容器不会再次查询处理器
• 因为 device plugin 会持续发布资源，所以调度仍会继续
• 因为驱动程序 DaemonSet 会自动修复运行时错误

如果 imports 指定的 glob 与实际文件名不匹配，containerd 会怎么做？

• 拒绝启动，并在日志中记录配置错误
• 改为读取名称最相近的文件
• 不发出任何警告，直接跳过该文件
• 重新扫描整个配置片段目录

编写节点启动后的检查脚本时，必须避免什么做法？

• 检查失败时以非零退出码结束
• 将处理器名称与 RuntimeClass 中的值进行比较
• 让检查在节点每次启动时自动运行
• 直接读取配置文件来判断是否存在处理器