この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。

永続ストレージの仕組み

永続ボリューム（PV）はKubernetesクラスター内のストレージの一部であり、永続ボリュームクレーム（PVC）はストレージのリクエストです。

Kubernetesで永続ストレージを使用する方法は2つあります：

  • 既存の永続ボリュームを使用する

  • 新しい永続ボリュームを動的にプロビジョニングする

既存のPVを使用するには、アプリケーションがPVにバインドされたPVCを使用する必要があり、PVはPVCが要求する最小リソースを含む必要があります。

動的ストレージプロビジョニングのために、アプリケーションはストレージクラスにバインドされたPVCを使用する必要があります。ストレージクラスは、新しい永続ボリュームをプロビジョニングするための権限を含んでいます。

新しい永続ストレージと既存の永続ストレージの設定

詳細については、 ストレージに関する公式Kubernetesドキュメントを参照してください。

永続ボリューム要求について

永続ボリューム要求（PVC）は、クラスターからストレージリソースを要求するオブジェクトです。これは、あなたのデプロイメントがストレージアクセスのために引き換えられるバウチャーに似ています。PVCはワークロードにボリュームとしてマウントされ、ワークロードが指定された永続ストレージのシェアを要求できるようにします。

永続ストレージにアクセスするには、ポッドにPVCがボリュームとしてマウントされている必要があります。このPVCにより、あなたのデプロイメントは外部の場所にデータを保存できるようになり、ポッドが障害で停止した場合でも、新しいポッドに置き換えられ、外部に保存されたデータに引き続きアクセスでき、障害が発生しなかったかのように動作します。

各Rancherプロジェクトには、作成したPVCのリストが含まれており、リソース  ワークロード  ボリュームから利用できます。将来のデプロイメント作成時に、これらのPVCを再利用できます。

PVCは新しい永続ストレージと既存の永続ストレージの両方に必要です。

PVCは、ワークロードが既存のストレージを使用する場合でも、要求に応じて新しいストレージを動的にプロビジョニングする必要がある場合でも、ポッドが永続ストレージを使用するために必要です。

ワークロードのために既存のストレージを設定する場合、ワークロードはPVCをマウントし、これはPVを参照し、既存のストレージインフラストラクチャに対応します。

ワークロードが新しいストレージを要求する場合、ワークロードはPVCをマウントし、これはストレージクラスを参照し、新しいPVとその基盤となるストレージインフラストラクチャを作成する能力を持っています。

Rancherでは、プロジェクト内に好きなだけPVCを作成できます。

デプロイメントを作成する際、またはデプロイメントが稼働した後に、PVCをデプロイメントにマウントすることができます。

PVCとPVを使用して既存のストレージを設定する

ポッドは ボリューム,にデータを保存できますが、ポッドが失敗した場合、そのデータは失われます。この問題を解決するために、Kubernetesは永続ボリューム（PV）を提供します。これは、ポッドがアクセスできる外部ストレージディスクまたはファイルシステムに対応するKubernetesリソースです。ポッドがクラッシュした場合、その代替ポッドは永続ストレージ内のデータにアクセスでき、データ損失はありません。

PVは、オンプレミスでホストされる物理ディスクまたはファイルシステム、またはAmazon EBSやAzure Diskなどのベンダーホストのストレージリソースを表すことができます。

Rancherで永続ボリュームを作成しても、ストレージボリュームは作成されません。既存のボリュームにマッピングされるKubernetesリソースのみが作成されます。したがって、Kubernetesリソースとして永続ボリュームを作成する前に、ストレージがプロビジョニングされている必要があります。

重要:

PVはクラスターのレベルで作成されるため、マルチテナントクラスターでは、別々のネームスペースにアクセスできるチームが同じPVにアクセスできる可能性があります。

PVをPVCにバインドする

ポッドが永続ストレージを使用するように設定されると、他のKubernetesボリュームと同様にマウントされる永続ボリュームクレーム（PVC）をマウントします。各PVCが作成されると、Kubernetesマスターはそれをストレージのリクエストと見なし、PVCの最小リソース要件に一致するPVにバインドします。すべてのPVCがPVにバインドされることが保証されているわけではありません。Kubernetesの ドキュメント,によると、

一致するボリュームが存在しない場合、クレームは無期限にバインドされないままとなります。一致するボリュームが利用可能になると、クレームはバインドされます。例えば、50GiのPVが多数プロビジョニングされたクラスターは、100Giを要求するPVCと一致しません。100GiのPVがクラスターに追加されると、PVCはバインドされることができます。

言い換えれば、無限にPVCを作成できますが、KubernetesコントロールプレーンがPVCが要求するディスクスペース以上の十分なPVを見つけられた場合にのみ、PVにバインドされます。

新しいストレージを動的にプロビジョニングするには、ポッドにマウントされたPVCが永続ボリュームではなくストレージクラスに対応している必要があります。

PVCとストレージクラスを使用して新しいストレージをプロビジョニングする

ストレージクラスを使用すると、インフラストラクチャプロバイダーで永続ストレージを最初に作成することなく、PVを動的に作成できます。

たとえば、ワークロードがPVCにバインドされ、PVCがAmazon EBSストレージクラスを参照している場合、ストレージクラスは動的にEBSボリュームと対応するPVを作成できます。

Kubernetesマスターは、新しく作成されたPVをワークロードのPVCにバインドし、ワークロードが永続ストレージを使用できるようにします。