为什么要在kubernetes(k8s)上禁用swap？

不正确地使用swap只是一个懒的行为，显示出对内存子系统的理解不深，以及缺乏基本的系统管理技能。设计基础设施服务而不了解这些系统，必然会以失败告终。

所以，我对此有一些评论，这在我看来更像是一种懒惰，而不是一种功能或需求。正确处理swap，分析内存，并确定如何在不影响swap的情况下正确利用内存子系统，这是绝对可能的。有一连串的工具围绕着这一点，你可以保证一个进程不会很容易地利用swap，所以性能的观点是错误的。不把这个工具放进去简直是懒惰的行为，而且总的来说，完全去除swap会对系统性能造成损害。这里的关键是正确使用它。我同意把pods换到磁盘上会影响性能，但是有很多东西应该被换到磁盘上。

此外，Linux内核的设计是为了利用swap，完全禁用它将会产生负面的影响。一个更好的处理方法是将pods固定在主内存中，不允许它们交换到磁盘，减少vfs缓存的压力，使它不交换，除非是绝对必要的，即使这样，你也可以使固定的进程在主内存耗尽的情况下不能MALLOC。

取决于容器中的进程，如果容器发生硬故障或被OOM杀手杀死，可能会导致一些相当灾难性的结果。然而，我知道在这些容器中运行的进程最好是无状态的和短暂的，但是在20年的系统运行中，我还没有看到每个人都100%地遵循预定的设计。

此外，这还没有考虑到未来的技术，如非易失性内存，以及较新的内存系统，如intel xpoint，可以使用混合磁盘/内存系统大大扩展主内存。有了这些类型的系统，他们可以直接将其作为补充主内存使用，或者利用交换文件来扩展主内存，对性能的影响可以忽略不计。

kubernetes 的想法是将实例紧密打包以尽可能接近100%的利用率。 所有的部署都应固定CPU/内存限制。因此，如果调度程序将 pod 发送到一台节点机器上，它根本不应该使用swap，因为它会减慢速度。

它主要是为了性能。

这样做的原因是 kubelet 不是为处理swap情况而设计的，Kubernetes 团队不打算实现这一点，因为目标是 pod 应该适合主机的内存。

来自：GitHub issue #53533

对swap的支持非常重要。 有保证的 pod 永远不需要交换。 Burstable pod 应该在不需要交换的情况下满足他们的请求。 BestEffort Pod 无法保证。 kubelet 现在缺乏智能来在 pod 中提供适量的可预测行为。

https://github.com/kubernetes/kubernetes/issues/53533