3.4. 永続ボリューム要求
各 PersistentVolumeClaim オブジェクトには、永続ボリューム要求 (PVC) の仕様およびステータスである spec および status が含まれます。以下が例になります。
PersistentVolumeClaim オブジェクト定義の例
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: myclaim 1 spec: accessModes: - ReadWriteOnce 2 resources: requests: storage: 8Gi 3 storageClassName: gold 4 status: ...
3.4.1. ストレージクラス
要求は、ストレージクラスの名前を storageClassName 属性に指定して特定のストレージクラスをオプションでリクエストできます。リクエストされたクラスの PV、つまり PVC と同じ storageClassName を持つ PV のみが PVC にバインドされます。クラスター管理者は 1 つ以上のストレージクラスを提供するように動的プロビジョナーを設定できます。クラスター管理者は、PVC の仕様に一致する PV をオンデマンドで作成できます。
Cluster Storage Operator は、使用されるプラットフォームに応じてデフォルトのストレージクラスをインストールする可能性があります。このストレージクラスは Operator によって所有され、制御されます。アノテーションとラベルを定義するほかは、これを削除したり、変更したりすることはできません。異なる動作が必要な場合は、カスタムストレージクラスを定義する必要があります。
クラスター管理者は、すべての PVC にデフォルトストレージクラスを設定することもできます。デフォルトのストレージクラスが設定されると、PVC は "" に設定された StorageClass または storageClassName アノテーションがストレージクラスなしの PV にバインドされるように明示的に要求する必要があります。
複数のストレージクラスがデフォルトとしてマークされている場合、PVC は storageClassName が明示的に指定されている場合にのみ作成できます。そのため、1 つのストレージクラスのみをデフォルトとして設定する必要があります。
3.4.2. アクセスモード
要求は、特定のアクセスモードのストレージを要求する際にボリュームと同じ規則を使用します。
3.4.3. リソース
要求は、Pod の場合のようにリソースの特定の数量を要求できます。今回の例では、ストレージに対する要求です。同じリソースモデルがボリュームと要求の両方に適用されます。
3.4.4. ボリュームとしての要求
Pod は要求をボリュームとして使用することでストレージにアクセスします。この要求を使用して、Pod と同じ namespace 内に要求を共存させる必要があります。クラスターは Pod の namespace で要求を見つけ、これを使用して要求をサポートする PersistentVolume を取得します。以下のように、ボリュームはホストにマウントされ、Pod に組み込まれます。
ホストおよび Pod のサンプルへのボリュームのマウント
kind: Pod
apiVersion: v1
metadata:
name: mypod
spec:
containers:
- name: myfrontend
image: dockerfile/nginx
volumeMounts:
- mountPath: "/var/www/html" 1
name: mypd 2
volumes:
- name: mypd
persistentVolumeClaim:
claimName: myclaim 3
