本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
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 中指定的策略，對這些卷的檔案執行所有權和許可權更改。