Kubernetes资源限制需requests与limits协同：requests保障调度与保底，limits设硬上限防失控；推荐Burstable配比（如cpu="300m"/"1"、memory="512Mi"/"1.2Gi"），结合QoS分级、IO限流及系统预留提升稳定性。
直接给容器加固定上限，往往治标不治本——高峰一来，硬限制造成请求排队、延迟飙升；限太松又容易挤占其他服务。真正平抑抖动，关键在于让资源限制“能呼吸”：既守住底线，又允许短时弹性突破，再快速收敛。
用 requests + limits 构建弹性基线
这是 Kubernetes 中最基础也最关键的双层保障机制：
- requests 是调度和保底依据，决定 Pod 能否被调度到某节点，也影响 CPU 共享权重和内存 OOM 排序优先级。设得太低，Pod 启不来；太高，造成大量资源闲置
- limits 是硬性天花板，内存超限直接 OOMKilled，CPU 超限则被节流（throttled），但不会终止
- 推荐配比：对智能 Agent 类容器，采用 Burstable QoS 策略，例如
requests: cpu="300m", memory="512Mi"，limits: cpu="1", memory="1.2Gi"。这样既保证启动资源，又允许突发时短暂使用更多 CPU，内存也有缓冲空间
结合实时反馈做动态限流
静态配置无法应对秒级波动。需引入闭环控制：
- 采集容器级指标（如 cAdvisor 提供的
container_cpu_usage_seconds_total、container_memory_usage_bytes） - 当 CPU 使用率连续 30 秒 > 85%，或内存 RSS 持续逼近 limit 的 90%，触发自动调整逻辑
- 可调用
kubectl patch更新 Pod 的resources.limits（需配合 VPA 或自研 Operator），或更轻量地通过 cgroup 接口临时调高cpu.cfs_quota_us（适用于 Docker 场景）
IO 层叠加 throttle 防止磁盘打满拖垮整机
CPU 和内存抖动常由底层 IO 拥塞引发，尤其日志刷盘、批量写入等场景：
- 对非核心任务容器，显式限制其块设备吞吐，例如：
--device-read-bps /dev/sda:5242880 --device-write-bps /dev/sda:10485760（即读 5MB/s、写 10MB/s） - 对核心 API 服务，建议保留更高读带宽（如 20MB/s），但写入严格限制（如 5MB/s），避免后台写放大干扰响应链路
- 生产环境务必定期审计
blkio.throttle.*使用情况，防止某容器长期占满 IO 队列
预留 buffer + 设置 QoS 类别强化稳定性
光靠单容器限制不够，节点层面要留余量：
- 在 kubelet 启动参数中设置
--system-reserved=memory=1Gi,cpu=500m，为系统组件留出资源，避免因主机负载高导致 kubelet 失联 - 将核心 Agent Pod 设置为 Guaranteed 类别（即
requests == limits），确保其获得独占 CPU 时间片和内存保障，不被其他 Burstable 容器抢占 - 配合节点亲和性（
nodeAffinity）把高优先级 Agent 固定在资源较充裕的节点组，减少跨节点争抢
