為何我的應用程式會因 NFS 檔案儲存空間許可權的群組 ID 錯誤而失敗?

排除檔案儲存群組 ID 權限錯誤的問題。

經典基礎架構

在您 建立 或 新增現有 NFS 儲存到群集後，您的應用程式的容器部署會失敗。 您會看到群組 ID (GID) 錯誤訊息。

當您從未指定使用者及使用者 ID (UID) 的映像檔建立容器時，依預設會由容器內的 root 使用者 (UID: 0) 執行 Dockerfile 中的所有指示。

不過，當您想要將 NFS 檔案共用裝載至容器時，容器內的使用者 ID 0 會對映至 NFS 主機系統上的使用者 ID nobody。 因此，磁區裝載路徑是由使用者 ID nobody 所擁有，而不是由 root 所擁有。 此安全特性也稱為 root quash。 Root quash 可透過裝載容器而不授與使用者 ID 在實際 NFS 主機檔案系統上的 root 許可權，來保護 NFS 內的資料。

使用 Kubernetes DaemonSet 來啟用 NFSv4 檔案共用所有工作節點上儲存掛載路徑的 root 權限。

若要容許磁區裝載路徑上的 root 許可權，您必須在工作者節點上設定 ConfigMap。 ConfigMap 會將使用者 ID nobody 從 NFS 主機系統對映至容器中的 root 使用者 ID 0。 此處理程序也稱為無根擠壓。 更新所有工作者節點的有效方法是使用常駐程式集，它會在叢集裡的每一個工作者節點上執行指定的 Pod。 在此情況下，由常駐程式集控制的 Pod 會更新每一個工作者節點，以啟用磁區裝載路徑上的 root 許可權。

部署已配置為容許常駐程式集 Pod 以特許模式執行，這是存取主機檔案系統的必要項目。 以特許模式執行 Pod 會產生安全風險，因此請謹慎使用此選項。

常駐程式集執行時，會自動更新新增至叢集的新工作者節點。

開始之前：

完成下列步驟。

  1. 複製 norootsquash daemon 設定 部署 YAML 檔案。

  2. 建立 norootsquash 常駐程式集部署。

    oc apply -f norootsquash.yaml

  3. 取得儲存磁區裝載至其中的 Pod 名稱。 此 pod 與 norootsquash pod 不同。

    oc get pods

  4. 登入該 pod。

    oc exec -it mypod /bin/bash

  5. 請驗證裝載路徑的許可權是 root。

    root@mypod:/# ls -al /mnt/myvol/
total 8
drwxr-xr-x 2 root root 4096 Feb  7 20:49 .
drwxr-xr-x 1 root root 4096 Feb 20 18:19 .

    此輸出顯示第一行的 UID 現在為 root 所擁有 (而非 nobody)。

  6. 如果 UID 是由 nobody 所擁有，請結束 Pod 並將叢集的工作者節點重新開機。 等待節點重新開機。

    ibmcloud oc worker reboot --cluster MY_CLUSTER --worker MY_WORKER1,MY_WORKER2

  7. 重複步驟 4 和 5 以驗證權限。