我在用着ConfigMap
公开一个旨在跨 pod 共享并可由www-data
(Apache)用户写入的 php 文件。
配置图
apiVersion: v1
kind: ConfigMap
metadata:
name: magento-config
data:
env.php: |
<?php
return array ( ...
部署
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: apache-deployment
spec:
...
spec:
containers:
- name: apache
image: apache:2.4
...
volumeMounts:
- name: magento-configs
mountPath: /var/www/html/etc
imagePullPolicy: Always
volumes:
- name: magento-configs
configMap:
name: magento-config
该文件似乎只能root
由
root@apache-deployment-79c8548cdc-r6qhs:/# realpath /var/www/html/etc/env.php
/var/www/html/etc/..2018_04_23_16_21_10.435323593/env.php
root@apache-deployment-79c8548cdc-r6qhs:/# ls -l /var/www/html/etc/..2018_04_23_16_21_10.435323593/env.php
-rw-r--r-- 1 root root 909 Apr 23 16:21
有什么办法可以改变这种情况吗?我注意到VolumeMount
具有readOnly
默认为 的属性false
。事实上,该卷是可写的,但只能由 进行root
。
我尝试在 Apache 中设置APACHE_RUN_USER
,root
但它要求我重新编译(当前使用 apt 构建)哈哈,感觉方向错了。如果可能的话,我只想弄清楚如何ConfigMap
正确使用。
答案1
更新:
因此,您使用的一定是 Kubernetes 1.13 之前的版本,该版本仍允许该数据卷行为。我会告诉您,在 1.13+ 及更高版本中,您将无法拥有这样的读写挂载。但是,有一种解决方法,它可能是“Kubernetes”的做事方式(尽管我很难理解为什么它更好)。
解决方法:
在您的 POD/Deployment 中,创建一个装载两个卷的 init 容器。第一个卷是您的 configmap(文件),第二个是 emptyDir 容器。我们将第一个(configmap)卷视为您的源,后者视为您的目标。然后,您在新的 init 容器中要做的就是将源卷的内容复制到目标卷。
然后,在您的常规应用程序容器部分中,从上面挂载目标容器,然后您就拥有了完整的读/写功能,而不必处理 Kubernetes 的 API 更改。这也应该能够承受他们未来计划进行的大部分 API 更改。
答案2
好的,我发现了一些东西可行的(但并不理想)。首先我发现我可以使用以下设置直接从安装ConfigMap
文件subPath
:
containers:
- name: apache
image: apache:2.4
...
volumeMounts:
- name: magento-configs
mountPath: /var/www/html/app/env/etc.php
subPath: etc.php
imagePullPolicy: Always
volumes:
- name: magento-configs
configMap:
name: magento-config
然后我发现更改 pod 内文件的所有权是可行的,而且一旦更改,www-data
就可以写入文件。所以我决定启动后生命周期钩子在 Pod 启动时更改所有权
containers:
- name: apache
image: apache:2.4
lifecycle:
postStart:
exec:
command: ["chown", "www-data:www-data", "/var/www/html/app/etc/env.php"]
理想情况下,我们可以在volumeMount
设置中配置文件所有权。