[imageGCManager]: Disk usage on image filesystem is at 91% which is over the high threshold (85%)

    我们在操作k8s集群的dockers镜像时，发现在本地做好一个镜像，不论容量大小，隔一段时间就会诡异的消失了，可能隔几分钟或者几个小时，太奇怪了，难道有人“黑”进服务器了？但是也不至于大费周章的删除些镜像吧？

使用命令“systemctl status kubelet” 或“journalctl -xeu kubelet”可以查看K8S集群的服务状态

使用命令“systemctl status docker”可以查看Docker服务的状态信息；

image_gc_manager.go:300] [imageGCManager]: Disk usage on image filesystem is at 91% which is over the high threshold (85%). Trying to free 11133159833 bytes down to the low threshold (80%). 

    起初还以为是dockers在安装的时候配置或者挂在的容量有些小了，但是也没找到到底是哪里配置的，dockers镜像可以push到远程仓库，暂时不影响项目的使用，所以问题就暂时搁置了。。。

    前两天在查看K8s集群的时候，同事发来截图说，看看这个啥错误？

    字面意思是这个域名没办法好好解析呗？？？赶紧将域名换成内网IP，就正常了，但是K8S著名的网络管理难道就这样不能用了？这也太不可靠了了吧，赶紧看看是不是内部的域名解析服务出问题啦？

    kubectl get pod -n kube-system;

   发现三个control节点的第一个节点control1节点的coredns和kube-proxy的pod是Pending状态的，查看这个Pod的具体情况，显示的是因为所在的节点的磁盘空间不足了，导致coredns和kube-proxy都被kill了，那内部的域名解析功能当然就没办法使用了；   

    这个问题会不会跟之前docker images呗莫名其妙的清理掉有关系呢，既然是磁盘空间不够，最快的办法就是将服务器目录下的大文件清理下试试。删除了之前安装测试的压缩包，共10多个G，等了一会后，将Pending的两个Pod直接delete掉，自动拉起两个新的Pod，观察一会儿后，状态一直是Running。。。

    回头去查看docker服务的信息的时候，惊喜的发现，之前image GC的日志报错竟然也没有了，果然也是因为磁盘空间不够了，导致的问题；

    当时安装k8s的时候，想着control节点只是做k8s的调度，不需要太大的磁盘，就分配了100G，但是慢慢的制作镜像上传文件和程序包的同时，并没有及时的清理不用的文件，导致磁盘慢慢吃紧了。而且团队使用的时候，都是习惯性的在control1节点上操作测试，不知不觉中control1节点的压力竟然越来越大了，最终导致了这次的问题。。。