自从Kubernetes 1.8
以来,我似乎每次都需要在我的节点上禁用swap交换空间(或将--fail-swap-on
设置为false
)。
我找不到Kubernetes(k8s)社区坚持禁用swap交换的技术原因,这是由于性能原因吗?安全原因?为什么文档里没有这个原因?
自从Kubernetes 1.8
以来,我似乎每次都需要在我的节点上禁用swap交换空间(或将--fail-swap-on
设置为false
)。
我找不到Kubernetes(k8s)社区坚持禁用swap交换的技术原因,这是由于性能原因吗?安全原因?为什么文档里没有这个原因?
不正确地使用swap只是一个懒的行为,显示出对内存子系统的理解不深,以及缺乏基本的系统管理技能。设计基础设施服务而不了解这些系统,必然会以失败告终。
所以,我对此有一些评论,这在我看来更像是一种懒惰,而不是一种功能或需求。正确处理swap,分析内存,并确定如何在不影响swap的情况下正确利用内存子系统,这是绝对可能的。有一连串的工具围绕着这一点,你可以保证一个进程不会很容易地利用swap,所以性能的观点是错误的。不把这个工具放进去简直是懒惰的行为,而且总的来说,完全去除swap会对系统性能造成损害。这里的关键是正确使用它。我同意把pods换到磁盘上会影响性能,但是有很多东西应该被换到磁盘上。
此外,Linux内核的设计是为了利用swap,完全禁用它将会产生负面的影响。一个更好的处理方法是将pods固定在主内存中,不允许它们交换到磁盘,减少
vfs
缓存的压力,使它不交换,除非是绝对必要的,即使这样,你也可以使固定的进程在主内存耗尽的情况下不能MALLOC。取决于容器中的进程,如果容器发生硬故障或被OOM杀手杀死,可能会导致一些相当灾难性的结果。然而,我知道在这些容器中运行的进程最好是无状态的和短暂的,但是在20年的系统运行中,我还没有看到每个人都100%地遵循预定的设计。
此外,这还没有考虑到未来的技术,如非易失性内存,以及较新的内存系统,如intel xpoint,可以使用混合磁盘/内存系统大大扩展主内存。有了这些类型的系统,他们可以直接将其作为补充主内存使用,或者利用交换文件来扩展主内存,对性能的影响可以忽略不计。
你的答案