【Kubernetesストレージ】Persistent Storage PVとPVCの詳細解説

1. PV および PVC 永続ストレージ理論

中国の公式参考文書:

1. PV と PVC とは何ですか?

  • PersistentVolume (PV)はクラスター内のストレージの一部であり、NFS、iSCSI、ローカル ストレージなど、管理者によって構成されたり、ストレージ クラスを使用して動的に構成されたりすることができますPV は、ストレージ容量、アクセス モード、永続ストレージ タイプなどの属性を定義します。PV のライフサイクルは Pod から独立しており、Pod が削除されても PV は残り、他の Pod で使用できます。
  • PersistentVolumeClaim (PVC)は永続ストレージ ボリュームです。ポッドの作成時に PVC タイプのストレージ ボリュームを定義できます。PVC は、ローカル ストレージ、ネットワーク ストレージ、クラウド ストレージなど、さまざまなタイプの永続ストレージにアクセスするために使用できます。これらのリソースの実際の場所や種類を気にする必要がなく、PVC を使用すると、アプリケーションの柔軟性と移植性が向上し、同時にストレージ リソースの使用率も向上します。
  • PVC と PV は 1 対 1 に対応しており、PV が PVC にバインドされている場合、他の PVC からは使用できません。

2. 太陽光発電の供給方法

2 つのタイプは静的と動的です。

  • 静的プロビジョニング: 管理者はPV オブジェクトを手動で作成し、それを特定のストレージ バックエンドにバインドします。その後、ポッドは PVC (Persistent Volume Claim) を通じて PV へのバインドを要求できます。
  • 動的プロビジョニング: 管理者は StorageClass を通じてストレージ バックエンドのセットを定義すると、Pod は PVC リクエストを通じて StorageClass にバインドでき、K8 は自動的にPV オブジェクトを作成し、それを利用可能なストレージ バックエンドにバインドします。

3. 太陽光発電と塩ビのリサイクル戦略

ポッドを作成するときに、ストレージ ボリュームとして pvc を使用すると、pv にバインドされます。ポッドを削除すると、pvc と pv の間のバインドが解除されます。バインドされた pv ボリューム内のデータを処理する方法発売後のPVC 以下のタイプ:

Kubernetes には 3 つの PV リサイクル戦略があります。

  • 保持: PV を保持しますが、基礎となるストレージ リソースは削除しません。これは、PV 内のデータはまだ存在しますが、手動でクリーンアップする必要があることを意味します。
  • 削除: PV および基礎となるストレージ リソースを削除します。これは、PV 内のデータが完全に削除されることを意味します。
  • リサイクル: PV 内のデータは削除されますが、基礎となるストレージ リソースは削除されません。これは、PV 内のデータは消去されますが、基礎となるストレージ リソースは再利用できることを意味します。(推奨されません。1.15 で削除される可能性があります)

Kubernetes には 2 つの PVC リサイクル戦略があります。

  • 保持: PVC は保持されますが、基礎となるストレージ リソースは削除されません。これは、PVC 内のデータはまだ存在しますが、手動でクリーンアップする必要があることを意味します。
  • 削除: PVC および基礎となるストレージ リソースを削除します。これは、PVC 内のデータが完全に削除されることを意味します。

PVC のリサイクル ポリシーは、PVC が拘束されている PV のリサイクル ポリシーと一致する必要があることに注意してください。たとえば、PV のリサイクル ポリシーが Retain の場合、PVC のリサイクル ポリシーも Retain にする必要がありますそうしないと、データの損失やストレージ リソースの漏洩が発生する可能性があります。

2. ケース: PV および PVC 永続ストレージ ケースのデモンストレーション

1. NFSサーバーの構築

PV はストレージとして NFS を使用します。

注: K8S クラスターのすべてのノードをインストールする必要があります。nfs-utils

yum install nfs-utils -y
mkdir /data/volumes/v{
    
    1..3} -p

vim /etc/exports
/data/volumes/v1 *(rw,no_root_squash)
/data/volumes/v2 *(rw,no_root_squash)
/data/volumes/v3 *(rw,no_root_squash)

構成をロードして有効にし、NFS サービスを開始します

exportfs -arv
systemctl enable nfs --now

NFS が他の Node ノードに正常にマウントできるかどうかをテストします。

yum install nfs-utils -y
mkdir /test
mount 16.32.15.200:/data/volumes/v1 /test

df -hT /test/

[外部リンク画像の転送に失敗しました。ソース サイトには盗難防止リンク メカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-ekJ4U0X0-1686473061750) (D:\MD Archives\IMG\image-20230611135004109)。 png)]

OK、上図に示すように、NFS は正常にマウントできています。これは、これまでの NFS 構成に問題がないことを意味します。

2. PV を作成し、NFS を使用してストレージを共有する

それぞれ異なるディレクトリと異なるアクセス モジュールを使用して 3 つの PV を作成します。YAML は次のとおりです。

cat pv.yaml 

---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-1
  labels:
    app: pv-1
spec:
  nfs:
    path: /data/volumes/v1   # PV使用NFS路径
    server: 16.32.15.200     # NFS 服务端IP地址
  accessModes: ["ReadWriteOnce"]  # 访问模式: ReadWriteOnce,卷可以被一个节点以读写方式挂载
  capacity:
    storage: 1Gi                  # 存储大小
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-2
  labels:
    app: pv-2
