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

【背景】

Kubernetes 节点中，kube-reserved 和 system-reserved 是为系统和 kubelet 预留资源的机制，确保节点的稳定运行。然而，这些资源的预留可能会导致业务 Pod 被驱逐，尤其是在资源紧张时。

【常见分歧】

1. 是否应该完全禁用 kube-reserved 和 system-reserved：有些人认为这些机制可能对业务造成干扰，因此建议禁用。

2. 如何精确计算预留资源：部分团队采用固定值（如 CPU 10%、内存 10%）来预留资源，而另一些团队则根据实际负载动态调整。

3. 是否需要监控和调整资源预留策略：一些团队认为需要实时监控资源使用情况并进行动态调整，而另一些团队则认为静态预留更简单可靠。

【我的倾向与理由】

我倾向于动态调整 kube-reserved 和 system-reserved 的资源预留策略。原因如下：

• 灵活性：动态调整可以更好地适应业务负载的变化，避免资源浪费或不足。

• 稳定性：通过监控节点资源使用情况，可以更准确地预测和预留资源，减少业务 Pod 被驱逐的风险。

• 可维护性：动态调整策略可以通过自动化工具实现，减少人工干预，提高维护效率。

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

• 你们在什么场景下选择固定值预留资源？
• 你们如何监控和调整 kube-reserved 和 system-reserved 的资源预留策略？
• 你们有没有遇到过因为资源预留策略不当导致的业务 Pod 被驱逐的问题？

【标签】 Kubernetes、资源预留、Pod 驱逐、系统稳定性、SRE 【分类】 Kubernetes