设置 Kubernetes 资源请求与限制

根据实测用量选择 CPU 和内存请求，设置防止噪音邻居的限制，并验证 QoS、CPU 节流和 OOM 行为。

请求负责调度，限制负责执行

请求告诉调度器预留多少 CPU 和内存；限制告诉内核和 kubelet 容器最多能用多少。没有请求，调度器是盲的；没有限制，一个容器可以吃掉整个节点。两者都应基于测量，而不是通用模板。

resources:
  requests: { cpu: "250m", memory: "256Mi" }
  limits:   { cpu: "1",    memory: "512Mi" }

内存限制是硬性的：超过会触发 OOM kill，退出码通常是 137。CPU 限制通过节流执行，即使平均使用很低，也可能给突发负载增加延迟。复制模板前要理解差异。

CPU 和内存的请求都等于限制会得到 Guaranteed QoS；只有内存相等得到 Burstable；没有请求是 BestEffort，在节点压力下最先被驱逐。混合策略没问题，但要记录哪些负载获得保证容量以及原因。

以预期峰值运行工作负载，观察 kubectl top、CPU 节流指标和 OOM 事件。内存贴近限制的 Pod 会在流量尖峰或大请求时失败。对可变负载使用 HorizontalPodAutoscaler，并用 PodDisruptionBudget 保护自愿中断期间的可用性。

预期结果：峰值负载下没有 OOM kill，CPU 节流在可接受范围，Pod 保持 Ready。通过 kubectl top、节流指标和事件确认；再超过内存限制验证会触发 OOM，从而证明限制确实生效。