我就要在容器里写文件！？-技术圈

在生产环境上遇到过一个讨厌的事情，有业务应用在容器中写入大量日志，导致磁盘空间爆满，引发了大面积驱逐。这种情况还有个比较烦心的事情就是无从监控，因此也不能用告警解决。

docker ps --size 可以凑合试一下。

虽说提倡使用标准输出来打印日志，通过 Docker 参数控制日志翻转，但是第三方容器的写入很难劝说整改，并且客观存在写入临时文件等的情况，所以还是要想个办法，在受控的情况下进行写入。

为了防止这种情况的出现，很自然的想出对策——避免容器内的任意写入行为，在 securityContext 里面加上 readOnlyRootFilesystem: true 就可以了：

  containers:
  - image: dustise/sleep:v0.9.6
    name: sleep
    securityContext:
      readOnlyRootFilesystem: true

这个容器创建之后，进入容器发现已经无法写入了。要写入文件，必须使用加载卷的方式，才能在指定位置进行写入，限制了卷尺寸，也就限制了文件写入了。

  containers:
  - image: dustise/sleep:v0.9.6
    name: sleep
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir:
      sizeLimit: "100Mi"

这里我们创建了一个限制尺寸为 100Mi 的卷，然后进入 Pod 尝试写入一个 500M 的文件：

$ df -h /cache
Filesystem                Size      Used Available Use% Mounted on
/dev/vda1                98.3G     17.3G     76.8G  18% /cache

$ dd if=/dev/zero of=/cache/data.txt bs=500M count=1
1+0 records in
1+0 records out
$ command terminated with exit code 137

可以看到这个卷的尺寸并非我们指定的 100M，而是整个数据盘的大小，后面文件成功写入了，但是过几分钟之后，Shell 被踢出，发现 Pod 被驱逐了：

$ kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
sleep-68bc88849b-5rwrd   0/1     Evicted   0          7m48s
sleep-68bc88849b-b7wz5   1/1     Running   0          104s

$ kubectl describe po sleep-68bc88849b-5rwrd
...
  Warning  Evicted    2m42s  kubelet            Usage of EmptyDir volume "cache-volume" exceeds the limit "100Mi".
  Normal   Killing    2m42s  kubelet            Stopping container sleep

可以看到驱逐原因的确是超出了限制。

驱逐是个比较慢的过程，可能不太合适，我们知道，emptyDir 还有一种内存的方式，会有改善么？

emptyDir:
  sizeLimit: "100Mi"
  medium: "Memory"

同样测试，发现还是被驱逐了。这种类型的卷是会占用容器的内存限制的（这点在实际应用时一定要注意，防止 emptyDir 挤占业务应用内存），加上 limit 会不会有所好转呢？

resources:
  requests:
    memory: "300Mi"
  limits:
    memory: "300Mi"

再次进入容器：

$ df -h /cache
Filesystem                Size      Used Available Use% Mounted on
tmpfs                     7.7G    100.0M      7.6G   1% /cache

$ dd if=/dev/zero of=/cache/data.txt bs=500M count=1
dd: error writing '/cache/data.txt': Out of memory
0+1 records in
0+0 records out

这次的反应速度就很快了，直接被拒绝。

Limit 这么好用，如果直接限制 Ephemeral Storage 会不会又能快速反应，又不影响内存占用呢？答案是否定的，这个资源的 Limit 同样是使用驱逐机制实现的。

1.20 中新增了一个 Feature gate：SizeMemoryBackedVolumes

如果放弃内存 emptyDir 的话，hostPath 能满足要求么？

apiVersion: v1
kind: PersistentVolume
metadata:
  name: task-pv-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: task-pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

申请了一个 1G 的 PVC 之后，再尝试创建文件，很遗憾，最终我在 /mnt/data 目录下收获了 10G 的文件。甚至也没有驱逐过程，换用 Local Persistent Volume 也没有任何变化。

结论

Kubernetes 容器中写入文件是一个非常不推荐的操作。两种本地卷都无法达成限制目的。如果没有外部存储设施，仅能通过 emptyDir 实现简单的写入限制，内存类型的会侵占应用内存，而磁盘类型的限制则要依赖于驱逐机制相对迟缓地完成操作。