我就要在容器里写文件！？
在生产环境上遇到过一个讨厌的事情，有业务应用在容器中写入大量日志，导致磁盘空间爆满，引发了大面积驱逐。这种情况还有个比较烦心的事情就是无从监控，因此也不能用告警解决。
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 实现简单的写入限制，内存类型的会侵占应用内存，而磁盘类型的限制则要依赖于驱逐机制相对迟缓地完成操作。