测验：共享与滚动发布

在 4 块物理 GPU 上设置分时共享 replicas 5 后，节点会通告多少个资源？

• 20 个，并且每个槽位都没有受保障的 VRAM
• 20 个，每个槽位各自拥有五分之一的 VRAM
• 5 个，其余三块 GPU 不会被通告
• 4 个，每个 Pod 分配 5 个流

如果生产推理服务和实验用 Notebook 必须使用同一套 GPU 资源，应当怎么做？

• 增加分时共享 replicas，预留充足槽位
• 拆分节点池，将需要隔离的工作负载单独放置
• 启用 MPS 守护进程，让内核并发执行
• 将请求量提高到 2，让每一方各占用两个切片

为什么要将 failRequestsGreaterThanOne 设为 true？

• 为了只在仍有空闲切片时才接受 Pod
• 为了按照请求数量自动设置显存上限
• 因为多个切片并不等同于多块设备
• 为了防止 Pod 数量超过设备数量

DaemonSet 停留在 DESIRED 3、READY 2、UP-TO-DATE 1。这个状态意味着什么？

• 三个节点都已收到新规约，只是在等待就绪
• 控制器暂时暂停，很快会继续处理下一个节点
• DaemonSet 已将两个节点排除在目标之外，因此规模缩小
• 有一个节点无法启动新 Pod，导致另外两个节点仍使用旧规约

要通过告警检测 rollout 停滞，应观察什么？

• desired 与 ready 是否持续数分钟不一致
• DaemonSet Pod 的重启次数是否不断增加
• 容器日志中是否出现错误字符串
• 节点 GPU 使用率是否突然下降

如果新规约无法启动的原因是缺少 toleration，会出现什么区别？

• Pod 不会处于 Pending，而会停留在 ImagePullBackOff
• DESIRED 数值本身会减少，Pod 也会消失
• UP-TO-DATE 会先增加到全部节点数量
• rollout 不会停止，而会一直推进到最后一个节点