这篇文章已经一年多了,较旧的文章可能包含过时的内容。请检查从发表以来,页面中的信息是否变得不正确。
Kubernetes 1.26: 支持在挂载时将 Pod fsGroup 传递给 CSI 驱动程序
作者: Fabio Bertinatto (Red Hat), Hemant Kumar (Red Hat)
译者: Xin Li (DaoCloud)
将 fsGroup 委托给 CSI 驱动程序管理首先在 Kubernetes 1.22 中作为 Alpha 特性引入,并在 Kubernetes 1.25 中进阶至 Beta 状态。对于 Kubernetes 1.26,我们很高兴地宣布此特性已进阶至正式发布(GA)状态。
在此版本中,如果你在 Pod(Linux)的安全上下文中指定一个 fsGroup,则该 Pod 容器中的所有进程都是该附加组的一部分。
在以前的 Kubernetes 版本中,kubelet 总是根据 Pod 的.spec.securityContext.fsGroupChangePolicy 字段中指定的策略,将 fsGroup 属主关系和权限的更改应用于卷中的文件。
从 Kubernetes 1.26 开始,CSI 驱动程序可以选择在卷挂载期间应用 fsGroup 设置,这使 kubelet 无需更改这些卷中文件和目录的权限。
它是如何工作的?
支持此功能的 CSI 驱动程序应通告其 VOLUME_MOUNT_GROUP 节点能力。
kubelet 识别此信息后,在 Pod 启动期间将 fsGroup 信息传递给 CSI 驱动程序。这个过程是通过 NodeStageVolumeRequest
和 NodePublishVolumeRequest
CSI 调用完成的。
因此,CSI 驱动程序应使用挂载选项将 fsGroup 应用到卷中的文件上。例如,Azure File CSIDriver
利用 gid 挂载选项将 fsGroup 信息映射到卷中的所有文件。
应该注意的是,在上面的示例中,kubelet 避免直接将权限更改应用于该卷文件中的文件和目录。此外,有两个策略定义不再有效:CSIDriver 对象的 .spec.fsGroupPolicy 和Pod 的 .spec.securityContext.fsGroupChangePolicy 都不再起作用。
有关此功能内部工作原理的更多详细信息,请查看 CSI开发人员文档中的增强建议和CSI 驱动程序 fsGroup 支持。
这一特性为何重要?
如果没有此功能,则无法在某些存储环境中将 fsGroup 信息应用于文件。
例如,Azure 文件不支持 POSIX 风格的文件所有权和权限概念,CSI 驱动程序只能在卷级别设置文件权限。
我该如何使用它?
此功能应该对用户基本透明。如果你维护应支持此功能的 CSI 驱动程序,请阅读 CSI 驱动程序 fsGroup 支持
以获取有关如何在你的 CSI 驱动程序中支持此功能的更多信息。
不支持此功能的现有 CSI 驱动程序将继续照常工作:他们不会从 kubelet 收到任何fsGroup 信息。除此之外,kubelet 将根据 CSIDriver 的.spec.fsGroupPolicy 和相关 Pod 的 .spec.securityContext.fsGroupChangePolicy
中指定的策略,继续对这些卷中文件的属主关系和权限进行更改。