这个问题目前正在等待分类。
如果SIG或子项目确定这是一个相关的问题，他们将通过应用triage/accepted标签并提供进一步的指导来接受它。
组织成员可以通过在评论中写入/triage accepted来添加triage/accepted标签。
有关使用PR评论与我互动的说明，请查看here。如果您对我的行为有任何问题或建议，请针对kubernetes/test-infra仓库提出一个问题。

这是一个很受欢迎的问题。In place pod update 和交换两者都将其作为支持的一个用例来调用。你对这两个方面有了解吗？

in-place-update 是一个有价值的特性，但它并没有直接解决节点上内存压力的问题。可能未来的增强功能会有所帮助。我的意思是：“Kubelet(或调度器)从节点中驱逐优先级较低的Pod,以便为调整大小腾出空间”。我们需要在每个节点上运行具有较低优先级的此类DaemonSet pods,以阻止一定数量的内存。
尽管“原地更新”+“降低优先级Pod驱逐”似乎与内存缓冲相比整体上更复杂。
交换机与我们关于内存缓冲的提议处于同一方向。然而，我们对引入交换机的风险表示担忧。例如，在系统上启用交换机会降低可预测性。交换机的性能比常规内存差很多，有时相差几个数量级，这可能导致意外的性能回归等问题。

这相当于两级调度 - 首先放置这些"缓冲区",然后将pods放在带有缓冲区的节点上。它将需要额外的cgroup层来在特定的pods(而不是所有pods)之间转移内存，并会影响所有pod资源管理代码和会计逻辑。
还有调度不匹配的风险 - 如果缓冲区落在一个节点上，然后没有pods能够降落在那里怎么办？
TL;DR:这是一个巨大的变化，我认为。虽然我不想完全排除它，但似乎不太可能。
正如@kannon92所说，交换似乎在短期内是一个更好的答案。另一种方法可能是只是调度一个"气球"pod,它请求内存但不使用它。那内存可供所有pods(而不仅仅是这些作业)使用，但这在今天是可行的。
另一个可能的方法可能是使用tmpfs - 我不确定它具体会是什么样子，但关于预先分配内存，pods可以访问的内容。
通常，当我看到像这样的buildfarm应用程序时，有几个作业大小的层级(例如Small、Medium、Large)。首先尝试在Small上编译，如果失败则移动到Medium,然后重复到large。这意味着一些任务运行速度稍慢，但资源利用率最高。

感谢你的详细回答和建议。
我认为最有前景的方法是使用优先级较低的"气球"pod。如果节点上没有足够的可用内存，这个"气球"pod可以被驱逐。它也在未来的增强功能中提到了。
我们需要立即测试是否可以使用具有较低优先级的"气球"pod。它应该可以在Memory QoS功能(有或没有它)的情况下独立工作。

另一个可能有趣的步骤是每个命名空间的cgroup层，所以如果你需要回收内存，你会首先向自己的pods施加压力。但是额外的cgroups有一些微妙的影响，所以在没有充分考虑的情况下，不应该轻易尝试 :)

Kubernetes项目目前缺乏足够的贡献者来充分应对所有问题。
此机器人根据以下规则对未分类的问题进行分级处理：

• 在lifecycle/stale应用后的90天内无活动，将应用lifecycle/stale
• 在lifecycle/stale应用后的30天内无活动，将应用lifecycle/rotten
• 在lifecycle/rotten应用后的30天内无活动，将关闭该问题

您可以：

• 使用/remove-lifecycle stale标记此问题为新鲜
• 使用/close关闭此问题
• 提供帮助，使用Issue Triage

请将反馈发送至sig-contributor-experience@kubernetes/community。
/lifecycle stale

Kubernetes项目目前缺乏足够的活跃贡献者来充分应对所有问题。
此机器人根据以下规则对未分类的问题进行分级处理：

• 在lifecycle/stale应用后的90天内无活动，将应用lifecycle/stale
• 在lifecycle/stale应用后的30天内无活动，将应用lifecycle/rotten
• 在lifecycle/rotten应用后的30天内无活动，将关闭该问题

您可以：

• 使用/remove-lifecycle rotten标记此问题为新鲜
• 使用/close关闭此问题
• 提供帮助，使用Issue Triage

请将反馈发送至sig-contributor-experience@kubernetes/community。
/lifecycle rotten