Kubernetes 不允许将文件挂载到容器

Question

尝试在 kubernetes 集群中部署应用程序时遇到以下错误。 kubernetes 好像不允许将文件挂载到容器，你知道可能的原因吗？

部署配置文件

apiVersion：扩展/v1beta1 种类：部署 元数据： 名称：模型加载器服务 命名空间：“{{ .Values.nsPrefix }}-aai” 规格： 选择器： 匹配标签： 应用程序：模型加载器服务 模板： 元数据： 标签： 应用程序：模型加载器服务 名称：模型加载器服务 规格： 容器： - 名称：模型加载器服务 图片：“{{ .Values.image.modelLoaderImage }}:{{ .Values.image.modelLoaderVersion }}” imagePullPolicy: {{ .Values.pullPolicy }} 环境： - 名称：CONFIG_HOME 值：/opt/app/model-loader/config/ 卷装： - 挂载路径：/etc/localtime 名称：当地时间 只读：真 - 安装路径：/opt/app/model-loader/config/ 名称：aai-model-loader-config - 挂载路径：/var/log/onap 名称：aai-model-loader-logs - 安装路径：/opt/app/model-loader/bundleconfig/etc/logback.xml 名称：aai-model-loader-log-conf 子路径：logback.xml 端口： - 容器端口：8080 - 容器端口：8443 - 名称：filebeat-onap-aai-model-loader 图片：{{ .Values.image.filebeat }} imagePullPolicy: {{ .Values.pullPolicy }} 卷装： - 挂载路径：/usr/share/filebeat/filebeat.yml 名称：filebeat-conf - 挂载路径：/var/log/onap 名称：aai-model-loader-logs - 挂载路径：/usr/share/filebeat/data 名称：aai-model-loader-filebeat 卷： - 名称：当地时间 主机路径： 路径：/etc/localtime - 名称：aai-model-loader-config 主机路径： 路径：“/dockerdata-nfs/{{ .Values.nsPrefix }}/aai/model-loader/appconfig/” - 名称：filebeat-conf 主机路径： 路径：/dockerdata-nfs/{{ .Values.nsPrefix }}/log/filebeat/logback/filebeat.yml

本期详细信息：

message: 'invalid header field value "oci runtime error: container_linux.go:247:

        starting container process caused \"process_linux.go:359: container init

        caused \\\"rootfs_linux.go:53: mounting \\\\\\\"/dockerdata-nfs/onap/log/filebeat/logback/filebeat.yml\\\\\\\"

        to rootfs \\\\\\\"/var/lib/docker/aufs/mnt/7cd32a29938e9f70a727723f550474cb5b41c0966f45ad0c323360779f08cf5c\\\\\\\"

        at \\\\\\\"/var/lib/docker/aufs/mnt/7cd32a29938e9f70a727723f550474cb5b41c0966f45ad0c323360779f08cf5c/usr/share/filebeat/filebeat.yml\\\\\\\"

        caused \\\\\\\"not a directory\\\\\\\"\\\"\"\n"'

....

$ docker version
Client:
 Version:      1.12.6
 API version:  1.24
 Go version:   go1.6.4
 Git commit:   78d1802
 Built:        Tue Jan 10 20:38:45 2017
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.6
 API version:  1.24
 Go version:   go1.6.4
 Git commit:   78d1802
 Built:        Tue Jan 10 20:38:45 2017
 OS/Arch:      linux/amd64

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.4", GitCommit:"793658f2d7ca7f064d2bdf606519f9fe1229c381", GitTreeState:"clean", BuildDate:"2017-08-17T08:48:23Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.3-rancher3", GitCommit:"772c4c54e1f4ae7fc6f63a8e1ecd9fe616268e16", GitTreeState:"clean", BuildDate:"2017-11-27T19:51:43Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

Answer 1

caused "not a directory" 有点不言自明。您使用的确切 volume 和 volumeMount 定义是什么？你在声明中使用subPath 吗？

编辑：改变

- name: filebeat-conf
  hostPath:
    path: /dockerdata-nfs/{{ .Values.nsPrefix }}/log/filebeat/logback/filebeat.yml

到

- name: filebeat-conf
  hostPath:
    path: /dockerdata-nfs/{{ .Values.nsPrefix }}/log/filebeat/logback/

并将subPath: filebeat.yml 添加到volumeMount

Answer 2

SELinux 也可能是这里的罪魁祸首。登录节点，执行sestatus。如果该策略被禁用，您将看到输出为 SELINUX=disabled 否则它将类似于以下内容：

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             mcs
Current mode:                   permissive
Mode from config file:          permissive
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      31

第一个选项： 您可以通过编辑/etc/selinux/config 文件来禁用selinux，并将SELINUX=permissive 更新为SELINUX=disabled。完成后，重新启动机器并部署以查看是否已修复。但是，这不是推荐的方式，可以看作是一种临时解决方法。

第二个选项： 登录到节点并执行ps -efZ | grep kubelet，这将给出类似的内容。

system_u:system_r:kernel_t:s0   root      1592     1  2 May23 ?        09:58:18 /usr/local/bin/kubelet --anonymous-auth=false

现在，从此输出中捕获字符串 system_u:system_r:kernel_t:s0，可以在部署中将其更改为安全上下文，如下所示。

securityContext:
    seLinuxOptions:
      user: system_u
      role: system_r
      type: spc_t
      level: s0

部署您的应用程序并检查日志是否已修复。如果这对您有用或需要任何进一步的帮助，请告诉我。

Answer 3

这是一个多节点集群吗？如果是这样，则该文件需要存在于所有 Kubernetes 节点上，因为 pod 通常安排在随机可用的主机上。无论如何，ConfigMaps 是向容器提供静态/只读文件的更好方法。