Pod资源请求（requests）和限制（limits）必须在容器级别显式声明，否则将导致Pending、OOMKilled、CPU节流或资源浪费；requests决定调度准入与资源预留，limits控制运行时上限并触发节流或OOM终止。
Pod 的资源请求（requests）和限制（limits）必须在容器级别显式声明，Kubernetes 才能据此调度和约束运行时行为。不配置或配置不当会导致 Pending、OOMKilled、CPU 节流或资源浪费。
requests 决定能否调度成功
requests 是 Pod 启动前的“准入门槛”。kube-scheduler 会检查节点的 可用可分配资源 是否 ≥ 所有容器 requests 总和。只要任一维度（CPU 或内存）不足，Pod 就卡在 Pending 状态。
- CPU requests 影响 CPU 时间片分配权重：例如 500m 请求对应约 512 个 CPU 份额（基于 1024/核）
- 内存 requests 会被 kubelet 预留，不参与节点内存 overcommit；即使其他 Pod 空闲，这部分内存也不会被抢占
- 建议从应用历史监控（如 Prometheus + cAdvisor）中取 P95 使用峰值，再上浮 10%~20% 作为 requests 基线
limits 控制运行时资源上限
limits 是容器运行中的“安全围栏”，由 kubelet 和底层 cgroups 强制执行：
- CPU limits 触发节流（throttling）：超限时被限速，不会被杀，但响应延迟上升
- 内存 limits 超过即触发 OOM Killer：内核直接终止容器进程，Pod 进入 CrashLoopBackOff
- 避免设置 limits = requests（除非 Guaranteed QoS 必需），否则可能因瞬时毛刺被误杀
- 单位要写对：CPU 用 500m 或 0.5，内存优先用 Mi/Gi（非 MB/GB），1Gi = 1024Mi ≈ 1.07GB
多容器 Pod 的资源配置要点
同一个 Pod 内多个容器共享网络和存储，但资源是独立申请与隔离的：
- 每个容器必须单独定义 resources 字段，不能只在 Pod 级统一设（Pod 级 resources 是 Alpha 特性，1.32+ 实验性支持，生产环境慎用）
- 总 requests 不得超过节点容量，总 limits 可高于节点容量（尤其 CPU），但内存不可 overcommit
- 典型组合：主应用容器设合理 requests/limits，sidecar（如日志采集）设较低 requests + 略高 limits，避免因 sidecar 波动拖垮主服务
验证与调优建议
配置不是一劳永逸，需持续观察与迭代：
- 用
kubectl describe pod <name>查看 Events，Pending 常因 requests 不足，OOMKilled 明确指向 memory limit - 用
kubectl top pods对比实际 usage 与 requests/limits，若 usage 长期低于 requests × 0.5，说明 request 过高；若频繁接近 limits，需扩容或优化代码 - 结合 Horizontal Pod Autoscaler（HPA）按 CPU/memory usage 自动扩缩容，但 HPA 默认只读取 metrics-server 提供的 usage，不感知 limits，所以 limits 仍需人工设稳
