K8s 节点 kube-reserved/system-reserved 驱逐业务 Pod：如何精准计算不触发驱逐？

【背景】 在 Kubernetes 集群中，kube-reserved 和 system-reserved 机制是为了确保系统组件和 kubelet 能够获得足够的资源，防止因资源不足导致的驱逐。但这也带来了一个问题：如何在业务 Pod 的资源请求和限制中，精准计算以避免被驱逐。

【常见分歧或几种做法】

1. 保守估算：一些团队倾向于将 kube-reserved 设置为 CPU 和内存的 10%~20%，并为业务 Pod 设置较高的资源请求和限制，以确保不被驱逐。
2. 动态调整：部分团队采用动态资源监控工具，实时调整 kube-reserved 和业务 Pod 的资源请求，以适应负载变化。
3. 基于历史数据：一些团队会分析历史负载数据，计算出业务 Pod 的平均资源使用情况，以此来设定资源请求和限制。

【我的倾向与理由】 我认为，动态调整和基于历史数据的方法更为可取。因为它们能更好地适应实际负载变化，避免资源浪费和过紧的限制。动态调整可以通过监控工具如 Prometheus 和 Kubernetes 的 Horizontal Pod Autoscaler (HPA) 来实现。

【想听大家在什么场景下怎么选】

• 在资源紧张的生产环境，如何平衡 kube-reserved 和业务 Pod 的资源请求？
• 在高并发场景下，如何避免因资源不足导致的驱逐？
• 是否有成功案例可以分享？