0

我有一个带有 2 个 PV 的本地集群

1 对于 20Gb 的 mysql 转储

1 对于大约 10Gb 的 Mongo db

一堆不同的服务，主要是大约 400Mb 或更少的图像，以及 1 个 2.1Gb 图像的遗留。

我正在运行 Skaffold + Minikube + VirtualBox

我从 mysql 收到以下错误：

2020-06-09T12:49:49.854701Z 0 [ERROR] InnoDB: Write to file ./ibtmp1failed at offset 0, 1048576 bytes should have been written, only 0 were written. Operating system error number 28. Check that your OS and file system support files of this size. Check also that the disk is not full or a disk quota exceeded.
2020-06-09T12:49:49.854724Z 0 [ERROR] InnoDB: Error number 28 means 'No space left on device'

然后我开始查看当前的系统内存，如下：

minikube ssh "free -mh"

我得到以下信息：

-------------total        used        free      shared  buff/cache   available
Mem:          7.8Gi       2.3Gi       2.4Gi       517Mi       3.1Gi       5.3Gi

我运行以下命令：

minikube ssh "df -h"

我得到以下信息：

Filesystem      Size  Used Avail Use% Mounted on
tmpfs           7.1G  493M  6.6G   7% /
devtmpfs        3.9G     0  3.9G   0% /dev
tmpfs           3.9G     0  3.9G   0% /dev/shm
tmpfs           3.9G   26M  3.9G   1% /run
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
tmpfs           3.9G   12K  3.9G   1% /tmp
/dev/sda1        70G   69G     0 100% /mnt/sda1
/Users          234G  190G   44G  82% /Users

我看到这/mnt/sda1可能是主要问题，但我无法追踪 sda1 是如何填充的。我怎样才能看到内容 /dev/sda1 以及填充此设备的可能有罪进程？

我还执行了以下命令：

docker image prune删除未使用的图像 docker volume prune删除未使用的卷

考虑到带有清理的文档，我还运行 skaffold： skaffoold -f="file-skaffold-config" --no-prune=false --cache-artifacts=false

docker rmi -f [IMAGE_ID]按 ID 删除特定图像并查看删除此图像是否最终会释放 /dev/sda1 中的一些空间

但是我的 sda1 看不到更好的情况，这意味着它minikube ssh "df -h"显示的结果与以前完全相同。

我如何使用 minikube / skaffold / docker 查看正在填充的内容/dev/sda1？

4

1 回答 1

0

在向 github 存储库询问有关 minikube 空间消耗的一些建议后：

https://github.com/kubernetes/minikube/issues/8422

有人向我指出太空雷达：

https://github.com/zz85/space-radar/tree/v5.1.0

我将能够提供进一步的见解并确保产生这种磁盘使用的原因......通过更改我在本地运行的图像中的某些内容很有可能会解决此问题，一旦我知道有什么，我会更新这个答案发生。

[更新]

最后，通过评估我的机器相对于他的机器的磁盘消耗，我能够更仔细地查看我的同事的 minikube 问题。正如 mWatney 在评论中指出的那样，我做到了：

$ minikube ssh "sudo du -sh /mnt/sda1/*"
17G /mnt/sda1/data
4.0K    /mnt/sda1/hostpath-provisioner
4.0K    /mnt/sda1/hostpath_pv
16K /mnt/sda1/lost+found
46G /mnt/sda1/var

但是我同事的那个有：

34G /mnt/sda1/data
4.0K    /mnt/sda1/hostpath-provisioner
4.0K    /mnt/sda1/hostpath_pv
16K /mnt/sda1/lost+found
36G /mnt/sda1/var

这意味着他的 Persistent Volumes 有问题，并且在过去对他的机器进行修复后，他错误地在 minikube 主机路径 PV 中进行了备份，所以现在它工作正常。

于 2020-06-09T15:58:38.670 回答