fsGroup 与 SupplementalGroups

Question

我正在 OpenShift 上运行我的部署，发现我需要 GID 2121 才能具有写入权限。

当我尝试这样做时，我似乎仍然没有写访问权限：

security:
  podSecurityContext: 
    fsGroup: 2121

这给了我一个2121 is not an allowed group错误。

然而，这似乎对我有用：

security:
  podSecurityContext: 
    fsGroup: 100010000  # original fsGroup value 
    supplementalGroups: [2121]

fsGroup我想知道和 的区别supplementalGroups是什么。

我已阅读此处的文档并查看了kubectl explain deployment.spec.template.spec.securityContext，但我仍然不太明白其中的区别。

我能否澄清一下不同的用例是什么？

Answer 1

FSGroup用于设置拥有 pod 卷的组。当 pod 挂载卷时，Kubernetes 将使用该组来更改卷中所有文件的权限。

1. 所属 GID 将是 FSGroup

2. setgid 位已设置（卷中创建的新文件将归 FSGroup 所有）

3. 权限位与 rw-rw 进行或运算----

   如果未设置，Kubelet 将不会修改任何卷的所有权和权限。

使用时的一些注意事项FSGroup：

• 更改慢速和/或大型文件系统的卷的所有权可能会导致 Pod 启动延迟。

• 如果其他进程没有访问新 GID 的权限，这可能会损害使用同一卷的其他进程。

SupplementalGroups- 控制可以将哪个补充组 ID 分配给 pod 中的进程。

除了容器的主 GID 之外，还应用到每个容器中运行的第一个进程的组列表。如果未指定，则不会将任何组添加到任何容器中。

另外来自OpenShift 文档：

假设无法更改 NFS 导出的权限，则处理 NFS 访问的推荐方法是使用补充组。OpenShift Container Platform 中的补充组用于共享存储，其中 NFS 就是一个例子。相比之下，iSCSI等块存储使用fsGroup SCC策略以及pod的securityContext中的fsGroup值。