使用无存储配额的emptyDir卷的Pod将填满此存储，此时会出现以下错误：

eviction manager: attempting to reclaim ephemeral-storage

设置配额limits.ephemeral-storage, requests.ephemeral-storage来限制这一点，否则任何容器都可以向其节点文件系统写入任意数量的存储。
资源配额定义示例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    pods: "4" 
    requests.cpu: "1" 
    requests.memory: 1Gi 
    requests.ephemeral-storage: 2Gi 
    limits.cpu: "2" 
    limits.memory: 2Gi 
    limits.ephemeral-storage: 4Gi

此问题的另一个原因可能是日志文件占用磁盘空间。

出现此问题的原因是在处理（如应用程序处理其作业并存储临时缓存数据）时缺少临时存储。要解决此问题，您必须深入您的Pod，通过命令df-h检查运行哪个设备位置的进程何时占用您的可用存储，并观察可用容量大小。您可以创建一个PVC（使用hostpath或其他方式），该目录具有较大的大小，并安装到存储其临时数据的pod目录中。

我的问题是我的pod正在写入一个没有在部署的volumeMounts中定义的文件夹。

volumeMounts:
  - name: my-data-volume
    mountPath: "/the/path/thatImounted"

我的pod写入到不同于"/the/path/thatImounted"的路径
在这种情况下，解决方案是将Pod写入的路径添加为附加mountPath，或者修复错误的mountPath

如果不设置limits.ephemeral-storage，requests.ephemeral-storage，默认情况下pod有权使用所有节点的存储空间。
因此，您可以设置limits.ephemeral-storage、requests.ephemeral-storage

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "4Gi"

或者，配置Docker日志记录驱动程序以限制存储的日志数量（在文件/etc/docker/daemon.json中，默认情况下此文件不存在，您必须创建它）：

{
"log-driver": "json-file",
"log-opts": {
"max-size": "100m",
"max-file": "2"
}
}

在我的例子中，问题是节点被Docker映像填满了。其中一些映像未使用，从未被修剪，而另一些映像太大了。要确认这一点，首先必须对节点执行ssh命令，然后检查磁盘是否（几乎）满了。例如：

[root@node-name ~]# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p1   20G   15G  5.9G  71% /

可以找出哪个图像占用了最多的空间，我建议这样做。查看这个优秀的资源，看看如何：https://rharshad.com/eks-troubleshooting-disk-pressure/
了解哪个映像占用的空间最大并调查其文件系统以了解原因，对于优化映像大小非常有用，但这是另一个主题。
如果你不能在节点上添加更多的存储空间，可以使用docker prune来清理它。但是在我们需要确保没有容器在运行之前，让我们先清空节点：

kubectl drain node-name

注意，节点在清空后将被封锁，这意味着没有容器将被调度到它。回到节点内部，让我们修剪未使用的Docker资源：

[root@node-name ~]# docker system prune --all
WARNING! This will remove:
  - all stopped containers
  - all networks not used by at least one container
  - all images without at least one container associated to them
  - all build cache

Are you sure you want to continue? [y/N] y
Deleted Containers:
8333683571a2ceff47bf08cc254f8fa3809acacc7fb981be3c1c274e9465dd68
28bdc62425707127ac977d20fd3dc85374ffc54ccccf2b2f2098d9af9ca3c898
7315014bfd9207c5a1b8e76ef0f1567bb5e221de6fe0304f4728218abd7e1f3f
b0f5ecb854a9f4b41610d7ec5b556447600f57529e68ae2093d1d40df02ff214
9e24227321d5e151bc665c55bcd474c9d586857cbac3cad744aad2dc11729e5e
63ab1bf7ded78d4b77db22f9c1aaac6a55247c71ca55b51caa8492f2b16c4d69
...
Total reclaimed space: 4.529GB

然后再次检查存储空间：

[root@node-name ~]# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p1   20G  8.9G   12G  45% /

现在，让我们从主机使用kubectl命令将节点恢复到就绪状态：

rancher kubectl uncordon node-name

您可以增加所连接的EBS卷的大小，然后重新启动EC2示例以达到此效果。

请考虑以下因素：
1.您通过Kubernetes部署的应用程序应在清单文件中设置内存和CPU的限制和请求。
1.根据您的应用程序要求，您应该在Kubernetes集群中配置节点。
1.如果应用程序大量使用所有节点，请增加节点数。