部署Kubernetes(k8s)时，为什么要关闭swap、selinux、firewall 防火墙？

关于防火墙的原因（nftables后端兼容性问题，产生重复的防火墙规则）

The ip tables tooling can act as a compatibility layer, behaving like iptables but actually configuring nftables. This nftables backend is not compatible with the current kubeadm packages: it causes duplicated firewall rules and breakskube-proxy

大概意思就是 nftables 与 kubeadm 不兼容:它会导致重复的防火墙规则和breakskube-proxy

关于selinux的原因（关闭selinux以允许容器访问宿主机的文件系统） selinux 是什么？是 Linux® 上最杰出的新安全子系统。NSA是在Linux社区的帮助下开发了一种访问控制体系，在这种访问控制体系的限制下，进程只能访问那些在他的任务中所需要文件。

那为什么要关闭这个很好的功能呢？

Setting SELinux in permissive mode by running setenforce 0 and sed ...effectively disables it. This is required to allow containers to access the host filesystem, which is needed by pod networks for example. You have to do this until SELinux support is improved in the kubele

因为有些时候容器需要访问宿主机器去实现一些功能，比如pod 的网络需要方位宿主文件进行实现，所以没办法咯。

关闭swap 的原因 首先我们确认下 swap是干嘛的？ 在Linux下，SWAP的作用类似Windows系统下的“虚拟内存”。当物理内存不足时，拿出部分硬盘空间当SWAP分区（虚拟成内存）使用，从而解决内存容量不足的情况。

SWAP意思是交换，顾名思义，当某进程向OS请求内存发现不足时，OS会把内存中暂时不用的数据交换出去，放在SWAP分区中，这个过程称为SWAP OUT。当某进程又需要这些数据且OS发现还有空闲物理内存时，又会把SWAP分区中的数据交换回物理内存中，这个过程称为SWAP IN。

当然，swap大小是有上限的，一旦swap使用完，操作系统会触发OOM-Killer机制，把消耗内存最多的进程kill掉以释放内存。

当然这种交换肯定是以牺牲性能作为代价来保证程序的运行，如果你的磁盘是机械硬盘，那么恭喜你，速度更慢了。。

那么我们来看下k8s中，swap对它的影响呢？

Swap会导致docker的运行不正常，性能下降，是个bug，但是后来关闭swap就解决了，就变成了通用方案。

对于我们部署在k8s中的应用或者运行在k8s上的工作服务，看到一个别人很好的举例：

在计算集群（请注意计算集群这四个字的含义，这种集群主要运行一些生存周期短暂的计算应用，申请大量内存-动用大量CPU-完成计算-输出结果-退出，而不是运行诸如mysql之类的服务型程序）中，我们通常希望OOM的时候直接杀掉进程，向运维或者作业提交者报错提示，并且执行故障转移，把进程在其他节点上重启起来。而不是用swap续命，导致节点hang住，集群性能大幅下降，并且运维还得不到报错提示。更可怕的是有一些集群的swap位于机械硬盘阵列上，大量动用swap基本可以等同于死机，你甚至连root都登录不上，不用提杀掉问题进程了。往往结局就是硬重启。

节点hang住是非常恶劣的情况，往往发现问题的时候，已经造成了大量损失。而程序出错可以自动重试，重试还OOM说明出现了预料之外的情况（比如程序bug或是预料之外的输入、输入文件大小远超预期等问题），这种时候就应该放弃这个作业等待人员处理，而不是不停地尝试着执行它们，从而导致后面的其他作业全部完蛋。

所以计算集群通常都是关闭swap的，除非你十分明确swap可以给你的应用带来收益。

计算集群和诸如执行mysql的集群有一个根本不同就是计算集群不在意单个进程、单个作业的失败（由于面向的用户很宽泛，这些作业所执行的程序很可能未经严格的测试，它们客观上出问题的几率远高于mysql等成熟的程序），但是绝对不接受hang住引起整个集群无法处理任何作业，这是非常严重的事故。

上诉描述中主要还是结合了实际的使用场景，一般k8s服务部署的大部分都属于允许OOM时候直接将服务杀掉的应用。对于像mysql的服务，在实际生产中从性能稳定性多方面考虑上应该都选用物理机部署。