背景
为了可以更好的管理我们的lnmp集群，打算将原有的php环境整体打包成一个镜像然后上到k8s容器，这样可以不仅使用到k8s的快速扩缩容和管理的好处，而且让机器资源能更好被利用，减少机器数量
问题
当我们将流量从原有的php机器集群切换到k8s集群时，发现php容器的虚拟内存一直再涨，然后达到一个阈值之后就会开始回落，然后又继续上涨，表现如下
原因
一开始我们还以为内存泄露了，不过内存泄露的话，内存使用率只会一直往上涨，这里有回落，说明大概率不是内存泄露
而经验老到的运维说这很有可能是因为PHP程序写日志到所在pod上，而根据linux系统的特性，写文件不会立马落盘，而是先写到本地缓存里，等达到一定量级之后才会落盘，这也就解释为什么虚拟内存会一直上涨，然后又会回落，最后就是这么反反复复
实验
在测试机写一个php接口，这个接口的功能就是写大量的日志数据，然后使用 ab来对这个接口进行压测，结果如下
确实会涨，这说明写日志确实会导致内存使用率的上涨
内存使用过程是如何的
既然知道这个问题的根源，那接下来简单讲讲这个内存使用过程是怎么导致会出现这个情况
首先先要知道
WSS（Working Set Size）和 RSS（Resident Set Size）是内存管理中两个相关但不同的概念。
WSS指的是当前进程正在使用的内存，包括其虚拟地址空间中已分配但未被使用的内存，以及已经被使用的内存页。换句话说，WSS是当前进程使用的活动内存。
而RSS则指的是当前进程使用的物理内存，也就是占用了进程物理内存的内存页数。RSS是用来衡量进程实际使用的物理内存大小。
因此，WSS通常比RSS要大。这是因为WSS包括了未使用但已分配的内存和已使用的内存，而RSS只包括已经占用了物理内存的内存页。
另外，WSS也会受到操作系统内存管理机制的影响，如内存页面换入换出机制等。在这些机制的调度下，可能会导致某些已使用但未活动的内存页被移出物理内存，从而导致WSS的变化。
而linux自身会有个文件缓存，主要作用是用来防止程序对文件的频繁操作从而导致对加大对磁盘的读写，先将文件存入缓存，等到合适时机再将文件写入到磁盘里
衍生问题
从上面可以看出，k8s的pod运行了linux系统，而如果多个pod对同一个文件进行读写，会不会导致这个文件数据不一致呢
这个问题k8s主要是使用Kubernetes Volume 的方案来保证数据的一致性，多个pod挂载了同一个存储卷
从逻辑上pod本身的文件缓存是有可能导致文件的不一致，不过这一点借助强大亚马逊云提供的EKS集群很好的解决了这个问题，不过具体怎么解决确实难懂，这里就不再进行赘述了
