Kubernetes kube-reserved 配置误区：预留不足 vs 过度预留，如何平衡资源安全与业务弹性？

【背景】 K8s 节点的 kube-reserved/system-reserved 机制本意是为系统守护进程（如 kubelet）预留资源，防止因业务 Pod 占用过多导致节点不可用。但实际运维中常出现两极分化：

【常见分歧】

1. 预留不足派：认为 kube-reserved 只需覆盖基础运行时（CPU 200m + 内存 512Mi），过度预留会挤压业务资源
2. 预留充足派：主张按 1.5x 节点总资源预设，避免因突发流量导致驱逐

【两种典型做法】

• 动态调整策略：通过 nodeResourcesReservation 与 metrics-server 实时感知负载
• 硬性阈值：设置 kube-reserved=50% 节点资源，配合 evict-threshold=80% 防御

【我的倾向】 更倾向动态策略，但需要配合：

1. Prometheus 监控 kubelet 资源占用曲线
2. 节点标签区分业务类型（如 db-node vs api-node）
3. 驱逐时优先回收非核心业务 Pod

【想听你的经验】 你在实际场景中如何配置 kube-reserved？遇到过哪些典型陷阱？

• 是否遇到过「预留充足却仍触发驱逐」的反直觉案例？
• 如何在资源利用率与系统稳定性间找到最优解？