题干与适用场景
Kubernetes Pod 级资源允许 Pod 在容器资源之外声明 CPU、内存或 hugepages 请求与限制。两者同时存在时，Pod 级值优先，并影响调度、QoS 与 OOM 评分。发布前必须确认 PodLevelResources 特性门和集群版本。
假设代理和工作进程共享突发负载，但代理有延迟 SLO，工作进程可以使用剩余容量。目标是在不让调度器或 kubelet 强制执行错误预算的前提下表达这种关系。
面试官考察点
面试官关注资源所有权模型、优先级规则是否正确，以及是否知道 Pod 级资源会改变调度和 QoS。强回答会讨论总量与容器保证、限制、自动扩缩容、可观测性和迁移测试。
普通回答把容器请求相加后填入 spec.resources。强回答会说明 Pod 预算是否为共享池、哪个容器需要底线，以及如何防止工作进程占用代理延迟余量。
回答前需要澄清的问题
- Pod 级请求是共享预算，还是每个容器的硬性最低值？
- 涉及哪些 Kubernetes 版本、特性门、资源管理器和操作系统？
- 代理是否需要独立于工作进程的 CPU 底线或内存限制？
- HPA、VPA 和驱逐策略如何观察新的资源范围？
- 迁移期间同时设置 Pod 级和容器级请求会怎样？
如果容器需要独立扩缩或故障域，拆成不同 Pod 可能更安全。如果它们确实共享生命周期和突发预算，Pod 级资源更能表达关系。
30 秒回答框架
“我会先确认特性门和版本，再把 Pod 建模为共享预算并明确代理底线。Pod 级请求优先，所以要避免混合配置产生意外。我会测试 QoS、OOM 和自动扩缩输入，先灰度清单，对比延迟、节流、驱逐和成本，并保留回滚到容器级请求的路径。”
分步骤深入解答
- 划分资源角色。 测量代理延迟敏感度、工作进程突发、稳态用量和内存增长，决定共享预算还是隔离保证。
- 确认能力。 核对服务器版本、控制平面和节点上的
PodLevelResources、支持的资源类型及操作系统限制。 - 设置 Pod 预算。 用请求影响调度，用限制设定总上限，并为代理延迟底线与工作进程突发留出空间。
- 消除优先级歧义。 迁移期间记录 Pod 级值覆盖容器级值，删除冲突配置，或明确保留两层的目的。
- 检查 QoS 与驱逐。 重新计算 QoS 和 OOM 行为，测试节点压力、节流和工作进程争用；总量健康仍可能掩盖代理饥饿。
- 灰度观察。 先发布一个工作负载，跟踪 p95 延迟、CPU 节流、内存压力、OOM、驱逐、重启和成本，护栏稳定后再扩大。
替代方案包括拆分 Deployment、只使用容器级请求，或给 sidecar 设定显式限制。Pod 级资源适合生命周期和突发容量有意共享的场景。
高质量示范回答
“代理需要延迟底线，工作进程可以借用剩余 CPU。我会设置反映正常总量的 Pod 请求和突发上限，然后验证工作进程高负载时代理不会饥饿。迁移时删除冲突容器请求，或明确它们保留的目的，因为 Pod 级值会优先。我会在两台节点上灰度，观察 p95 延迟、节流、OOM、驱逐和自动扩缩行为；如果代理 SLO 退化，就回滚到旧的容器策略。”
常见错误
- 错误表现： 认为 Pod 请求自动提供每容器保证 → 失败原因： 预算可能是共享的 → 修正方法： 明确底线和隔离。
- 错误表现： 不记录冲突容器值 → 失败原因： Pod 优先级会让运维意外 → 修正方法： 文档化并测试生效资源。
- 错误表现： 只看 CPU 利用率 → 失败原因： 内存压力和 OOM 行为可能改变 → 修正方法： 联合观察 CPU、内存、QoS、驱逐和延迟。
- 错误表现： 只在一个控制平面组件启用 → 失败原因： 所有必需节点和组件都要支持 → 修正方法： 灰度前验证集群能力。
追问及应对
Pod 没达到限制但代理仍然饥饿，怎么办？
视为争用故障。增加代理底线、拆分工作负载或使用容器级隔离；总量余量不保证延迟。
Pod 级请求如何影响 QoS？
两层同时存在时 Pod 级值优先，并影响 Pod QoS 与 OOM 计算。迁移时重新计算类别并测试节点压力。
Windows Pod 能使用 Pod 级资源吗？
检查对应版本限制。Kubernetes 1.35 文档不支持 Windows Pod 的 Pod 级资源，因此应继续使用容器级策略。
什么时候应该拆 Pod？
当容器需要独立扩缩、失败处理或 SLO 时拆分。只有在共享生命周期和突发预算有意且可观测时才保留同一 Pod。