自 Kubernetes 1.8 以来，我似乎需要禁用节点上的交换（或设置--fail-swap-on为false）。
我找不到 Kubernetes 坚持禁用交换的技术原因。这是出于性能原因吗？还是出于安全原因？为什么没有记录这样做的原因？
答案1
kubernetes 的理念是将实例紧密打包，使其利用率尽可能接近 100%。所有部署都应限制 CPU/内存。因此，如果调度程序将 pod 发送到机器，它根本不应该使用交换。您不想交换，因为它会减慢速度。
其主要是为了性能。
答案2
TL;DR 不正确使用交换只是一种懒惰的黑客行为，表明对内存子系统的理解不佳，并且缺乏基本的系统管理技能。设计基础设施服务而不理解这些系统注定会以失败告终。
因此，我对此有一些评论，在我看来，这更像是一种懒惰，而不是一种功能或要求。完全有可能在不触及交换的情况下正确处理交换、分析内存并确定如何正确利用内存子系统。有大量的工具围绕这一点构建，您可以保证进程不会轻易利用交换，因此性能点是不正确的。不加入这种检测只是懒惰的编码，总的来说，完全删除交换将损害系统性能。这里的关键是正确使用它。我同意将 pod 交换到磁盘会影响性能，但是有很多事情应该被换出至磁盘。
此外，Linux 内核设计为使用交换，完全禁用它将产生负面影响。处理此问题的更好方法是将 pod 固定到主内存中，不允许它们交换到磁盘，减少 vfs 缓存压力，以便除非绝对必要，否则不会进行交换，即使这样，如果主内存耗尽，您也可能导致固定进程的 MALLOC 失败。
根据容器中的进程，容器发生硬故障或被 OOM 终止程序终止可能会导致一些相当灾难性的后果。然而，我明白这些容器中运行的进程理想情况下应该是无状态和短暂的，但在运行系统的 20 年里，我从未见过每个人都 100% 地遵循预期的设计。
此外，这还没有考虑到非易失性内存等未来技术，以及英特尔 xpoint 等较新的内存系统，它们可以使用混合磁盘/内存系统显著扩展主内存。有了这些类型的系统，他们可以直接将其用作补充主内存，或利用交换文件扩展主内存，而对性能的影响几乎可以忽略不计。
答案3
据我所知，原因在于 kubelet 不是为处理交换情况而设计的，并且 Kubernetes 团队不打算实现这一点，因为目标是 pod 应该适合主机的内存。
对交换的支持并非易事。有保证的 Pod 永远不需要交换。可突发的 Pod 应该无需交换即可满足其请求。BestEffort Pod 没有保证。kubelet 目前缺乏智能，无法在 Pod 之间提供适当数量的可预测行为。
答案4
有票可以再次启用它，你会在那里获得更多的见解