以下の解決策を参照してください。
説明
解決
永続ボリューム
永続ボリュームは、Kubernetes クラスター内のストレージの一部です。PersistentVolume はノードのようなクラスター レベルのリソースであり、どの名前空間にも属しません。これは管理者によってプロビジョニングされ、特定のファイル サイズを持ちます。この方法により、Kubernetes にアプリをデプロイする開発者は、基盤となるインフラストラクチャについて知る必要がなくなります。開発者がアプリケーションに一定量の永続ストレージを必要とする場合、システム管理者は、プロビジョニングされた PersistentVolume を簡単な方法で消費できるようにクラスターを構成します。
永続ボリュームの作成
kind: PersistentVolumeapiVersion: v1metadata: name: spec: Capacity: # 作成している PV の容量を定義します storage: 2Gi # 要求するために結び付けているストレージの量 accessModes: # 作成しているボリュームの権限を定義します - ReadWriteMany " #ボリュームを作成するパス チャレンジ ReadWriteMany という名前の永続ボリューム、共有ストレージ クラス名、2Gi のストレージ容量、およびホスト パスを作成します。
2. ファイルを保存し、永続ボリュームを作成します。
投稿用画像
3. 永続ボリュームを表示します。
永続ボリュームのステータスは「利用可能」です。これは、ボリュームが利用可能であり、まだマウントされていないことを意味します。このステータスは、persistentVolume をpersistentVolumeClaim にマウントすると変わります。
PersistentVolumeClaim
実際のエコシステムでは、システム管理者が Persistent Volume を作成し、開発者がポッド内で参照される Persistent VolumeClaim を作成します。PersistentVolumeClaim は、persistentVolume に必要な最小サイズとアクセス モードを指定することによって作成されます。
チャレンジ
上で作成した Persistent Volume を要求する Persistent Volume Claim を作成します。クレームでは 2Gi を要求する必要があります。Persistent Volume Claim の storageClassName が、以前に作成したpersistentVolume と同じであることを確認してください。
種類: PersistentVolumeapiVersion: v1metadata: name:
仕様:
アクセスモード: - ReadWriteMany
リクエスト: ストレージ: 2Gi
storageClassName: 共有
2. PVC を保存して作成します
njerry191@cloudshell:~ (extreme-clone-2654111)$ kubect1 create -f app-data.yamlpersistentvolumeclaim/app-data created
3.PVCを表示する
投稿用画像
4. 最初に作成した pv で何が変わったのか見てみましょう。
投稿用画像
ステータスが「利用可能」から「バウンド」に変わりました。
5. イメージ nginx を使用して myapp という名前の新しいポッドを作成します。このポッドは、パス /var/app/config で Persistent Volume Claim をマウントするために使用されます。
請求を行う
apiVersion:v1kind:Podmetadata:creationTimestamp:null name:app-dataspec:volumes: - name:congigpvcpersistenVolumeClaim:claimName:app-data コンテナー: - image: nginx name: app volumeMounts: - mountPath: "/srv/app-data "名前: configpvc
