ファイルストレージを使用する

PFCP では、Pod からマウントして利用できるファイルストレージを提供しています。 ReadWriteMany のファイルストレージであり、組織内の複数の Pod から同時に読み書き可能です。

• PersistentVolumeClaim の作成と Pod へのマウント
• 制限事項
  • すべてのファイル操作が nobody ユーザからのアクセスとして処理される
    • chown/chgrp: Operation not permitted エラーが発生する
    • Pod securityContext fsGroup: 設定が無視されて Pod が実行される
• 参考

PersistentVolumeClaim の作成と Pod へのマウント

ファイルストレージを利用するには、PersistentVolumeClaim リソースを作成することで必要なストレージ領域を要求し、 動的に払い出された PersistentVolume を Pod からマウントします。その具体例を説明します。

1. 組織ごとに用意された専用の StorageClass を指定して、PersistentVolumeClaim を作成します。利用可能な StorageClass 名は standard-rwx-<組織名> です。

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: hello-sample-pvc
   spec:
     accessModes:
     - ReadWriteMany
     resources:
       requests:
         storage: 10Gi
     storageClassName: standard-rwx-<組織名>
   

   この例では、10GiB のファイルストレージを要求する PersistentVolumeClaim を作成しています。 このマニフェストを Kubernetes に適用すると、動的に PersistentVolume が作成され、 以下の通り PersistentVolumeClaim のステータスが Bound になることが確認できます。

   $ kubectl -n org-<組織名> get pvc
   NAME              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS               VOLUMEATTRIBUTESCLASS   AGE
   hello-sample-pvc   Bound    pvc-c5bb8161-f8f3-4b2d-b001-0aee300b7478   10Gi       RWX            standard-rwx-<組織名>   <unset>   3d2h
   

2. この PersistentVolumeClaim を指定して Pod にマウントすることで、ファイルストレージとして利用できます。

   apiVersion: v1
   kind: Pod
   metadata:
     name: jupyter-notebook
   spec:
     containers:
     - name: jupyter-notebook
       image: quay.io/jupyter/scipy-notebook:2024-03-14
       volumeMounts:
       - mountPath: "/hello-sample"
         name: hello-sample-pv
     volumes:
     - name: hello-sample-pv
       persistentVolumeClaim:
         claimName: hello-sample-pvc
   

制限事項

すべてのファイル操作が nobody ユーザからのアクセスとして処理される

PFCP のファイルストレージではボリューム上のすべてのファイルとディレクトリに対する操作が nobody ユーザ（UID 65534、GID 65534）として処理されます。これはルートユーザ（UID 0）を含むすべての Linux ユーザで同様です。

例として、下記では ubuntu ユーザ（UID 1000）がボリューム上にファイルを新規作成していますが、ファイル操作は nobody ユーザのアクセスとして処理されます。 そのため、作成されたファイルのオーナとグループが nobody:nogroup（65534:65534）となっていることを確認できます。

ubuntu@pv-test:~$ id
uid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu)
ubuntu@pv-test:~$ ls -al /data-rwx
total 8
drwxrwxrwx 3 nobody nogroup 4096 Nov 10 23:28 .
drwxr-xr-x 1 root   root    4096 Nov 10 23:09 ..
ubuntu@pv-test:~$ touch /data-rwx/testfile
ubuntu@pv-test:~$ ls -al /data-rwx/testfile
-rw-r--r-- 1 nobody nogroup 0 Nov 10 23:39 /data-rwx/testfile

ファイルのオーナが nobody である /data-rwx/testfile に対する更新操作の場合も nobody ユーザとして処理されるため権限エラーになることなく更新が成功します。

ubuntu@pv-test:~$ ls -al /data-rwx/testfile
-rw-rw-r-- 1 nobody nogroup 0 Nov 10 23:39 /data-rwx/testfile
ubuntu@pv-test:~$ date >/data-rwx/testfile
ubuntu@pv-test:~$ cat /data-rwx/testfile
Mon Nov 10 23:40:20 UTC 2025
ubuntu@pv-test:~$ ls -al /data-rwx/testfile
-rw-rw-r-- 1 nobody nogroup 29 Nov 10 23:40 /data-rwx/testfile

ただし、この制限からファイルストレージではボリューム上のファイルに対する chown/chgrp コマンドやボリュームのグループを Pod 実行時に変更する Pod securityContext fsGroup 等が機能しません。

chown/chgrp: Operation not permitted エラーが発生する

ファイルのオーナ・グループを変更する chown/chgrp コマンドをボリューム上のファイルに対して実行する場合は Operation not permitted エラーが発生して次のように失敗します。

root@pv-test:~# id
uid=0(root) gid=0(root) groups=0(root)
root@pv-test:~# chown root /data-rwx/testfile
chown: changing ownership of '/data-rwx/testfile': Operation not permitted
root@pv-test:~# chgrp root /data-rwx/testfile
chgrp: changing group of '/data-rwx/testfile': Operation not permitted

kubectl cp コマンドや tar/rsync コマンドを実行した際にも同様のエラーが発生します。これはコマンドが内部的にファイルやディレクトリのオーナを変更するためです。それぞれのコマンドでオーナを変更しないオプションを使用してエラーを回避できます。

• kubectl cp: --no-preserve オプション
• tar: --no-same-owner オプション
• rsync: --no-owner オプション

Pod securityContext fsGroup: 設定が無視されて Pod が実行される

Pod 実行時にボリュームのグループを変更する Pod SecurityContext の fsGroup 機能はファイルストレージのボリュームに対しては設定が無視されて Pod が実行されます。

参考

• Persistent Volumes | Kubernetes