Kubelet在NFS持久卷中缓存文件的本地副本

如何解决Kubelet在NFS持久卷中缓存文件的本地副本

我们在裸机Linux集群上使用Docker 19.03.12运行kubelet 1.18.3。今天我们注意到，我们有很多Pod逐出，可追溯到节点上的磁盘空间压力。对于该特定节点，我们已经超过了保存Docker nodefs的文件系统的80％阈值。

但罪魁祸首在/var/lib/kubelet/pods/{{pod-uid}}/volumes/kubernetes.io~nfs/{{pv}}中。经过检查，该目录保存了一个副本。 （缓存???）由Pod通过PersistentVolumeClaim挂载ReadOnlyMany的NFS持久卷。该Pod最终基于Debian Stretch和OpenJDK。如果执行到Pod中，我们将看到PV的nfs挂载点：

server:/export-path on /local-volume type nfs4 (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=nn.nn.nn.nn,local_lock=none,addr=nn.nn.nn.nn)

但是，docker inspect -f '{{.Mounts}}' container-id还将挂载点/local-volume显示为绑定到/ var / lib / kubelet / pods / {{pod-uid}} / volumes / kubernetes.io〜nfs / { {pv}}

有两个问题：

1. AFAIK，nfsv4客户端不会在已安装的文件系统中缓存文件，那么这些副本来自何处？
2. 是否可以管理此本地缓存？外部PV非常大，我们不需要将其作为本地卷缓存在Pod中。

解决方法

我应该更深入地研究主机的mtab。 Kubelet将pod的持久卷声明绑定绑定到/var/lib/kubelet/pods/{{pod-uid}}/volumes/kubernetes.io~nfs/{{pv}}中，因此容器的持久卷出现在主机的文件系统中。

教训。搜寻大量磁盘空间违规者时，请使用du -x -h -s * | sort -h，以免被（nfs）挂载点分散注意力。