記事ディレクトリ
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/
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
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
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
コンテナに入り、試してみるファイルを作成してみましょう。
kubectl exec -it pvc-test-d65964fd4-jmkmg -- /bin/bash
下の図に示すように、私は読み取り専用 PVC を使用しています。コンテナー内にファイルを作成する権限はないはずですが、確かにコンテナー内にファイルを作成できます。クラウド ネイティブ分野の専門家と相談しました。これは、コンテナー内にファイルを作成する権限がないはずです。 K8S PVC のバグです。現在の K8S バージョンは : v1.27.0 です。
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 を削除する