spec:
  nfs:
    path: /data/volumes/v2
    server: 16.32.15.200
  accessModes: ["ReadOnlyMany"] # 访问模式: ReadOnlyMany,可以被多个节点只读方式挂载
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-3
  labels:
    app: pv-3
spec:
  nfs:
    path: /data/volumes/v3
    server: 16.32.15.200
  accessModes: ["ReadWriteMany"] # 访问模式: ReadWriteMany,可以被多个节点读写方式挂载
  capacity:
    storage: 3Gi
...

アクセスモードの説明:

  • ReadWriteOnce: 読み取り/書き込みモードのノードによってマウントされます (公式の説明ですが、反映されません。バグのはずです)。
  • ReadOnlyMany: 複数のノードによって読み取り専用モードでマウントされます。
  • ReadWriteMany: 複数のノードによって読み取り/書き込みモードでマウントされます。

YAML ファイルを実行します。

kubectl apply -f pv.yaml

作成された PV リソースを表示します。

kubectl get pv

[外部リンク画像の転送に失敗しました。ソース サイトには盗難防止リンク メカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-qIdR6GdY-1686473061751) (D:\MD Archives\IMG\image-20230611140856919)。 png)]

3. PVC を作成し、PV にバインドします。

次のように 3 つの PVC を作成し、上記の 3 つの PV を YAML でバインドします。

cat pvc.yaml 
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-1
  labels:
    app: pvc-1
spec:
  accessModes: ["ReadWriteOnce"]   # PVC访问模式,必须和PV访问模式一致
  selector:
    matchLabels:
      app: pv-1                   # 标签选择器,选择具有 app=pv-1 PV绑定
  resources: 
    requests: 
      storage: 1Gi                # 容量,必须和PV容量保持一致
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-2
  labels:
    app: pvc-2
spec:
  accessModes: ["ReadOnlyMany"]
  selector:
    matchLabels:
      app: pv-2
  resources:
    requests:
      storage: 2Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-3
  labels:
    app: pvc-3
spec:
  accessModes: ["ReadWriteMany"]
  selector:
    matchLabels:
      app: pv-3
  resources:
    requests:
      storage: 3Gi
...

YAML マニフェスト ファイルを実行します。

kubectl apply -f pvc.yaml

PVC が PV に関連付けられているかどうかを確認します。

kubectl get pvc

[外部リンク画像の転送に失敗しました。ソース サイトにはリーチ防止メカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-TQTsbz18-1686473061752) (D:\MD Archives\IMG\image-20230611151351851.png) )]

4. ポッドを作成し、PVC ボリュームをマウントします

cat pod-pvc.yaml 
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pvc-test
  labels:
    app: pvc-test
spec:
  replicas: 3
  selector:
    matchLabels:
      app: pvc-test
  template:
    metadata:
      labels:
        app: pvc-test
    spec:
      volumes:
      - persistentVolumeClaim:     # 使用PVC类型
          claimName: pvc-2         # 指定使用PVC名字
        name: web-html-path        # 卷名称
      containers:
      - name: pvc-test
        image: nginx
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - name: web-html-path      # 使用卷名称,和上面卷名称对应上
          mountPath: /usr/share/nginx/html  # 容器内挂载目录

YAML ファイルを実行します。

kubectl apply -f pod-pvc.yaml 

読み取り専用権限を使用しておりpvc-2、対応するディレクトリ/data/volumes/v2/にindex.htmlファイルを追加します。

echo "PVC-DEMO" > /data/volumes/v2/index.html

ポッド Web サイトにアクセスしてください。

kubectl get pods -o wide

[外部リンク画像の転送に失敗しました。ソース サイトにはリーチ防止メカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-NZN6DVxq-1686473061752) (D:\MD Archives\IMG\image-20230611161521242.png) )]

コンテナに入り、試してみるファイルを作成してみましょう。

kubectl exec -it pvc-test-d65964fd4-jmkmg -- /bin/bash

下の図に示すように、私は読み取り専用 PVC を使用しています。コンテナー内にファイルを作成する権限はないはずですが、確かにコンテナー内にファイルを作成できます。クラウド ネイティブ分野の専門家と相談しました。これは、コンテナー内にファイルを作成する権限がないはずです。 K8S PVC のバグです。現在の K8S バージョンは : v1.27.0 です。

[外部リンク画像の転送に失敗しました。ソース サイトにはリーチ防止メカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-gbyw4p4M-1686473061752) (D:\MD Archives\IMG\image-20230611161652570.png) )]

5. PVC を削除するための正しい手順

  • pvc と pv はバインドされており、デフォルトのリサイクル ポリシー保持を使用する場合、pvc が削除された後、pv はリリース状態になります。この pv を引き続き使用したい場合は、手動で pv を削除する必要があります。kubectl delete pv pv_name、delete pv , pv は削除されません pvc を再作成するときに、pvc 内のデータは最も一致する pv にバインドされます。データは元のデータのままであり、失われることはありません。

  • テスト後、回復戦略が削除の場合は PV を削除しますが、PV バックエンドに保存されているデータは削除されません。

  • リサイクルポリシーフィールド:pv.spec.persistentVolumeReclaimPolicyフィールド

ステップ 1: まず、PVC を使用してポッドを削除します。

ステップ 2: PVC を削除する

ステップ 3: PV を削除する

おすすめ

転載: blog.csdn.net/weixin_45310323/article/details/131154956