Kubernetes 部署只读文件系统错误 [英] Kubernetes deployment read-only filesystem error

问题描述

我在 Kubernetes 上部署 Airflow 时遇到错误(正是这个版本的 Airflow https://github.com/puckel/docker-airflow/blob/1.8.1/Dockerfile) 关于对文件系统的写入权限.

I am facing an error while deploying Airflow on Kubernetes (precisely this version of Airflow https://github.com/puckel/docker-airflow/blob/1.8.1/Dockerfile) regarding writing permissions onto the filesystem.

pod的日志显示的错误是:

The error displayed on the logs of the pod is:

sed: couldn't open temporary file /usr/local/airflow/sed18bPUH: Read-only file system
sed: -e expression #1, char 131: unterminated `s' command
sed: -e expression #1, char 118: unterminated `s' command
Initialize database...
sed: couldn't open temporary file /usr/local/airflow/sedouxZBL: Read-only file system
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/airflow/configuration.py", line 769, in
    ....
    with open(TEST_CONFIG_FILE, 'w') as f:
IOError: [Errno 30] Read-only file system: '/usr/local/airflow/unittests.cfg'

文件系统似乎是只读的，但我不明白为什么会这样.我不确定这是 Kubernetes 配置错误(我是否需要一个特殊的 RBAC 用于 Pod?不知道)还是 Dockerfile 的问题.

It seems that the filesystem is read-only but I do not understand why it is. I am not sure if it is a Kubernetes misconfiguration (do I need a special RBAC for pods ? No idea) or if it is a problem with the Dockerfile.

部署文件如下所示:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: airflow
  namespace: test
spec:
  replicas: 1
  revisionHistoryLimit: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  template:
    metadata:
      labels:
        app: airflow
    spec:
      restartPolicy: Always
      containers:
      - name: webserver
        image: davideberdin/docker-airflow:0.0.4
        imagePullPolicy: Always
        resources:
          limits:
            cpu: 1
            memory: 1Gi
          requests:
            cpu: 50m
            memory: 128Mi
        securityContext:  #does not have any effect
          runAsUser: 0    #does not have any effect
        ports:
        - name: airflow-web
          containerPort: 8080
        args: ["webserver"]
        volumeMounts:
          - name: airflow-config-volume
            mountPath: /usr/local/airflow
            readOnly: false #does not have any effect
          - name: airflow-logs
            mountPath: /usr/local/logs
            readOnly: false #does not have any effect
      volumes:
      - name: airflow-config-volume
        secret:
          secretName: airflow-config-secret
      - name: airflow-parameters-volume
        secret:
          secretName: airflow-parameters-secret
      - name: airflow-logs
        emptyDir: {}

知道如何使文件系统可写吗?容器以 USER 气流 身份运行，但我认为该用户具有 root 权限.

Any idea how I can make the filesystem writable? The container is running as USER airflow but I think that this user has root privileges.

推荐答案

    volumeMounts:
      - name: airflow-config-volume
        mountPath: /usr/local/airflow
  volumes:
  - name: airflow-config-volume
    secret:
      secretName: airflow-config-secret

是你问题的根源，有两个原因:第一，你已经砸了airflow用户的主目录 通过将您的秘密卷安装到图像上，将其直接安装到图像期望的位置 airflow 拥有的目录.

Is the source of your problems, for two reasons: first, you have smashed the airflow user's home directory by volume mounting your secret onto the image directly into a place where the image expects a directory owned by airflow.

另外，虽然我必须启动一个集群来确认 100%，但我很确定 Secret 卷安装 - 我认为他们的 ConfigMap 朋友——是对 Pod 文件系统的只读投影；这种怀疑似乎与您的经历相符.肯定不会期望对这些卷的更改会传播回 kubernetes 集群，所以为什么要假装不然呢.

Separately, while I would have to fire up a cluster to confirm 100%, I am pretty sure that Secret volume mounts -- and I think their ConfigMap friends -- are read-only projections into the Pod filesystems; that suspicion certainly appears to match your experience. There is certainly no expectation that changes to those volumes propagate back up into the kubernetes cluster, so why pretend otherwise.

如果你想继续尝试这样的事情，你实际上对defaultMode 投射到该 volumeMount文件>，所以你可以将它们设置为 0666，但一定要注意空运者.到目前为止，简短版本不是用卷挂载来粉碎 $AIRFLOW_HOME.

If you want to continue to attempt such a thing, you do actually have influence over the defaultMode of the files projected into that volumeMount, so you could set them to 0666, but caveat emptor for sure. The short version is, by far, not to smash $AIRFLOW_HOME with a volume mount.

这篇关于Kubernetes 部署只读文件系统错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！