测验：toolkit 与运行时注册

主机上 nvidia-smi 正常，但容器内看不到 GPU。最可能的原因是什么？

• 主机驱动版本过低，不受支持
• 容器运行时未注册 nvidia 运行时，或不存在 CDI 规范
• GPU 正被其他进程占用
• GPU 内核模块尚未加载

从互联网复制的 containerd 配置片段完全不起作用。最可能的原因是什么？

• 引号写错了
• 权限不足
• config version 不同，导致节标题路径整体发生变化
• 没有重启 containerd

为什么不应把 default_runtime_name 改为 nvidia？

• 因为 NVIDIA 运行时处理普通 Pod 更慢
• 因为运行时配置本身复杂，难以管理
• 因为连不使用 GPU 的 Pod 也会依赖该运行时，从而扩大故障半径
• 因为它与 CDI 注入方式存在根本冲突

为什么建议在 systemd 主机上设置 SystemdCgroup = true？

• 因为 systemd 驱动性能更好
• 因为 kubelet 与 containerd 使用不同的 cgroup 驱动会造成视角不一致
• 因为 containerd 默认值本来就是它
• 因为运行 GPU 工作负载必须设置它

如果 RuntimeClass 的 handler 值与 config.toml 中的运行时名称不同，会怎样？

• Pod 显示 RunContainerError，并提示运行时不存在
• 无警告地回退到默认运行时并继续工作
• 事件中只留下警告，Pod 正常启动
• kubelet 报错，节点变为 NotReady

在托管节点组中登录节点并直接修改 config.toml 会怎样？

• 只要节点存活，修改就会永久保留
• 节点被替换后修改会消失；更糟的是，它可能只残留在部分节点上，形成无法复现的差异
• 修改会自动复制到节点组中的其他节点
• kubelet 会检测到修改并恢复原状