本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
Kubernetes 1.26:支持在挂载时将 Pod fsGroup 传递给 CSI 驱动
将 fsGroup
委托给 CSI 驱动程序的功能最初在 Kubernetes 1.22 中作为 Alpha 版本引入,并在 Kubernetes 1.25 中进入 Beta 阶段。对于 Kubernetes 1.26,我们很高兴地宣布此功能已正式发布(GA)。
在此版本中,如果您在(Linux)Pod 的安全上下文中指定了 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 CSI 驱动程序利用 gid
挂载选项将 fsGroup
信息映射到卷中的所有文件。
需要注意的是,在上面的例子中,kubelet 不会直接对该卷文件中的文件和目录应用权限更改。此外,两个策略定义不再生效:CSIDriver 对象的 .spec.fsGroupPolicy
和 Pod 的 .spec.securityContext.fsGroupChangePolicy
都不再起作用。
有关此功能内部工作原理的更多详细信息,请查看增强提案和 CSI 开发者文档中的 CSI 驱动程序 fsGroup
支持。
为什么它很重要?
如果没有此功能,在某些存储环境中无法将 fsGroup 信息应用于文件。
例如,Azure File 不支持 POSIX 风格的文件所有权和权限概念。CSI 驱动程序只能在卷级别设置文件权限。
我该如何使用它?
此功能对用户来说基本上是透明的。如果您维护一个应该支持此功能的 CSI 驱动程序,请阅读 CSI 驱动程序 fsGroup
支持以获取有关如何在您的 CSI 驱动程序中支持此功能的更多信息。
不支持此功能的现有 CSI 驱动程序将继续照常工作:它们不会从 kubelet 收到任何 fsGroup
信息。此外,kubelet 将继续根据 CSIDriver 的 .spec.fsGroupPolicy
和相关 Pod 的 .spec.securityContext.fsGroupChangePolicy
中指定的策略,对这些卷的文件执行所有权和权限更改。