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

【背景】

Kubernetes 在资源管理中引入了 kube-reserved 和 system-reserved 的机制，用来确保节点上系统和 kubelet 的运行不会被驱逐。但在实际操作中，如何精准计算业务 Pod 的资源请求和限制，以避免被驱逐，是很多团队面临的一个挑战。

【常见分歧】

1. 保守 vs 乐观：

   • 保守派倾向于为 kube-reserved 和 system-reserved 预留更多资源，以确保系统稳定性。
   • 乐观派则认为可以动态调整，减少资源预留，以提升利用率。

2. 硬性限制 vs 动态调整：

   • 一些团队倾向于设置硬性限制，以确保资源不被过度消耗。
   • 另一些团队则采用动态调整策略，根据负载情况进行资源分配。

【我的倾向与理由】

我认为，精准计算不触发驱逐的关键在于资源预留与动态调整的结合。

• 资源预留： 确保 kube-reserved 和 system-reserved 的预留资源足够，以防止系统组件被驱逐。

• 动态调整： 根据实际负载情况，动态调整业务 Pod 的资源请求和限制，以提升资源利用率。

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

• 在哪些场景下你会选择保守策略？
• 在哪些场景下你会选择动态调整策略？
• 你们是如何在资源预留和动态调整之间找到平衡点的？