Kubernetes更改已装入卷的权限



我在Openstack上管理Kubernetes的部署。

我的用户pod装载了一个使用Openstack Cinder动态创建的PersistentVolume作为他们的主文件夹。

奇怪的是,如果我创建了一个文件权限为600:的(空(文件

bash-4.2$ ls -l
total 16
-rw------- 1 jovyan users     0 Jul 16 17:55 id_rsa

然后我杀死容器并重新启动它,卷再次装载,但权限现在有rw作为组权限:

bash-4.2$ ls -l
total 16
-rw-rw---- 1 jovyan users     0 Jul 16 17:55 id_rsa

关于如何进一步调试,有什么建议吗?

Kubernetes配置的详细信息

  • 体积AccessModeReadWriteOncevolumeMode: Filesystem
  • 卷文件系统是ext4:/dev/sdf: Linux rev 1.0 ext4 filesystem data, UUID=c627887b-0ff0-4310-b91d-37fe5ca9564d (needs journal recovery) (extents) (64bit) (large files) (huge files)

检查Openstack

我最初认为这是一个Openstack问题,但如果我从Openstack实例中分离卷,然后使用Openstack命令再次附加它,并使用节点上的终端装载它,权限就可以了。所以我认为这是Kubernetes在某种程度上扰乱了权限。

Yaml资源

我把吊舱、PV和PVC的YAML文件粘贴在要点上,请参阅https://gist.github.com/zonca/21b81f735d0cc9a06cb85ae0fa0285e5

我还为这些资源添加了kubectl describe的输出。它是Jupyterhub0.9.0 Helm包的部署。

之所以会发生这种情况,是因为您已使用fsGroup配置了pod。它在securityContext:下指定

---
securityContext:
fsGroup: 100
---

每当指定fsGroup字段时,容器的所有进程也是补充组ID的一部分。卷和在该卷中创建的任何文件的所有者都将是组ID。

下面是kubernetes API文档如何解释的:

fsGroup是一个特殊的补充组,适用于所有吊舱中的容器。某些卷类型允许Kubelet更改吊舱拥有的该卷的所有权:

  1. 拥有GID的将是FSGroup
  2. setgid位已设置(在卷中创建的新文件将归FSGroup所有(
  3. 权限位为ORwith rw-rw----如果未设置,Kubelet将不会修改所有权,并且任何卷的权限

相关内容

  • 没有找到相关文章

最新更新