资源调度

【背景】 在K8s集群中，kube-reserved用于为关键系统组件（如kubelet）预留资源，而HPA（Horizontal Pod Autoscaler）负责根据负载自动扩展Pod数量。但二者存在天然矛盾： - kube-reser

【背景】 在 K8s 集群中，kube-reserved 机制用于保障系统关键组件（如 kubelet）的资源隔离，但其静态阈值设计常导致资源利用率与业务需求的矛盾。 【常见分歧】 1. 硬性预留：预留固定比例（如 20% CPU/内存），

【背景】 K8s中kube-reserved作为资源预留机制，本质是为系统组件（如kubelet、docker）保留核心资源，防止OOM导致集群不可用。但实际落地时，常面临两个矛盾： 1. 预留过多→业务Pod抢不到资源，HPA频繁触发扩缩

【背景】 Kube-reserved预留不足导致Pod驱逐的根因分析中，发现传统静态阈值（如CPU 20%、内存50%）在业务波动场景下频繁触发OOM Killer，而动态计算方案（如基于历史负载的滑动窗口）又存在实现复杂度高、实时性差的问

【背景】 K8s的kube-reserved机制本意是为系统CPU/内存预留资源防止OOM/Kubelet驱逐，但实际落地时普遍遇到两个矛盾： 1. 预留比例越高，业务可用资源越少，但预留不足又可能触发驱逐 2. 静态预留无法应对突发流量，

【背景】 做了 5 年云原生运维，我们集群 K8s 1.28 + containerd，300+ 工作负载，一半是 Java 服务（JDK17，G1），一半 Go。最近做容量成本盘点时发现一个尴尬的事实：全集群只有不到 30% 的 Pod

【背景】 我维护一个 40+ 业务 Pod 的自建 K8s 集群（1.28，cgroup v2，节点 16C64G，业务与批处理混部比例约 7:3）。去年我们做过一次「全量 Guaranteed」改造：把所有生产服务的 requests 对

先抛结论（我目前的倾向，欢迎打脸）：对绝大多数有状态、长生命周期的后端服务，limit 应该设；对批处理、Spark、ML 训练这类任务型负载，limit 不该设，甚至应该用 Burstable + request 兜底。但社区里这三种流派