ローカル・ストレージ-ファイルおよびブロック
IBM Cloud Satellite® クラスタ用にローカル・ブロック・ボリュームまたはファイル・ボリュームを使用して永続ストレージをセットアップする。 Satellite ストレージ・テンプレートを使用して、ストレージ構成を作成できます。 ストレージ構成をクラスターに割り当てると、選択したストレージ・プロバイダーのストレージ・ドライバーがクラスターにインストールされます。
前提条件
ローカルストレージの設定を作成するには、まず、クラスタ内のワーカーノードのうち、必要な空きディスクを備えたものを特定する必要があります。 そして、それらのワーカー・ノードだけにローカル・ストレージ・ドライバーをインストールするために、それらのワーカー・ノードにラベルを付けます。
-
以下の権限が設定されていることを確認してください。
- 請求サービスの 「エディター」。
- Manager および Editor for Kubernetes サービス。
- Satellite サービスの Satellite Link 管理者 および リーダー。
-
- クラスターを作成するときに、 「 Satellite 構成のクラスター管理アクセスを有効にする」 オプションを選択していることを確認します。 クラスターの作成時に Satellite の管理者 (管理者) アクセス権限を有効にしない場合、ストレージをデプロイする前に、クラスターを再作成し、管理者アクセス権限を有効にする必要があります。
-
ローカル・ストレージ・オペレーターをデプロイします。 ローカル・ファイル・ストレージまたはブロック・ストレージをセットアップするには、ローカル・ストレージ・オペレーターをデプロイする必要があります。
-
ストレージ構成で使用するクラスター内のワーカー・ノードには、Satellite に必要なディスクのほかに、使用可能なローカル・ディスクが 1 台以上ある必要があります。 この追加のディスクは未フォーマットでなければなりません。
-
使用可能なディスクがあるワーカー・ノードのうち、構成で使用するワーカー・ノードにラベルを付けます。 ローカル・ストレージ・ドライバーは、ラベルの付いたワーカー・ノードだけにインストールされます。
ローカルストレージ構成のデバイス詳細を取得する
ローカルストレージの設定を作成する際は、使用するデバイスを指定する必要があります。 以下の手順で取得したデバイス・パスを、構成の作成時にパラメーターとして指定します。
-
クラスターにログインし、使用可能なワーカー・ノードのリストを取得します。 構成で使用するワーカー・ノードをメモします。
oc get nodes -
ローカル・ストレージ構成で使用する各ワーカー・ノードにログインします。
oc debug node/<node-name> -
ワーカー・ノードにデバッグ・ポッドがデプロイされている場合は、以下のコマンドを実行してワーカー・ノードの使用可能なディスクをリストします。
- ホスト・バイナリーを許可します。
chroot /host ``` 1. デバイスをリストします。 ```sh {: pre} lsblk ``` 1. デバイスの詳細を取得します。 使用するデバイスが、未マウントかつ未フォーマットであることを確認します。 ```sh {: pre} fdisk -l ``` -
ワーカー・ノードの使用可能なブロック・ストレージ・ディスクをリストします。 ローカル・ストレージ構成には、未マウントのディスクを使用する必要があります。 以下の
lsblkコマンドの出力例では、nvme2n1ディスクが未マウントであり、パーティションも作成されていません。NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT nvme0n1 259:3 0 100G 0 disk |-nvme0n1p1 259:4 0 1M 0 part `-nvme0n1p2 259:5 0 100G 0 part / nvme1n1 259:0 0 20G 0 disk nvme2n1 259:1 0 20G 0 disk nvme3n1 259:2 0 139.7G 0 disk /var/data -
ローカルストレージ構成に使用する各ワーカーノードについて、上記の手順を繰り返してください。
ワーカー・ノードにラベルを付ける
構成で使用するディスクのデバイス・パスを取得したら、それらのディスクがあるワーカー・ノードにラベルを付けます。
-
ワーカー・ノードの IP アドレスを取得します。
oc get nodes -
先ほど取得したワーカー・ノードにラベルを付けます。 ローカル・ストレージ・ドライバーは、このラベルの付いたワーカー・ノードにデプロイされます。 このコマンドの例の
storage=local-blockラベルを使用することも、key=value形式で独自のラベルを作成することもできます。oc label nodes <worker-IP> <worker-IP> <worker-IP> "storage=local-block"出力例
node/<worker-IP> labeled node/<worker-IP> labeled node/<worker-IP> labeled -
使用するワーカー・ノードにラベルが追加されていることを確認します。 以下のコマンドを実行してワーカー・ノードのラベルを表示し、前の手順で追加したラベルに絞り込みます。
oc get nodes --show-labels | grep --color=always storage=local-block
コンソールでの構成の作成と割り当て
-
[ロケーション]コンソールから、ストレージ構成を作成するロケーションを選択します。
-
ストレージ > ストレージ構成の作成を選択します。
-
構成の名前を入力します。
-
ストレージの種類を選択してください。
-
バージョンを選択し、「 次へ 」をクリックしてください
-
選択した 「ストレージ・タイプ」 がカスタム・パラメーターを受け入れる場合は、 「パラメーター」 タブでそれらのパラメーターを入力します。
-
選択した ストレージ・タイプ にシークレットが必要な場合は、 「シークレット (Secrets)」 タブに入力します。
-
ストレージ・クラスタブで、構成によってデプロイされたストレージ・クラスを確認するか、カスタム・ストレージ・クラスを作成します。
-
サービスへの割り当てタブで、構成の割り当て先となるサービスを選択します。
-
完了をクリックして、ストレージ構成を割り当てます。
CLI での構成の作成
-
使用するテンプレート・バージョンの パラメーター・リファレンス を確認します。
-
IBM Cloud CLI にログインします。
ibmcloud login -
Satellite ロケーションをリストして、
Managed from列をメモします。ibmcloud sat location ls -
Satellite ロケーションの
Managed fromリージョンをターゲットにします。 例えば、wdcの場合は、us-eastをターゲットにします。 詳しくは、Satellite リージョンを参照してください。ibmcloud target -r us-east -
default以外のリソース・グループを使用する場合は、そのリソース・グループをターゲットにします。ibmcloud target -g RESOURCE_GROUP -
使用するテンプレート・バージョンについて、以下のいずれかのコマンド例をコピーします。 コマンドについて詳しくは、 コマンド・リファレンス の
ibmcloud sat storage config createを参照してください。バージョン 1.0.0 の構成を作成するコマンドの例。
ibmcloud sat storage config create --location LOCATION --name NAME --template-name local-storage --template-version 1.0.0 --param "install-local-storage-file=INSTALL-LOCAL-STORAGE-FILE" --param "auto-discover-devices-file=AUTO-DISCOVER-DEVICES-FILE" --param "file-nodes-label-key=FILE-NODES-LABEL-KEY" --param "file-nodes-label-value=FILE-NODES-LABEL-VALUE" --param "file-devicepath=FILE-DEVICEPATH" --param "fstype=FSTYPE" --param "install-local-storage-block=INSTALL-LOCAL-STORAGE-BLOCK" --param "auto-discover-devices-block=AUTO-DISCOVER-DEVICES-BLOCK" --param "block-nodes-label-key=BLOCK-NODES-LABEL-KEY" --param "block-nodes-label-value=BLOCK-NODES-LABEL-VALUE" --param "block-devicepath=BLOCK-DEVICEPATH" -
使用する設定に基づいて、コマンドをカスタマイズします。
-
設定を作成するには、コマンドを実行してください。
-
設定が作成されたことを確認してください。
ibmcloud sat storage config get --config CONFIG
API での構成の作成
-
API キーを生成してから、リフレッシュ・トークンを要求します。 詳しくは、API キーを使用した IBM Cloud IAM トークンの生成を参照してください。
-
使用するテンプレート・バージョンの パラメーター・リファレンス を確認します。
-
以下のいずれかの要求例をコピーし、使用する変数を置き換えます。
バージョン 1.0.0 の構成を作成する要求の例。
curl -X POST "https://containers.cloud.ibm.com/global/v2/storage/satellite/createStorageConfigurationByController" -H "accept: application/json" -H "Authorization: TOKEN" -H "Content-Type: application/json" -d "{ \"config-name\": \"string\", \"controller\": \"string\", \"storage-class-parameters\": [ { \"additionalProp1\": \"string\", \"additionalProp2\": \"string\", \"additionalProp3\": \"string\" } ], \"storage-template-name\": \"local-storage\", \"storage-template-version\": \"1.0.0\", \"update-assignments\": true, \"user-config-parameters\": { \"entry.name\": \"INSTALL-LOCAL-STORAGE-FILE\", { \"entry.name\": \"AUTO-DISCOVER-DEVICES-FILE\", { \"entry.name\": \"FILE-NODES-LABEL-KEY\", { \"entry.name\": \"FILE-NODES-LABEL-VALUE\", { \"entry.name\": \"FILE-DEVICEPATH\", { \"entry.name\": \"FSTYPE\", { \"entry.name\": \"INSTALL-LOCAL-STORAGE-BLOCK\", { \"entry.name\": \"AUTO-DISCOVER-DEVICES-BLOCK\", { \"entry.name\": \"BLOCK-NODES-LABEL-KEY\", { \"entry.name\": \"BLOCK-NODES-LABEL-VALUE\", { \"entry.name\": \"BLOCK-DEVICEPATH\",\"user-secret-parameters\": }
CLI での課題の作成
-
ストレージ構成を一覧表示し、クラスタに割り当てたいストレージ構成をメモしておいてください。
ibmcloud sat storage config ls -
ストレージを割り当てたいクラスタ、クラスタグループ、またはサービスのIDを取得します。
クラスターが Satellite Config に登録されていることを確認したり、グループを作成したりするには、Satellite Config で使用するためのクラスターのセットアップを参照してください。
クラスター・グループをリストするコマンドの例。
ibmcloud sat group lsクラスターをリストするコマンドの例。
ibmcloud oc cluster ls --provider satelliteSatellite サービスをリストするコマンドの例。
ibmcloud sat service ls --location LOCATION -
以前に取得したクラスター、グループ、またはサービスにストレージ構成を割り当てます。 詳しくは、
ibmcloud sat storage assignment createコマンドを参照してください。クラスター・グループに構成を割り当てるコマンドの例。
ibmcloud sat storage assignment create --group GROUP --config CONFIG --name NAMEクラスターに構成を割り当てるコマンドの例。
ibmcloud sat storage assignment create --cluster CLUSTER --config CONFIG --name NAMEサービス・クラスターに構成を割り当てるコマンドの例。
ibmcloud sat storage assignment create --service-cluster-id CLUSTER --config CONFIG --name NAME -
割り当てが作成されたことを確認します。
ibmcloud sat storage assignment ls (--cluster CLUSTER | --config CONFIG | --location LOCATION | --service-cluster-id CLUSTER)
API でのストレージ割り当ての作成
-
以下のいずれかの要求例をコピーします。
構成をクラスターに割り当てる要求の例。
curl -X POST "https://containers.cloud.ibm.com/global/v2/storage/satellite/createAssignmentByCluster" -H "accept: application/json" -H "Authorization: Bearer TOKEN" -H "Content-Type: application/json" -d "{ \"channelName\": \"CONFIGURATION-NAME\", \"cluster\": \"CLUSTER-ID\", \"controller\": \"LOCATION-ID\", \"name\": \"ASSIGNMENT-NAME\"}"クラスター・グループに構成を割り当てる要求の例。
curl -X POST "https://containers.cloud.ibm.com/global/v2/storage/satellite/createAssignment" -H "accept: application/json" -H "Authorization: Bearer TOKEN" -H "Content-Type: application/json" -d "{ \"channelName\": \"CONFIGURATION-NAME\", \"cluster\": \"string\", \"groups\": [ \"CLUSTER-GROUP\" ], \"name\": \"ASSIGNMENT-NAME\"}" -
変数を自分の詳細に置き換え、要求を実行します。
-
割り当てをリストして、割り当てが作成されたことを確認します。
curl -X GET "https://containers.cloud.ibm.com/global/v2/storage/satellite/getAssignments" -H "accept: application/json" -H "Authorization: Bearer TOKEN"
コンソールでのストレージ割り当ての更新
Satellite コンソール を使用して、割り当てに最新のパッチ更新を適用できます。
-
Satellite コンソールの 「ロケーション」 ページで、ロケーションを選択します。
-
「ストレージ」 タブをクリックして、構成を表示します。
-
更新したい設定をクリックしてください。
-
「情報」 (i) アイコンをクリックして、最新のリビジョンまたはパッチを適用します。
-
オプション: ストレージ割り当ての自動パッチ更新を有効にします。 自動パッチ更新を有効にすると、割り当てに常に最新のセキュリティー・フィックスが適用されます。
自動パッチ更新を有効にした場合でも、メジャー更新を手動で適用する必要があります。
CLI での割り当ての手動アップグレード
最新のストレージ・テンプレート・リビジョンを使用するように割り当てをアップグレードします。
-
Satellite ストレージ割り当てをリストし、アップグレードする Satellite 割り当てを書き留めます。
ibmcloud sat storage assignment ls -
Satellite ストレージ・テンプレートをリストして、使用可能な最新バージョンを確認します。
ibmcloud sat storage template ls -
Satellite 割り当てをアップグレードします。
割り当てをアップグレードするコマンドの例。
ibmcloud sat storage assignment upgrade --assignment ASSIGNMENT
CLI での構成および割り当ての自動パッチ更新の有効化
sat storage assignment autopatch enable CLI を使用して、割り当ての自動パッチ更新を有効にすることができます。 自動パッチ更新を有効にすると、最新のストレージ・テンプレート・リビジョン (パッチ) が自動的に適用されます。 ただし、メジャー更新は手動で適用する必要があります。
-
Satellite ストレージ構成をリストします。 設定IDをメモしておいてください。
ibmcloud sat storage assignment ls -
以下のいずれかのコマンド例を実行して、ご使用の構成とその関連割り当てに対して自動パッチ更新を有効にします。 前の手順で取得した設定IDを入力してください。
割り当ての自動パッチ更新を有効にするコマンドの例。
ibmcloud sat storage assignment autopatch enable --config CONFIG (--all | --assignment ASSIGNMENT-ID [--assignment ASSIGNMENT-ID])指定された構成下のすべてのストレージ割り当てに対して自動パッチ更新を有効にするコマンド例。
ibmcloud sat storage assignment autopatch enable --config CONFIG --all特定の構成下のすべての割り当てに対して自動パッチ更新を無効にするコマンドの例。
ibmcloud sat storage assignment autopatch disable --config CONFIG --all単一の割り当ておよび特定の構成に対して自動パッチ更新を無効にするコマンドの例。
ibmcloud sat storage assignment autopatch disable --config CONFIG --assignment ASSIGNMENT-ID複数の割り当ておよび特定の構成に対する自動パッチ更新を無効にするコマンド例。
ibmcloud sat storage assignment autopatch disable --config CONFIG --assignment ASSIGNMENT-ID --assignment ASSIGNMENT-ID
CLI での構成の手動アップグレード
Satellite のストレージ構成をアップグレードすることで、同じメジャーバージョン内で最新のストレージテンプレートのリビジョンを取得できます。
-
Satellite ストレージ構成をリストし、アップグレードする Satellite 構成を書き留めます。
ibmcloud sat storage config ls -
Satellite 構成をアップグレードします。 更新されるのは構成のみであることに注意してください。 この構成を使用する割り当てをアップグレードする場合は、
--include-assignmentsオプションを指定するか、assignment updateコマンドを使用して各割り当てを手動で更新することができます。構成を最新リビジョンにアップグレードするためのコマンド例。
ibmcloud sat storage config upgrade --config CONFIG [--include-assignments]構成とその関連割り当てを最新リビジョンにアップグレードするためのサンプル・コマンド。
ibmcloud sat storage config upgrade --config CONFIG --include-assignments
API での構成と割り当てのアップグレード
/v2/storage/satellite/updateAssignment API を使用して、新しいクラスターまたはクラスター・グループで割り当てを更新できます。 改訂の更新を適用するには、 updateConfigVersion を true に設定します。
-
以下の要求例をコピーし、更新するクラスター・グループおよび割り当ての変数を置き換えます。
curl -X PATCH "https://containers.cloud.ibm.com/global/v2/storage/satellite/updateAssignment" -H "accept: application/json" -H "Authorization: Bearer TOKEN" -H "Content-Type: application/json" -d "{ \"groups\": [ \"CLUSTER-GROUPS\" ], \"name\": \"ASSIGNMENT-NAME\", \"updateConfigVersion\": true, \"uuid\": \"ASSIGNMENT-ID\"}" -
要求を実行します。
-
更新を確認するために割り当ての詳細を取得します。
curl -X GET "https://containers.cloud.ibm.com/global/v2/storage/satellite/getAssignment?uuid=ASSIGNMENT-ID" -H "accept: application/json" -H "Authorization: Bearer TOKEN"
API での割り当ての自動パッチ更新の有効化
/v2/storage/satellite/setAssignmentAutoupgrade API を使用して、割り当ての自動パッチ更新を有効にすることができます。 自動パッチ更新を有効にすると、最新のストレージ・テンプレート・リビジョン (パッチ) が自動的に適用されます。 ただし、メジャー更新は手動で適用する必要があります。
-
以下の要求例をコピーし、更新するクラスター・グループおよび割り当ての変数を置き換えます。
curl -X PATCH "https://containers.cloud.ibm.com/global/v2/storage/satellite/setAssignmentAutoupgrade" -H "accept: application/json" -H "Authorization: Bearer TOKEN" -H "Content-Type: application/json" -d { "config": "string", "controller": "string", "autopatch": boolean,"assignment" : { "all": boolean, "uuid": ["string", "string", ...], } } -
要求を実行します。
-
割り当ての詳細を取得して、アップグレードを検証します。
curl -X GET "https://containers.cloud.ibm.com/global/v2/storage/satellite/getAssignment?uuid=ASSIGNMENT-ID" -H "accept: application/json" -H "Authorization: Bearer TOKEN"
ローカルストレージを使用するアプリのデプロイ
ローカルストレージの設定を作成し、それをクラスタに割り当てた後、そのローカルブロックストレージを利用するアプリを作成できます。
永続ボリュームにラベルを追加して、PVC を特定の永続ボリュームにマップできます。 詳細については、 Kubernetes のセレクタに関するドキュメントを参照してください。
-
以下の PVC の YAML ファイルを
local-pvc.yamlという名前でローカル・マシンに保存します。kind: PersistentVolumeClaim apiVersion: v1 metadata: name: local-pvc spec: accessModes: - ReadWriteOnce volumeMode: Block resources: requests: storage: 20Gi # Important: Ensure that size of your claim is not larger than the local disk. storageClassName: sat-local-block-gold -
クラスター内に PVC を作成します。
oc create -f local-pvc.yaml -
PVC が作成されたことを確認します。
volumeBindingModeストレージ・クラスのsat-local-block-goldがwaitForFirstConsumerであることに注意してください。oc get pvc | grep localストレージを搭載したワーカー・ノードにポッドが確実にスケジュールされるようにする、またはストレージを必要とするアプリが他のポッドからプリエンプトされないようにするには、
nodeAffinityを指定し、ポッドの優先度をセットアップしてください。 詳細については、 Kubernetes のドキュメントで、 ポッドの優先度とプリエンプション、および ノードアフィニティの設定についてご確認ください。 -
ローカル・ストレージの PVC を使用するアプリ・ポッドをデプロイします。 以下のサンプル・アプリの YAML を
app.yamlという名前のファイルにしてローカル・マシンに保存します。 この例では、nodeAffinityという仕様により、このポッドは指定されたラベルを持つワーカーノードにのみスケジューリングされることが保証されます。apiVersion: v1 kind: Pod metadata: name: app spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: storage # Enter the 'key' of the worker node label created earlier. operator: In values: - local-block # Enter the 'value' of the worker label that you created earlier. containers: - name: nginx image: nginx volumeDevices: - name: data devicePath: "/dev/nvme2n1" # Enter the path to your local device. volumes: - name: data persistentVolumeClaim: claimName: local-pvc -
クラスター内にアプリ・ポッドを作成します。
oc create -f app.yaml -
アプリ・ポッドにログインし、ローカル・ディスクに書き込めることを確認します。
kubectl exec <pod_name> -it bash -
ディレクトリーを
devフォルダーに変更します。cd dev -
ls -lR <device-path>コマンドを実行して、デバイスの詳細を確認するとともに、アプリのポッドがブロックデバイスに対して読み書き権限を持っていることを確認してください。これは、コマンドの出力に「brw」と表示されることで確認できます。ls -lR /dev/nvme2n1出力例
brw-rw-rw-. 1 root disk 202, 32 Mar 3 21:24 /dev/nvme2n1 -
オプション 以下のコマンドを実行して、ブロック・デバイスにデータを書き込みます。
- アプリにマウントしたローカルストレージデバイスに、
"block_data"を書き込んでください。<device-path>を、お使いのストレージデバイスのパスに置き換えてください。 例:/dev/nvme2n1。
kubectl exec <pod_name> -- bash -c "echo "block_data" | dd conv=unblock of=<device-path>" ``` 2. データがデバイスに書き込まれていることを確認します。 `<device-path>` をストレージ・デバイスへのパスに置き換えます。 例: `/dev/nvme2n1`。 ```sh {: pre} kubectl exec <pod_name> -- bash -c "od -An -c -N 10 <device-path>" ``` 出力例 ```sh {: screen} b l o c k _ d a t a ``` - アプリにマウントしたローカルストレージデバイスに、
-
testポッドを削除します。oc delete pod <pod_name>
コンソールからストレージ構成を削除する
- Satellite ストレージ・ダッシュボードから、削除するストレージ構成を選択します。
- [アクション ] > [ 削除 ] を選択します。
- ストレージ構成の名前を入力します。
- **「削除」**を選択します。
コマンドラインからローカルストレージの設定を削除する
-
local-storage名前空間のリソースをリストします。 ストレージ割り当てを削除すると、これらのリソースは削除されます。oc get all -n local-storage出力例
NAME READY STATUS RESTARTS AGE pod/local-disk-local-diskmaker-clvg6 1/1 Running 0 29h pod/local-disk-local-diskmaker-kqddq 1/1 Running 0 29h pod/local-disk-local-diskmaker-p6z9q 1/1 Running 0 29h pod/local-disk-local-provisioner-dw5g7 1/1 Running 0 29h pod/local-disk-local-provisioner-hxd9n 1/1 Running 0 29h pod/local-disk-local-provisioner-tfg95 1/1 Running 0 29h pod/local-storage-operator-df4994656-7826l 1/1 Running 0 29h NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/local-storage-operator ClusterIP 172.21.147.17 <none> 60000/TCP 29h NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/local-disk-local-diskmaker 3 3 3 3 3 <none> 29h daemonset.apps/local-disk-local-provisioner 3 3 3 3 3 <none> 29h NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/local-storage-operator 1/1 1 1 29h NAME DESIRED CURRENT READY AGE replicaset.apps/local-storage-operator-df4994656 1 1 1 29h -
ストレージ割り当てをリストし、クラスターに使用していた割り当てを見つけます。
ibmcloud sat storage assignment ls (--cluster CLUSTER | --config CONFIG | --location LOCATION | --service-cluster-id CLUSTER) -
割り当てを削除します。 割り当てを削除すると、そのストレージ割り当てに含まれていたすべてのクラスターから、ローカル・ストレージのドライバー・ポッドとストレージ・クラスが削除されます。
ibmcloud sat storage assignment rm --assignment <assignment_ID> -
local-storage名前空間のリソースをリストし、ローカル・ストレージ・ドライバー・ポッドが削除されていることを確認します。oc get all -n local-storage出力例
No resources found in local-storage namespace. -
クラスターでストレージ・クラスをリストし、ローカル・ストレージ・クラスが削除されていることを確認します。
oc get sc -
オプション: ストレージ構成を削除します。
- ストレージ構成をリストします。
ibmcloud sat storage config ls ``` 2. ストレージ構成を削除します。 ```sh {: pre} ibmcloud sat storage config rm --config <config_name> ``` -
PVC をリストし、削除する PVC の名前をメモします。
oc get pvc -
現在 PVC がマウントされているすべてのポッドを削除します。
- 削除する PVC を現在マウントしているポッドをすべてリストします。 ポッドが返されなければ、現在その PVC を使用しているポッドはありません。
oc get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.volumes[*]}{.persistentVolumeClaim.claimName}{" "}{end}{end}' | grep "<pvc_name>" ``` 出力例 ```sh {: screen} app sat-local-block-gold ``` 2. PVC を使用するポッドを削除します。 ポッドがデプロイメントの一部である場合は、デプロイメントを削除します。 ```sh {: pre} oc delete pod <pod_name> ``` ```sh {: pre} oc delete deployment <deployment-name> ``` 3. ポッドまたはデプロイメントが削除されたことを確認します。 ```sh {: pre} oc get pods ``` ```sh {: pre} oc get deployments ``` -
PVC を削除します。 IBM 提供のローカル・ブロック・ストレージ・クラスはすべて
Retain再利用ポリシーを使用して指定されているので、アプリやデプロイメントを削除しても、PV と PVC は自動的に削除されません。oc delete pvc <pvc-name> -
PVC が削除されたことを確認します。
oc get pvc -
PV をリストし、削除する PV の名前をメモします。
oc get pv -
PV を削除します。 PV を削除すると、他のワークロードにディスクを使用できるようになります。
oc delete pv <pv-name> -
PV が削除されたことを確認します。
oc get pv
パラメーターのリファレンス
1.0.0 パラメーター・リファレンス
| 表示名 | CLI オプション | タイプ | 説明 | デフォルト値 |
|---|---|---|---|---|
| ファイル・ストレージ・ドライバーのインストール | install-local-storage-file |
構成 | ファイル・ストレージ・ドライバーをインストールするには、「true」に設定します。 | true |
| ファイル・ストレージの自動ボリューム・ディスカバリー | auto-discover-devices-file |
構成 | ファイル・ストレージのワーカー・ノード上のボリュームを自動的にディスカバーして使用する場合は、「true」に設定します。 | false |
| ファイル・ストレージ・ワーカー・ノード・ラベル鍵 | file-nodes-label-key |
構成 | ファイル・ストレージに使用するワーカー・ノード・ラベル「key=value」の「key」。 | 該当なし |
| ファイル・ストレージ・ワーカー・ノード・ラベル値 | file-nodes-label-value |
構成 | ファイル・ストレージに使用するワーカー・ノード・ラベル「key=value」の「value」。 | 該当なし |
| ファイル・ストレージのデバイス・パス | file-devicepath |
構成 | ファイル・ストレージに使用するワーカー・ノード上のストレージ・デバイスへのパス。 例: 「/dev/sdc」。 このオプションは、「auto-discover-devices-file」が「false」に設定されている場合に必要です。 | 該当なし |
| ファイル・システム・タイプ | fstype |
構成 | ファイル・システムのタイプ。 「ext3」、「ext4」、または「xfs」を指定します。 | ext4 |
| ブロック・ストレージ・ドライバーのインストール | install-local-storage-block |
構成 | ブロック・ストレージ・ドライバーをインストールするには、「true」に設定します。 | true |
| ブロック・ストレージの自動ボリューム・ディスカバリー | auto-discover-devices-block |
構成 | ブロック・ストレージのワーカー・ノード上のボリュームを自動的にディスカバーして使用する場合は、「true」に設定します。 | false |
| ブロック・ストレージ・ワーカー・ノード・ラベル鍵 | block-nodes-label-key |
構成 | ブロック・ストレージに使用するワーカー・ノード・ラベル「key=value」の「key」。 | 該当なし |
| ブロック・ストレージ・ワーカー・ノード・ラベル値 | block-nodes-label-value |
構成 | ブロック・ストレージに使用するワーカー・ノード・ラベル「key=value」の「value」。 | 該当なし |
| ローカル・ストレージ・ブロックのデバイス・パス | block-devicepath |
構成 | ブロック・ストレージに使用するワーカー・ノード上のストレージ・デバイスへのパス。 例: 「/dev/sdc」。 このオプションは、「auto-discover-devices-block」が false に設定されている場合に必要です。 | 該当なし |