4.4. S3 プロトコルを使用してレガシーアプリケーションデータをクラウドネイティブアプリケーションと共有する
多くのレガシーアプリケーションは、ファイルシステムを使用してデータセットを共有します。S3 操作を使用して、ファイルシステム内のレガシーデータにアクセスして共有できます。データを共有するには、次のことを行う必要があります。
- 既存のファイルシステムデータセット、つまり Ceph FileSystem (CephFS) などの RWX ボリュームをエクスポートするか、S3 プロトコルを使用して新しいファイルシステムデータセットを作成します。
- ファイルシステムと S3 プロトコルの両方からファイルシステムデータセットにアクセスします。
- S3 アカウントを設定し、それらを既存または新規のファイルシステムの一意の識別子 (UID) とグループ識別子 (GID) にマップします。
4.4.1. ファイルシステムを使用するための NamespaceStore の作成
前提条件
- OpenShift Data Foundation Operator がインストールされた OpenShift Container Platform。
- Multicloud Object Gateway (MCG) へのアクセス。
手順
- OpenShift Web コンソールにログインします。
-
Storage
Object Storage をクリックします。 - NamespaceStore タブをクリックして、namespace バケットで使用する NamespaceStore リソースを作成します。
- Create namespaces をクリックします。
- NamespaceStore の名前を入力します。
- プロバイダーとしてファイルシステムを選択します。
- 永続ボリュームクレームを選択します。
フォルダー名を入力します。
フォルダー名が存在する場合は、そのフォルダーを使用して NamespaceStore を作成するか、その名前のフォルダーを作成します。
- Create をクリックします。
- NamespaceStore が Ready 状態であることを確認します。
4.4.2. NamespaceStore ファイルシステム設定を使用したアカウントの作成
NamespaceStore ファイルシステム設定を使用して新しいアカウントを作成するか、YAML を編集して既存の通常のアカウントを NamespaceStore ファイルシステムアカウントに変換できます。
NamespaceStore ファイルシステム設定をアカウントから削除することはできません。
前提条件
カスタマーポータル から Multicloud Object Gateway (MCG) コマンドラインインターフェイスバイナリーをダウンロードし、実行可能にする。
注記アーキテクチャーに応じて適切な製品バリアントを選択してください。利用可能なプラットフォームは、Linux (x86_64)、Windows、Mac OS です。
手順
MCG コマンドラインインターフェイスを使用して、NamespaceStore ファイルシステム設定で新しいアカウントを作成します。
$ noobaa account create <noobaa-account-name> [flags]
以下に例を示します。
$ noobaa account create testaccount --full_permission --nsfs_account_config --gid 10001 --uid 10001 –default_resource fs_namespacestore
allow_bucket_create
アカウントが新しいバケットの作成を許可されているかどうかを示します。サポートされている値は
true
またはfalse
です。デフォルト値はtrue
です。allowed_buckets
ユーザーがアクセス権と管理権を持つことを許可されているバケット名のコンマ区切りのリスト。
default_resource
S3 CreateBucket 操作を使用するときに新しいバケットが作成される NamespaceStore リソース。NamespaceStore は、RWX (ReadWriteMany) 永続ボリューム要求 (PVC) によってサポートされている必要があります。
full_permission
アカウントに完全な権限を与えるかどうかを示します。サポートされている値は
true
またはfalse
です。デフォルト値はfalse
です。new_buckets_path
新しいバケットに対応するディレクトリーが作成されるファイルシステムパス。パスは、NamespaceStore ファイルシステム PVC のファイルシステム内にあり、新しく作成されたオブジェクトバケットクラスのファイルシステムマッピングとして機能する新しいディレクトリーが作成されます。
nsfs_account_config
アカウントが NamespaceStore ファイルシステムに使用されているかどうかを示す必須フィールド。
nsfs_only
アカウントが NamespaceStore ファイルシステムにのみ使用されるかどうかを示します。サポートされている値は true または
false
です。デフォルト値はfalse
です。'true' に設定すると、他のタイプのバケットへのアクセスが制限されます。uid
MCG アカウントがマップされるファイルシステムのユーザー ID であり、ファイルシステム上のデータにアクセスして管理するために使用されます。
gid
MCG アカウントがマップされるファイルシステムのグループ ID であり、ファイルシステム上のデータにアクセスして管理するために使用されます。
MCG システムは、アカウント設定とその S3 クレデンシャルを含む応答を送信します。
# NooBaaAccount spec: allow_bucket_creation: true Allowed_buckets: full_permission: true permission_list: [] default_resource: noobaa-default-namespace-store Nsfs_account_config: gid: 10001 new_buckets_path: / nsfs_only: true uid: 10001 INFO[0006] ✅ Exists: Secret "noobaa-account-testaccount" Connection info: AWS_ACCESS_KEY_ID : <aws-access-key-id> AWS_SECRET_ACCESS_KEY : <aws-secret-access-key>
次のコマンドを使用して、すべてのカスタムリソース定義 (CRD) ベースのアカウントをリスト表示できます。
$ noobaa account list NAME ALLOWED_BUCKETS DEFAULT_RESOURCE PHASE AGE testaccount [*] noobaa-default-backing-store Ready 1m17s
特定のアカウントに関心がある場合は、そのカスタムリソース定義 (CRD) をアカウント名で直接読み取ることができます。
$ oc get noobaaaccount/testaccount -o yaml spec: allow_bucket_creation: true allowed_buckets: full_permission: true permission_list: [] default_resource: noobaa-default-namespace-store nsfs_account_config: gid: 10001 new_buckets_path: / nsfs_only: true uid: 10001
4.4.3. openshift-storage namespace からレガシーアプリケーションデータにアクセスする
Multicloud Object Gateway (MCG) NamespaceStore ファイルシステム (NSFS) 機能を使用する場合、データが openshift-storage
namespace に存在する永続ボリューム要求 (PVC) が必要です。ほとんどすべての場合、アクセスする必要のあるデータは、openshift-storage
namespace ではなく、レガシーアプリケーションが使用する namespace にあります。
別の namespace に保存されているデータにアクセスするには、レガシーアプリケーションが使用するのと同じ CephFS ボリュームを指す PVC を openshift-storage
namespace に作成する必要があります。
手順
scc
を使用してアプリケーションの namespace を表示します。$ oc get ns <application_namespace> -o yaml | grep scc
- <application_namespace>
アプリケーションの namespace の名前を指定します。
以下に例を示します。
$ oc get ns testnamespace -o yaml | grep scc openshift.io/sa.scc.mcs: s0:c26,c5 openshift.io/sa.scc.supplemental-groups: 1000660000/10000 openshift.io/sa.scc.uid-range: 1000660000/10000
アプリケーションの namespace に移動します。
$ oc project <application_namespace>
以下に例を示します。
$ oc project testnamespace
MCG NSFS 機能を使用して、noobaa S3 エンドポイントから消費する Pod に ReadWriteMany (RWX) PVC がマウントされていることを確認します。
$ oc get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE cephfs-write-workload-generator-no-cache-pv-claim Bound pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a 10Gi RWX ocs-storagecluster-cephfs 12s
$ oc get pod NAME READY STATUS RESTARTS AGE cephfs-write-workload-generator-no-cache-1-cv892 1/1 Running 0 11s
Pod 内の永続ボリューム (PV) のマウントポイントを確認します。
Pod から PV のボリューム名を取得します。
$ oc get pods <pod_name> -o jsonpath='{.spec.volumes[]}'
- <pod_name>
pod の名前を指定します。
以下に例を示します。
$ oc get pods cephfs-write-workload-generator-no-cache-1-cv892 -o jsonpath='{.spec.volumes[]}' {"name":"app-persistent-storage","persistentVolumeClaim":{"claimName":"cephfs-write-workload-generator-no-cache-pv-claim"}}
この例では、PVC のボリュームの名前は
cephfs-write-workload-generator-no-cache-pv-claim
です。
Pod 内のすべてのマウントをリスト表示し、前の手順で特定したボリュームのマウントポイントを確認します。
$ oc get pods <pod_name> -o jsonpath='{.spec.containers[].volumeMounts}'
以下に例を示します。
$ oc get pods cephfs-write-workload-generator-no-cache-1-cv892 -o jsonpath='{.spec.containers[].volumeMounts}' [{"mountPath":"/mnt/pv","name":"app-persistent-storage"},{"mountPath":"/var/run/secrets/kubernetes.io/serviceaccount","name":"kube-api-access-8tnc5","readOnly":true}]
Pod 内の RWX PV のマウントポイントを確認します。
$ oc exec -it <pod_name> -- df <mount_path>
<mount_path>
前の手順で特定したマウントポイントへのパスを指定します。
以下に例を示します。
$ oc exec -it cephfs-write-workload-generator-no-cache-1-cv892 -- df /mnt/pv main Filesystem 1K-blocks Used Available Use% Mounted on 172.30.202.87:6789,172.30.120.254:6789,172.30.77.247:6789:/volumes/csi/csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213/edcfe4d5-bdcb-4b8e-8824-8a03ad94d67c 10485760 0 10485760 0% /mnt/pv
UID および SELinux ラベルが、レガシー namespace が使用するものと同じであることを確認してください。
$ oc exec -it <pod_name> -- ls -latrZ <mount_path>
以下に例を示します。
$ oc exec -it cephfs-write-workload-generator-no-cache-1-cv892 -- ls -latrZ /mnt/pv/ total 567 drwxrwxrwx. 3 root root system_u:object_r:container_file_t:s0:c26,c5 2 May 25 06:35 . -rw-r--r--. 1 1000660000 root system_u:object_r:container_file_t:s0:c26,c5 580138 May 25 06:35 fs_write_cephfs-write-workload-generator-no-cache-1-cv892-data.log drwxrwxrwx. 3 root root system_u:object_r:container_file_t:s0:c26,c5 30 May 25 06:35 ..
openshift-storage
namespace からアクセス可能にするレガシーアプリケーション RWX PV の情報を取得します。$ oc get pv | grep <pv_name>
<pv_name>
PV の名前を指定します。
以下に例を示します。
$ oc get pv | grep pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a 10Gi RWX Delete Bound testnamespace/cephfs-write-workload-generator-no-cache-pv-claim ocs-storagecluster-cephfs 47s
1 つ以上の noobaa-endpoint Pod が PVC にアクセスできるように、レガシーアプリケーションの PVC が
openshift-storage
namespace からアクセス可能であることを確認します。volumeAttributes
からsubvolumePath
とvolumeHandle
の値を検索します。これらの値は、レガシーアプリケーション PV の YAML 記述から取得できます。$ oc get pv <pv_name> -o yaml
以下に例を示します。
$ oc get pv pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a -o yaml apiVersion: v1 kind: PersistentVolume metadata: annotations: pv.kubernetes.io/provisioned-by: openshift-storage.cephfs.csi.ceph.com creationTimestamp: "2022-05-25T06:27:49Z" finalizers: - kubernetes.io/pv-protection name: pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a resourceVersion: "177458" uid: 683fa87b-5192-4ccf-af2f-68c6bcf8f500 spec: accessModes: - ReadWriteMany capacity: storage: 10Gi claimRef: apiVersion: v1 kind: PersistentVolumeClaim name: cephfs-write-workload-generator-no-cache-pv-claim namespace: testnamespace resourceVersion: "177453" uid: aa58fb91-c3d2-475b-bbee-68452a613e1a csi: controllerExpandSecretRef: name: rook-csi-cephfs-provisioner namespace: openshift-storage driver: openshift-storage.cephfs.csi.ceph.com nodeStageSecretRef: name: rook-csi-cephfs-node namespace: openshift-storage volumeAttributes: clusterID: openshift-storage fsName: ocs-storagecluster-cephfilesystem storage.kubernetes.io/csiProvisionerIdentity: 1653458225664-8081-openshift-storage.cephfs.csi.ceph.com subvolumeName: csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213 subvolumePath: /volumes/csi/csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213/edcfe4d5-bdcb-4b8e-8824-8a03ad94d67c volumeHandle: 0001-0011-openshift-storage-0000000000000001-cc416d9e-dbf3-11ec-b286-0a580a810213 persistentVolumeReclaimPolicy: Delete storageClassName: ocs-storagecluster-cephfs volumeMode: Filesystem status: phase: Bound
前のステップで特定した
subvolumePath
とvolumeHandle
の値を使用して、レガシーアプリケーション PV と同じ CephFS ボリュームを指すopenshift-storage
namespace に新しい PV および PVC オブジェクトを作成します。YAML ファイルサンプル:
$ cat << EOF >> pv-openshift-storage.yaml apiVersion: v1 kind: PersistentVolume metadata: name: cephfs-pv-legacy-openshift-storage spec: storageClassName: "" accessModes: - ReadWriteMany capacity: storage: 10Gi 1 csi: driver: openshift-storage.cephfs.csi.ceph.com nodeStageSecretRef: name: rook-csi-cephfs-node namespace: openshift-storage volumeAttributes: # Volume Attributes can be copied from the Source testnamespace PV "clusterID": "openshift-storage" "fsName": "ocs-storagecluster-cephfilesystem" "staticVolume": "true" # rootpath is the subvolumePath: you copied from the Source testnamespace PV "rootPath": /volumes/csi/csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213/edcfe4d5-bdcb-4b8e-8824-8a03ad94d67c volumeHandle: 0001-0011-openshift-storage-0000000000000001-cc416d9e-dbf3-11ec-b286-0a580a810213-clone 2 persistentVolumeReclaimPolicy: Retain volumeMode: Filesystem --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: cephfs-pvc-legacy namespace: openshift-storage spec: storageClassName: "" accessModes: - ReadWriteMany resources: requests: storage: 10Gi 3 volumeMode: Filesystem # volumeName should be same as PV name volumeName: cephfs-pv-legacy-openshift-storage EOF
前のステップで指定した YAML ファイルを使用して、
openshift-storage
namespace に PV と PVC を作成します。$ oc create -f <YAML_file>
<YAML_file>
YAML ファイルの名前を指定します。
以下に例を示します。
$ oc create -f pv-openshift-storage.yaml persistentvolume/cephfs-pv-legacy-openshift-storage created persistentvolumeclaim/cephfs-pvc-legacy created
PVC が
openshift-storage
namespace で使用可能であることを確認します。$ oc get pvc -n openshift-storage NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE cephfs-pvc-legacy Bound cephfs-pv-legacy-openshift-storage 10Gi RWX 14s
openshift-storage
プロジェクトに移動します。$ oc project openshift-storage Now using project "openshift-storage" on server "https://api.cluster-5f6ng.5f6ng.sandbox65.opentlc.com:6443".
NSFS namespace ストアを作成します。
$ noobaa namespacestore create nsfs <nsfs_namespacestore> --pvc-name='<cephfs_pvc_name>' --fs-backend='CEPH_FS'
<nsfs_namespacestore>
- NSFS namespace ストアの名前を指定します。
<cephfs_pvc_name>
openshift-storage
namespace で CephFS PVC の名前を指定します。以下に例を示します。
$ noobaa namespacestore create nsfs legacy-namespace --pvc-name='cephfs-pvc-legacy' --fs-backend='CEPH_FS'
noobaa-endpoint Pod が再起動し、NSFS namespace ストア (
/nsfs/legacy-namespace
mountpoint など) に PVC が正常にマウントされていることを確認します。$ oc exec -it <noobaa_endpoint_pod_name> -- df -h /nsfs/<nsfs_namespacestore>
<noobaa_endpoint_pod_name>
noobaa エンドポイント Pod の名前を指定します。
以下に例を示します。
$ oc exec -it noobaa-endpoint-5875f467f5-546c6 -- df -h /nsfs/legacy-namespace Filesystem Size Used Avail Use% Mounted on 172.30.202.87:6789,172.30.120.254:6789,172.30.77.247:6789:/volumes/csi/csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213/edcfe4d5-bdcb-4b8e-8824-8a03ad94d67c 10G 0 10G 0% /nsfs/legacy-namespace
MCG ユーザーアカウントを作成します。
$ noobaa account create <user_account> --full_permission --allow_bucket_create=true --new_buckets_path='/' --nsfs_only=true --nsfs_account_config=true --gid <gid_number> --uid <uid_number> --default_resource='legacy-namespace'
<user_account>
- MCG ユーザーアカウントの名前を指定します。
<gid_number>
- GID 番号を指定します。
<uid_number>
UID 番号を指定します。
重要レガシーアプリケーションと同じ
UID
とGID
を使用します。前の出力から見つけることができます。以下に例を示します。
$ noobaa account create leguser --full_permission --allow_bucket_create=true --new_buckets_path='/' --nsfs_only=true --nsfs_account_config=true --gid 0 --uid 1000660000 --default_resource='legacy-namespace'
MCG バケットを作成します。
レガシーアプリケーション Pod の CephFS PV および PVC の NSFS 共有内に S3 専用のフォルダーを作成します。
$ oc exec -it <pod_name> -- mkdir <mount_path>/nsfs
以下に例を示します。
$ oc exec -it cephfs-write-workload-generator-no-cache-1-cv892 -- mkdir /mnt/pv/nsfs
nsfs/
パスを使用して MCG バケットを作成します。$ noobaa api bucket_api create_bucket '{ "name": "<bucket_name>", "namespace":{ "write_resource": { "resource": "<nsfs_namespacestore>", "path": "nsfs/" }, "read_resources": [ { "resource": "<nsfs_namespacestore>", "path": "nsfs/" }] } }'
以下に例を示します。
$ noobaa api bucket_api create_bucket '{ "name": "legacy-bucket", "namespace":{ "write_resource": { "resource": "legacy-namespace", "path": "nsfs/" }, "read_resources": [ { "resource": "legacy-namespace", "path": "nsfs/" }] } }'
レガシーアプリケーションおよび
openshift-storage
namespace の PVC にあるフォルダーの SELinux ラベルを確認します。$ oc exec -it <noobaa_endpoint_pod_name> -n openshift-storage -- ls -ltraZ /nsfs/<nsfs_namespacstore>
以下に例を示します。
$ oc exec -it noobaa-endpoint-5875f467f5-546c6 -n openshift-storage -- ls -ltraZ /nsfs/legacy-namespace total 567 drwxrwxrwx. 3 root root system_u:object_r:container_file_t:s0:c0,c26 2 May 25 06:35 . -rw-r--r--. 1 1000660000 root system_u:object_r:container_file_t:s0:c0,c26 580138 May 25 06:35 fs_write_cephfs-write-workload-generator-no-cache-1-cv892-data.log drwxrwxrwx. 3 root root system_u:object_r:container_file_t:s0:c0,c26 30 May 25 06:35 ..
$ oc exec -it <pod_name> -- ls -latrZ <mount_path>
以下に例を示します。
$ oc exec -it cephfs-write-workload-generator-no-cache-1-cv892 -- ls -latrZ /mnt/pv/ total 567 drwxrwxrwx. 3 root root system_u:object_r:container_file_t:s0:c26,c5 2 May 25 06:35 . -rw-r--r--. 1 1000660000 root system_u:object_r:container_file_t:s0:c26,c5 580138 May 25 06:35 fs_write_cephfs-write-workload-generator-no-cache-1-cv892-data.log drwxrwxrwx. 3 root root system_u:object_r:container_file_t:s0:c26,c5 30 May 25 06:35 ..
これらの例では、SELinux ラベルが同じではないため、アクセス許可が拒否されたり、アクセスの問題が発生したりすることがわかります。
レガシーアプリケーションと
openshift-storage
Pod がファイルで同じ SELinux ラベルを使用していることを確認します。これは、次のいずれかの方法で実行できます。
NSFS namespace ストアを削除します。
MCG バケットを削除します。
$ noobaa bucket delete <bucket_name>
以下に例を示します。
$ noobaa bucket delete legacy-bucket
MCG ユーザーアカウントを削除します。
$ noobaa account delete <user_account>
以下に例を示します。
$ noobaa account delete leguser
NSFS namespace ストアを削除します。
$ noobaa namespacestore delete <nsfs_namespacestore>
以下に例を示します。
$ noobaa namespacestore delete legacy-namespace
PV と PVC を削除します。
重要PV と PVC を削除する前に、PV に保持ポリシーが設定されていることを確認してください。
$ oc delete pv <cephfs_pv_name>
$ oc delete pvc <cephfs_pvc_name>
<cephfs_pv_name>
- レガシーアプリケーションの CephFS PV 名を指定します。
<cephfs_pvc_name>
レガシーアプリケーションの CephFS PVC 名を指定します。
以下に例を示します。
$ oc delete pv cephfs-pv-legacy-openshift-storage
$ oc delete pvc cephfs-pvc-legacy
4.4.3.1. レガシーアプリケーションプロジェクトのデフォルトの SELinux ラベルを、openshift-storage プロジェクトのラベルと一致するように変更します
現在の
openshift-storage
namespace をsa.scc.mcs
で表示します。$ oc get ns openshift-storage -o yaml | grep sa.scc.mcs openshift.io/sa.scc.mcs: s0:c26,c0
レガシーアプリケーションの namespace を編集し、
openshift-storage
namespace のsa.scc.mcs
の値でsa.scc.mcs
を変更します。$ oc edit ns <appplication_namespace>
以下に例を示します。
$ oc edit ns testnamespace
$ oc get ns <application_namespace> -o yaml | grep sa.scc.mcs
以下に例を示します。
$ oc get ns testnamespace -o yaml | grep sa.scc.mcs openshift.io/sa.scc.mcs: s0:c26,c0
-
レガシーアプリケーション Pod を再起動します。すべてのファイルの再ラベル付けが行われ、SELinux ラベルが
openshift-storage
デプロイメントと一致するようになりました。
4.4.3.2. レガシーアプリケーション PVC をマウントする Pod を持つデプロイメント設定に対してのみ SELinux ラベルを変更する
MustRunAs
およびseLinuxOptions
オプションを使用して、openshift-storage
プロジェクトが使用するマルチカテゴリーセキュリティー (MCS) を使用して新しいscc
を作成します。サンプル YAML ファイル:
$ cat << EOF >> scc.yaml allowHostDirVolumePlugin: false allowHostIPC: false allowHostNetwork: false allowHostPID: false allowHostPorts: false allowPrivilegeEscalation: true allowPrivilegedContainer: false allowedCapabilities: null apiVersion: security.openshift.io/v1 defaultAddCapabilities: null fsGroup: type: MustRunAs groups: - system:authenticated kind: SecurityContextConstraints metadata: annotations: name: restricted-pvselinux priority: null readOnlyRootFilesystem: false requiredDropCapabilities: - KILL - MKNOD - SETUID - SETGID runAsUser: type: MustRunAsRange seLinuxContext: seLinuxOptions: level: s0:c26,c0 type: MustRunAs supplementalGroups: type: RunAsAny users: [] volumes: - configMap - downwardAPI - emptyDir - persistentVolumeClaim - projected - secret EOF
$ oc create -f scc.yaml
デプロイメント用のサービスアカウントを作成し、新しく作成した
scc
に追加します。サービスアカウントを作成します。
$ oc create serviceaccount <service_account_name>
- <service_account_name>`
サービスアカウントの名前を指定します。
以下に例を示します。
$ oc create serviceaccount testnamespacesa
新しく作成した
scc
にサービスアカウントを追加します。$ oc adm policy add-scc-to-user restricted-pvselinux -z <service_account_name>
以下に例を示します。
$ oc adm policy add-scc-to-user restricted-pvselinux -z testnamespacesa
新しく作成されたサービスアカウントを使用するように、レガシーアプリケーションのデプロイメントにパッチを適用します。これにより、デプロイメントで SELinux ラベルを指定できます。
$ oc patch dc/<pod_name> '{"spec":{"template":{"spec":{"serviceAccountName": "<service_account_name>"}}}}'
以下に例を示します。
$ oc patch dc/cephfs-write-workload-generator-no-cache --patch '{"spec":{"template":{"spec":{"serviceAccountName": "testnamespacesa"}}}}'
デプロイメントを編集して、デプロイメント設定の SELinux ラベルで使用するセキュリティーコンテキストを指定します。
$ oc edit dc <pod_name> -n <application_namespace>
以下の行を追加します。
spec: template: metadata: securityContext: seLinuxOptions: Level: <security_context_value>
<security_context_value>
この値は、レガシーアプリケーション Pod の CephFS PV および PVC で、NSFS 共有内に S3 専用のフォルダーを作成するコマンドを実行するときに見つかります。
以下に例を示します。
$ oc edit dc cephfs-write-workload-generator-no-cache -n testnamespace
spec: template: metadata: securityContext: seLinuxOptions: level: s0:c26,c0
デプロイメント設定の SELinux ラベルで使用されるセキュリティーコンテキストが正しく指定されていることを確認してください。
$ oc get dc <pod_name> -n <application_namespace> -o yaml | grep -A 2 securityContext
以下に例を示します。
$ oc get dc cephfs-write-workload-generator-no-cache -n testnamespace -o yaml | grep -A 2 securityContext securityContext: seLinuxOptions: level: s0:c26,c0
レガシーアプリケーションが再起動され、
openshift-storage
namespace と同じ SELinux ラベルの使用が開始されます。