Kubernetes：fsGroup 对 hostPath 与 pvc 的影响不同，对 nfs 与 cifs 的影响也不同答案

【问题标题】：Kubernetes: fsGroup has different impact on hostPath versus pvc and different impact on nfs versus cifsKubernetes：fsGroup 对 hostPath 与 pvc 的影响不同，对 nfs 与 cifs 的影响也不同
【发布时间】：2020-11-12 08:09:16
【问题描述】：

我的许多工作流程都使用 pod iam 角色。正如here 所记录的那样，我必须包含 fsGroup 才能让非根容器读取生成的身份令牌。问题是当我另外包含指向 cifs pv 的 pvc 时，由于超时，卷无法挂载。看起来这是因为 Kubelet 试图 chown 卷上的所有文件，这会花费太多时间并导致超时。问题……

当使用 hostPath 而不是 pvc 时，为什么 Kubernetes 不尝试 chown 所有文件？在我从 hostPath 切换到使用 pvcs 之前，所有工作流程都很好，现在发生了超时问题。
为什么这个问题发生在 cifs pvcs 而不是 nfs pvcs 上？我注意到 nfs pvcs 继续正常挂载，并且 fsGroup 似乎没有生效，因为我没有看到任何文件上的组 ID 更改。但是，由于超时问题，似乎无法再安装 cifs pvcs。如果重要的话，我正在使用本机 nfs pv lego 和 this cifs flexVolume plugin，到目前为止效果很好。

总体而言，这篇文章的目的是更好地了解 Kubernetes 如何确定在包含 fsGroup 时何时对卷上的所有文件进行 chown，以便在未来做出良好的设计决策。感谢您提供的任何帮助！

Kubernetes Chowing 文件参考

https://docs.microsoft.com/en-us/azure/aks/troubleshooting

由于 gid 和 uid 默认挂载为 root 或 0。如果是 gid 或 uid 设置为非 root，例如 1000，Kubernetes 将使用 chown 来更改该磁盘下的所有目录和文件。这个操作可以非常耗时，并且可能会导致安装磁盘非常慢。

https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods

默认情况下，Kubernetes 会递归更改所有权和权限使每个卷的内容与 a 中指定的 fsGroup 相匹配挂载该卷时 Pod 的 securityContext。对于大容量，检查和更改所有权和权限可能需要很多时间时间，减慢 Pod 启动速度。

【问题讨论】：

你好 Kubernetes 社区——如果有人对此有任何想法，请告诉我。我曾尝试在 Kubernetes 讨论论坛中提问，并且我正要在 Kubernetes github 存储库本身上提问——但它指出应该在此处提出与支持相关的问题。我还尝试与非常了解 Kubernetes 的 AWS 代表交谈，总的来说，到目前为止，没有人能够解释这是如何工作的

标签： kubernetes persistent-volumes persistent-volume-claims

【解决方案1】：

我不久前在 Kubernetes Repo 上发布了这个问题，最近在the comments 中得到了回答。

要点是 fsgroup 支持是根据每个插件实现和决定的。他们忽略了nfs，这就是为什么我从未在 nfs pvcs 上看到 Kubelet chown 文件的原因。对于 FlexVolume 插件，插件可以通过返回 FSGroup false 来选择退出基于 fsGroup 的权限更改。所以，这就是 Kubelet 尝试 chown cifs pvcs 的原因——我使用的 FlexVolume 插件不返回 fsGroup false。

所以，最后你不需要为nfs 担心这个问题，如果你使用 FlexVolume 插件来共享文件系统，你应该确保它返回 fsGroup false 如果你不这样做希望 Kubelet chown 所有文件。

【讨论】：