一、问题描述
当Deployment定义并使用了hostPath
类型的存储卷,在POD启动或运行过程中,出现写入存储卷的操作,比如:创建目录,创建文件,写入文件等,经常会出现没有权限的问题,通常报错字样为Permission denied
。以上报错信息通常出现在pod日志,如启动成功也可以进入容器进行复现。
二、问题原因
k8s启动容器通常不是root用户,而是其他用户,因此由其启动的容器没有权限操作宿主机中归属其他用户和组的目录。
三、解决办法
给宿主机上hostPath对应目录赋上启动pod用户的归属权限即可。具体如下:
1、确认启动pod的用户id
k8s中启动Pod的用户和组信息通常在YAML的securityContext
的runAsUser
和fsGroup
字段设置,例如:
securityContext:
runAsUser: 1001
fsGroup: 1001
如果此处未设置,那么可查看docker镜像中是否有定义。
docker inspect <image_id>
结果中查看user等信息。或直接用docker inspect <image_id> |grep -i user
尝试。
如果均未设置,那么Pod内的容器将以宿主机上的默认用户和用户组运行,即root用户(用户ID为0)和root组(组ID也为0)来运行。
出于安全考虑,Kubernetes建议不要以root用户在容器中运行应用程序。因此,即使没有在Pod的
securityContext
中设置用户和组,通常也可在容器镜像的构建过程中设置USER
指令来实现。例如,在Dockerfile中,可能有类似下面的指令:USER 1001
这将导致容器以用户ID为1001的用户运行。这个用户通常是在镜像构建过程中通过
adduser
或RUN useradd
等命令创建的。
如果容器可以启动成功,也可以进入容器,通过id
命令查看。例如:
...zookeeper-node-1-6dc9db5cd8-p646p:/$ id
uid=1001 gid=0(root) groups=0(root)
2、给目录赋权限
确认好user和group的id后,执行目录赋权命令即可。
chown -R 1001:1001 /bitnami/zookeeper/data
也可以根据id确认其在宿主机的用户名后,再进行赋权,与使用id等效。
[root@zookeeper-node-1]# grep 1001 /etc/passw
cloudroot:x:1001:1001:1001: /home/cloudroot:/bin/bash
[root@zookeeper-node-1]# chown -R cloudroot:root /bitnami/zookeeper/data
2024.3.6 v1.0