Docker Google Kubernetes引擎上是否可能有短暂的磁盘pod存储？

我希望pod中的容器为临时（缓存）数据共享一个卷。我不介意pod终止时数据是否丢失（事实上，我希望删除数据并回收空间）

使

emptyDir

听起来像我想要的：

emptyDir卷是在Pod分配给节点时首先创建的，只要该Pod在该节点上运行，该卷就存在

。。及

默认情况下，emptyDir卷存储在支持节点的任何介质上—可能是磁盘、SSD或网络存储，具体取决于您的环境。但是，您可以将emptyDir.medium字段设置为“Memory”，让Kubernetes为您安装一个tmpfs（RAM支持的文件系统）

这听起来像默认行为是将卷存储在磁盘上，除非我在内存中显式请求

但是，如果我在GKE集群上创建以下pod：

apiVersion: v1
kind: Pod
metadata:
  name: alpine
spec:
  containers:
  - name: alpine
    image: alpine:3.7
    command: ["/bin/sh", "-c", "sleep 60m"]
    volumeMounts:
      - name: foo
        mountPath: /foo
  volumes:
  - name: foo
    emptyDir: {}

。。然后打开pod上的外壳，并将2Gb文件写入卷：

kubectl exec -it alpine -- /bin/sh
$ cd foo/
$ dd if=/dev/zero of=file.txt count=2048 bs=1048576

然后我可以在GKE web控制台中看到，容器的RAM使用量增加了2Gb：

在我看来，GKE默认情况下在内存中存储

emptyDir

卷。我计划运行的工作负载需要大量内存，因此我希望磁盘备份

emptyDir

卷，这可能吗？他们在这个问题上没有什么可说的

另一种方法可能是对缓存的数据使用a，但是，如果我按照GKE文档中的建议装载它们，它们将由运行在同一节点上的所有pod共享，并且pod终止时不会清理数据，这不符合我自动管理资源的目标

坐骑 以下是容器内

df-h

的输出：

# df -h
Filesystem                Size      Used Available Use% Mounted on
overlay                  96.9G     26.2G     70.7G  27% /
overlay                  96.9G     26.2G     70.7G  27% /
tmpfs                     7.3G         0      7.3G   0% /dev
tmpfs                     7.3G         0      7.3G   0% /sys/fs/cgroup
/dev/sda1                96.9G     26.2G     70.7G  27% /foo
/dev/sda1                96.9G     26.2G     70.7G  27% /dev/termination-log
/dev/sda1                96.9G     26.2G     70.7G  27% /etc/resolv.conf
/dev/sda1                96.9G     26.2G     70.7G  27% /etc/hostname
/dev/sda1                96.9G     26.2G     70.7G  27% /etc/hosts
shm                      64.0M         0     64.0M   0% /dev/shm
tmpfs                     7.3G     12.0K      7.3G   0% /run/secrets/kubernetes.io/serviceaccount
tmpfs                     7.3G         0      7.3G   0% /proc/kcore
tmpfs                     7.3G         0      7.3G   0% /proc/timer_list
tmpfs                     7.3G         0      7.3G   0% /proc/sched_debug
tmpfs                     7.3G         0      7.3G   0% /sys/firmware

节点中的视图 我发现可以通过ssh连接到节点实例，并且我能够在节点文件系统上找到2Gb文件：

root@gke-cluster-foo-pool-b-22bb9925-xs5p:/# find . -name file.txt
./var/lib/kubelet/pods/79ad1aa4-4441-11e8-af32-42010a980039/volumes/kubernetes.io~empty-dir/foo/file.txt

---

现在我可以看到它正在写入底层文件系统，我想知道我在GKE web UI中看到的RAM使用情况是否是linux文件系统缓存或类似的，而不是存储在RAM磁盘中的文件？

根据您提供的装载信息，

emptyDir

卷装载在驱动器分区上，所以它按预期工作，并且没有装入内存。您看到的内存使用情况很可能是由于文件系统缓冲区缓存造成的，因此如果有足够的内存压力，它最终会被写入磁盘。然而，考虑到您有这么多的可用内存，系统可能认为没有必要立即这样做

---

如果您还有更多疑问，请在计算机上尝试将文件系统信息刷新到磁盘上。您应该会看到内存使用的变化。

我认为COS和Ubuntu节点之间的行为可能有所不同，但我在这两种节点类型上都观察到了这一点。您能在容器（

df-h

）中列出挂载吗？显示的是什么文件系统？我在容器中添加了

df-h

的输出。我在文章的末尾添加了一些额外的细节，现在我想知道我在GKE web UI中看到的RAM使用情况是否是linux文件系统缓存或类似的，而不是将文件存储在RAM磁盘中？你一针见血-a

echo 3>/proc/sys/vm/drop\u缓存在节点上，stackdriver内存使用率图表也随之下降。我觉得很傻，但是谢谢你！