自从我们的kubernetes集群部署到生产环境后，将流量从原有的服务器上切过来之后，部分节点出现挂载目录容量爆满的情况。
运维的同事报给我们之后，我们首先想到的是节点镜像过多，于是我们提供一个命令用于清理当前节点上无用的、报错的、镜像和docker资源文件
docker system prune 命令可以用于清理磁盘，删除关闭的容器、无用的数据卷和网络，以及dangling镜像(即无tag的镜像)
docker system prune -a 命令清理得更加彻底，可以将没有容器使用Docker镜像都删掉。
待运维执行之后，目录存储资源释放了一些，我们本以为这就告一段落了。然而，事与愿违，没过多久，再次容量报警。。。
我们开始重视起来，开始检视节点上工作的容器，发现在日志爆炸的节点上运行了定时任务，开发人员将定时任务的日志输出到控制台，于是我们回到节点docker的工作目录，通过du -sh *方式查看每个文件夹大小，发现docker目录下containers目录占用空间巨大，进去看原来是每个运行的容器存放日志的目录，我们找出占用空间最大的日志目录，发现容器日志特别的大
我们可使用如下命令查看各个日志的文件大小
ls -lh $(find /var/lib/docker/containers/ -name *-json.log)
那我们如何清理日志呢，如果docker容器正在运行，那么使用rm -rf 方式删除日志后，通过df -h会发现磁盘空间并没有释放
原因：在Linux或者Unix系统中，通过rm或者文件管理器删除文件将会从文件系统的目录结构上解除链接(unlink).然而如果文件是被打开的（有一个进程正在使用），那么进程将仍然可以读取该文件，磁盘空间也一直被占用
我们通过cat /dev/null > *-json.log来清理相应的日志，然后重启
systemctl daemon-reload
systemctl restart docker
然而，我思考，不能每次满的时候找运维清理日志啊，这多麻烦，难道docker没有相应的机制应付输出到控制台的日志吗？答案是：当然不会
在新版的docker中我们可以通过设置vim /etc/docker/daemon.json 来限制docker的日志量
"log-driver":"json-file","log-opts":{ "max-size" :"200m","max-file":"5"}
顾名思义max-size就是每个日志文件大小，max-file是最多生成的文件数，如上我设置成功后，每个容器运行的日志最多有五份每份200M大小，这样就基本限制了容器的日志大小。
然后你觉得结束了吗？？并不！！
容器日志我们是限制完了，本以为高枕无忧，不用担心出现日志爆满的情况了，但是事与愿违，过几天硬盘容量又满了。。。
我们究其原因，发现在docker的运行目录下overlay这个文件夹里存放着所有的容器挂载目录，也就是容器的系统文件在这里放着，在容器中跑着的服务产生日志很可能并不是输出到控制台，而是保存到本地，容器内的日志文件也是会占用磁盘空间的，这就让我们犯愁了，这个不好限制开发团队不存日志或者规定团队存放目录啊，对于一个成熟的容器平台来说，海纳百川那是必须的~
于是我们打起了kubelet的主意
在k8s中文社区中有详细的限制方法 那具体做法呢，其实就是为节点加上驱逐策略，当cpu或者内存或者硬盘空间不满足要求时，自动驱逐一些消耗资源大的容器，保证节点稳定性。
里面主要是有以下几个关键驱逐信号
上面的每个信号都支持整数值或者百分比。百分比的分母部分就是各个信号的总量。kubelet 支持两种文件系统分区。
nodefs：保存 kubelet 的卷和守护进程日志等。
imagefs：在容器运行时，用于保存镜像以及可写入层。
imagefs 是可选的。Kubelet 能够利用 cAdvisor 自动发现这些文件系统。Kubelet 不关注其他的文件系统。所有其他类型的配置，例如保存在独立文件系统的卷和日志，都不被支持。
因为磁盘压力已经被驱逐策略接管，因此未来将会停止对现有 垃圾收集 方式的支持。
具体的内容大家可以详细去看看社区里的介绍，我这里就不再赘述了，我这边献上我的驱逐方案~
执行vim /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
在里面插入
Environment="KUBELET_OTHER_ARGS=
--eviction-hard=memory.available<2Gi,nodefs.available<5Gi,imagefs.available<5Gi
--eviction-minimum-reclaim=memory.available=500Mi,nodefs.available=5Gi,imagefs.available=5Gi
--node-status-update-frequency=10s
--eviction-pressure-transition-period=30s"
解读：内存小于2G驱逐，root目录磁盘空间小于5G驱逐，镜像目录磁盘空间小于5G驱逐，节点检测为每10秒一次，在跳出压力状态之前要等待的时间为30秒。
在某些场景下，驱逐 Pod 可能只回收了很少的资源。这就导致了 kubelet 反复触发驱逐阈值。另外回收资源例如磁盘资源，是需要消耗时间的。
要缓和这种状况，Kubelet 能够对每种资源定义 minimum-reclaim。kubelet 一旦发现了资源压力，就会试着回收至少 minimum-reclaim 的资源，使得资源消耗量回到期望范围。
也就是说当内存触发驱逐时，kubelet至少要让内存有2.5G，当root和镜像磁盘空间发生驱逐时，kubelet至少要让磁盘有10G的空间。
那驱逐的规则是什么呢，对什么样的容器做驱逐呢？这个我们下回分解哈。
那总的来说，若要解决节点镜像存储报警，我们可以从三个方面入手
1.容器：通过docker限制容器日志大小
2.k8s：通过kubelet来驱逐过大的容器
3.跟开发人员沟通，精简容器，不让内存泄漏，不随意使用资源（很难啦~~~）
祝各位新春快乐~