测验：GPU 栈的结构

引入 GPU Operator 后，实际获得的是什么？

• 把原本因节点而异的安装流程收敛为一份声明
• 让 GPU 计算通过绕过内核的路径提升速度
• 让多个 Pod 安全隔离地共享一块 GPU
• 消除驱动版本与 CUDA 版本之间的约束

如果 Pod 一直处于 Pending，甚至没有被分配到任何节点，首先应该查看哪里？

• 节点 containerd 配置中的 runtimes 表
• 节点 status 中 nvidia.com/gpu 的通告数量和污点
• 容器镜像的 CUDA 版本与标签
• RuntimeClass 对象中的 handler 字符串

如果把 RuntimeClass 的 handler 拼错后执行 apply，会发生什么？

• API server 会与已注册的 handler 列表核对并拒绝请求
• kubelet 会静默替换为默认 runtime 后运行
• apply 会通过，直到创建 Pod 时才在相应节点上失败
• 节点会变为 NotReady，DaemonSet 会尝试重新应用配置

在 Pod 中声明扩展资源 nvidia.com/gpu 时，应遵循什么规则？

• 只能写入 requests，limits 必须留空
• 为 requests 和 limits 设置不同数值，以允许突发使用
• 可以使用小数来申请一部分 GPU
• 在 limits 中填写整数，requests 会取相同的值

GPU Operator 的 toolkit DaemonSet 与其他 DaemonSet 最关键的区别是什么？

• 它修改的不是集群对象，而是节点文件系统
• 它不是部署在 namespace 中，而是以集群作用域部署
• 与其他 DaemonSet 不同，它完全不查看节点标签
• 它不是以 Pod 运行，而是由 kubelet 通过静态清单启动

为什么要在 GPU 节点上设置 nvidia.com/gpu 污点？

• 为 device plugin 通告资源争取时间
• 防止不使用 GPU 的工作负载占用昂贵节点
• 在重新加载驱动期间阻止创建容器
• 向调度器告知节点升级顺序