以下の解決策を参照してください。
説明
解決
永続ボリューム
永続ボリュームは、Kubernetesクラスター内のストレージの一部です。PersistentVolumesは、ノードのようなクラスターレベルのリソースであり、どの名前空間にも属していません。管理者によってプロビジョニングされ、特定のファイルサイズがあります。このように、Kubernetesにアプリをデプロイする開発者は、基盤となるインフラストラクチャを知る必要がありません。開発者がアプリケーション用に一定量の永続ストレージを必要とする場合、システム管理者は、簡単な方法でプロビジョニングされたPersistentVolumeを消費するようにクラスターを構成します。
永続ボリュームの作成
種類：PersistentVolumeapiVersion：v1metadata：name：app-dataspec：capacity：＃作成するPVの容量を定義しますストレージ：2Gi＃accessModesを要求するために結び付けるストレージの量：＃作成するボリュームの権限を定義します--ReadWriteMany hostPath：path： "/ srv / app-data"＃ボリュームを作成するパスチャレンジ
* ReadWriteMany、ストレージクラス名という名前の永続ボリュームを作成します
共有、2Giのストレージ容量とホストパス

2.ファイルを保存し、永続ボリュームを作成します。
投稿用画像

3.永続ボリュームを表示します。

*永続的なボリュームステータスが利用可能です。つまり、利用可能であり、まだマウントされていません。このステータスは、persistentVolumeをpersistentVolumeClaimにマウントすると変更されます。
PersistentVolumeClaim
実際のエコシステムでは、システム管理者がPersistentVolumeを作成し、次に開発者がポッドで参照されるPersistentVolumeClaimを作成します。PersistentVolumeClaimは、persistentVolumeから必要な最小サイズとアクセスモードを指定することによって作成されます。
チャレンジ
*上記で作成した永続ボリュームを要求する永続ボリュームクレームを作成します。クレームは2Giを要求する必要があります。PersistentVolumeClaimが以前に作成したpersistentVolumeと同じstorageClassNameを持っていることを確認してください。
種類：PersistentVolumeapiVersion：v1metadata：名前：
仕様：
accessModes：-ReadWriteMany
リクエスト：ストレージ：2Gi
storageClassName：共有
2.PVCを保存して作成します
njerry191 @ cloudshell：〜（extreme-clone-2654111）$ kubect1 create -f app-data.yaml persistvolumeclaim / app-data created
3.PVCを表示します
投稿用画像

4.最初に作成したpvで何が変更されたかを見てみましょう。
投稿用画像

ステータスが利用可能からバインドに変更されました。
5.パス/var/ app/configを使用して永続ボリュームクレームをマウントするために使用されるイメージnginxを使用してmyappという名前の新しいポッドを作成します。
クレームのマウント
apiVersion：v1kind：Podmetadata：creationTimestamp：null name：app-dataspec：volumes：-name：congigpvc persistenVolumeClaim：claimName：app-data container：-image：nginx name：app volumeMounts：-mountPath： "/ srv / app-data"名前：configpvc