Kubernetes：fsGroup 对 hostPath 和 pvc 的影响不同，对 nfs 和 cifs 的影响也不同
Kubernetes: fsGroup has different impact on hostPath versus pvc and different impact on nfs versus cifs
我的许多工作流程都使用 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，到目前为止效果很好。
总的来说，post 的目标是更好地了解 Kubernetes 如何确定在包含 fsGroup 时何时对卷上的所有文件进行 chown，以便做出良好的设计决策。感谢您提供的任何帮助！
Kubernetes Chowning 文件参考
https://docs.microsoft.com/en-us/azure/aks/troubleshooting
Since gid and uid are mounted as root or 0 by default. If gid or uid
are set as non-root, for example 1000, Kubernetes will use chown to
change all directories and files under that disk. This operation can
be time consuming and may make mounting the disk very slow.
By default, Kubernetes recursively changes ownership and permissions
for the contents of each volume to match the fsGroup specified in a
Pod's securityContext when that volume is mounted. For large volumes,
checking and changing ownership and permissions can take a lot of
time, slowing Pod startup.
我不久前在 Kubernetes Repo 上发布了这个问题，最近在 the comments 中得到了回答。
要点是 fsgroup 支持已实现并由每个插件决定。他们忽略它 nfs，这就是为什么我从未在 nfs pvcs 上看到 Kubelet chown 文件。对于 FlexVolume 插件，插件可以通过 returning FSGroup false opt-out of fsGroup 基于权限的更改。所以，这就是 Kubelet 试图 chown cifs pvcs 的原因——我使用的 FlexVolume 插件没有 return fsGroup false.
所以，最后 nfs 你不需要担心这个，如果你使用的是共享文件系统的 FlexVolume 插件，你应该确保它 return s fsGroup false 如果你不想让 Kubelet chown 所有的文件。
我的许多工作流程都使用 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，到目前为止效果很好。
总的来说，post 的目标是更好地了解 Kubernetes 如何确定在包含 fsGroup 时何时对卷上的所有文件进行 chown，以便做出良好的设计决策。感谢您提供的任何帮助！
Kubernetes Chowning 文件参考
https://docs.microsoft.com/en-us/azure/aks/troubleshooting
Since gid and uid are mounted as root or 0 by default. If gid or uid are set as non-root, for example 1000, Kubernetes will use chown to change all directories and files under that disk. This operation can be time consuming and may make mounting the disk very slow.
By default, Kubernetes recursively changes ownership and permissions for the contents of each volume to match the fsGroup specified in a Pod's securityContext when that volume is mounted. For large volumes, checking and changing ownership and permissions can take a lot of time, slowing Pod startup.
我不久前在 Kubernetes Repo 上发布了这个问题，最近在 the comments 中得到了回答。
要点是 fsgroup 支持已实现并由每个插件决定。他们忽略它 nfs，这就是为什么我从未在 nfs pvcs 上看到 Kubelet chown 文件。对于 FlexVolume 插件，插件可以通过 returning FSGroup false opt-out of fsGroup 基于权限的更改。所以，这就是 Kubelet 试图 chown cifs pvcs 的原因——我使用的 FlexVolume 插件没有 return fsGroup false.
所以，最后 nfs 你不需要担心这个，如果你使用的是共享文件系统的 FlexVolume 插件，你应该确保它 return s fsGroup false 如果你不想让 Kubelet chown 所有的文件。