欢迎光临
我们一直在努力

我就要在容器里写文件!

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

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 实现简单的写入限制,内存类型的会侵占应用内存,而磁盘类型的限制则要依赖于驱逐机制相对迟缓地完成操作。

文章来源于互联网:我就要在容器里写文件!

赞(0)
未经允许不得转载:莱卡云 » 我就要在容器里写文件!