趁热记录下,给未来的自己
在开发过程中,需要将NAS盘挂载到pod里,然后启动脚本/start.sh会启动业务服务,业务服务启动时,会在挂载目录上创建文件和文件夹。
由于安全的原因,启动pod的镜像默认是非root用户,比如user:group。而NAS盘挂载的时候,里面的文件权限是root:root, 见下图。这就带来了一个问题,当pod启动时,容器的用户是user,用user启动/start.sh时,操作挂载目录会报 permission denied 错误。
为了解决nas盘挂载到pod时,遇到的permission denied问题,基本思路就是:保证挂载的目录文件权限和容器默认用户的权限保持一致。
有三种方案:
首先,第一种方案在业务侧没有强需求(不能用root作为默认用户)的时候,是最有效快捷的方式,只需要在镜像构建阶段 设置 USERNAME root 即可。但是,我们的业务需求是不允许以root方式运行容器,所以pass。
第二种方案,是先把nas盘挂载到一台主机上,然后去修改对应的目录权限为user:group,这就要求需要在这台主机上新建user:group用户。而且如果遇到了pod容器的默认用户是user1:group1,user2:group2的时候,就要在nas挂载的主机上同步操作,很不优雅。
第三种方案,可以一劳永逸,通过模板化操作,可以实现任意pod默认用户使用nas挂载到容器的目录。
要实现第三种方案,可以利用
spec.template.spec.initContainers 在启动pod的时候,用一个初始化容器,对挂载到pod里的目录初始化目录权限为:user:group。
假定一些参数:
具体的yaml配置信息:
...
spec:
template:
spec:
containers:
- image: your_image
imagePullPolicy: Always
name: your_container_name
ports:
- containerPort: 6006
protocol: TCP
resources:
limits:
cpu: 500m
memory: 1Gi
nvidia.com/gpu: "1"
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
- mountPath: /home/user
name: aide-139741-89991d7d0
initContainers:
- args:
- -c
- chmod 755 /home/user && chown 10000:10000 /home/user
command:
- /bin/sh
image: centos
imagePullPolicy: IfNotPresent
name: initpathauth
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /home/user
name: aide-139741-89991d7d0
...
经过这样的配置,启动的容器就可以访问挂载的目录了。