混合宿主机资源争抢死锁源于Requests/Limits与真实负载、硬件异构性、内核调度错配，需通过观测（7天P95/P50画像）、约束（NodeLabel+LimitRange差异化）、适配（CPU限差≤20%、内存limit≥1.8×requests且swappiness=1）三层调优，并引入sidecar+Prometheus反馈闭环实现动态治理。
在混合物理宿主机环境中，资源争抢死锁常表现为：部分节点 CPU 长期 90%+ 但 Pod 调度失败，另一些节点内存空闲却无法接纳新 Pod；或某 Pod 因瞬时内存峰值被 OOMKilled，触发级联驱逐，进而加剧调度压力。这本质是 Requests/Limits 与真实负载、硬件异构性、内核调度行为三者错配所致。调优需从观测、约束、适配三个层面切入，而非简单放大数值。
基于真实负载画像做分层资源建模
混合宿主机（如混用 Intel Xeon 与 AMD EPYC、不同代内存带宽）意味着“相同 requests 值”在不同节点上实际保障能力差异显著。不能统一按平均值设配额。
- 用 kubectl top pods --containers 和 metrics-server 拉取至少 7 天的分钟级数据，重点看 P95 内存峰值和 CPU 持续 >80% 的时长占比
- 对每类应用打标：例如 stateful-db（内存敏感、突发强）、api-gateway（CPU 密集、内存平稳）、batch-job（短时高载、可容忍节流）
- 按标签分组计算：requests 取 P50 使用量 × 1.2（留缓冲），limits 取 P95 峰值 × 1.15（防毛刺），但 memory limits 必须 ≤ 节点可用内存的 70%，避免触发节点级 OOM
用 LimitRange + NodeSelector 实现硬件感知约束
单纯靠 Deployment YAML 手动配，无法应对宿主机型号、NUMA 节点、内存通道数等底层差异。需将硬件特征转化为调度策略。
- 为不同硬件池打 NodeLabel：如 hardware.arch=amd、hardware.memory-bandwidth=high
- 在对应命名空间部署差异化 LimitRange：AMD 节点池的默认 memory limit 设为 1.5× Intel 池，因 AMD 内存延迟更高，需更大缓冲
- 关键服务 Pod 显式声明 nodeSelector + resources，例如数据库 Pod 强制调度到 hardware.memory-bandwidth=high 节点，并设置 memory requests=1Gi, limits=1.8Gi（留 800Mi 应对 page cache 波动）
规避 CPU 节流与内存回收的协同死锁
死锁常见于：CPU 密集型 Pod 达到 limits 被 throttled → 处理请求变慢 → 请求堆积 → 内存缓存膨胀 → 触发 cgroup memory.high 回收 → GC 加剧 CPU 占用 → 进入恶性循环。
- CPU 配置原则：requests 与 limits 差值控制在 20% 以内（如 requests: 400m, limits: 480m），避免节流突降导致响应雪崩
- 内存配置原则：对使用 mmap 或大量 page cache 的服务（如 Elasticsearch、Redis），limits 必须 ≥ requests × 1.8，且开启 memory.swappiness=1（通过 securityContext 设置），抑制内核过早 swap
- 禁用无意义的 “requests=0” 或 “limits 不设”，这类 Pod 在压力下会抢占所有空闲 CPU 时间片，成为隐性死锁源
引入轻量级运行时反馈闭环
静态配置无法覆盖业务增长、版本迭代带来的负载漂移。需建立低开销反馈机制。
- 在 Pod 中注入 sidecar（如 resource-exporter），每 30 秒上报 /sys/fs/cgroup/cpu.stat 中 throttled_time 和 /sys/fs/cgroup/memory.stat 中 oom_kill
- 用 Prometheus Rule 监控：若某 Deployment 连续 5 分钟 throttled_time > 1s/min 或 oom_kill > 0，则触发告警并自动 patch resources（通过 Argo Rollouts 或自定义 Operator）
- 对 batch 类任务，直接使用 Job.spec.activeDeadlineSeconds + backoffLimit=1，避免失败 Pod 持续重试加剧争抢
