StorageClass をわかりやすい言葉で説明する (理論 + 実践)

この記事はWeChatの公開アカウント「The Calm Programmer」から転載したものです。この記事を転載する場合はAI Originの公開アカウントまでご連絡ください。

一言でまとめると、PV と PVC は、K8S がストレージ管理に使用するリソースオブジェクトです。ストレージリソースの使用を制御可能になり、システムの安定性と信頼性が確保されます。 StorageClass は、手動の作業負荷を軽減するために PV を自動的に作成するコンポーネントです。すべてのポッドがストレージを使用するための原則は 1 つだけです。まず計画し、次に適用し、次に使用する。

1. 理論

1. PVコンセプト

PV は、K8S ストレージリソースの抽象化です。 PV は通常、コンテナアプリケーションの運用および保守担当者によって作成および構成されます。

PV が利用可能になる前は、サーバーディスクのパーティションの概念はありませんでした。 PV が利用可能になった後は、PV を介してサーバーディスクをパーティション分割することと同等になりました。

2. PVCコンセプト

PVC は、Pod によるストレージリソースの申請であり、主にストレージスペースの申請、アクセスモードなどが含まれます。PV を作成した後、Pod は PVC を介して PV からディスクスペースを申請できます。これは、オペレーティングシステムの D ドライブから 1G の使用領域を要求するアプリケーションに似ています。

PVC が正常に作成されると、Pod は PVC のストレージリソースをストレージボリュームの形式で使用できるようになります。 PVC を使用する場合、Pod は PVC と同じ名前空間に存在する必要があります。

3. PVとPVCの関係

PV はディスクのパーティションに相当し、PVC はパーティション内で APP (アプリケーション) が適用するスペースの量に相当します。たとえば、WPS プログラムをインストールする場合、通常はインストールに必要なストレージ容量が通知され、特定のディスクにインストールすることを選択するように求められます。将来パーティションディスクがいっぱいになった場合でも、他のパーティションディスクの使用には影響しません。

PV が PVC にバインドされると、Pod は PVC を使用できるようになります。システム内に PVC の要件を満たす PV がない場合、適切な PV がシステム内に生成されるまで PVC は保留状態のままになります。

4. StorageClass の概念

K8S には、静的モードと動的モードの 2 つのストレージリソースプロビジョニングモードがあります。リソースプロビジョニングの最終的な目標は、適切な PV を PVC にバインドすることです。

静的モード: 管理者は事前にさまざまな PV を作成し、PVC が使用申請されるのを待ちます。
動的モード: 管理者は事前に PV を作成する必要はありません。代わりに、StorageClass は自動的に PV を作成し、それを PVC にバインドします。

StorageClass は、PVC のニーズに基づいて適切な PV リソースを動的に作成し、オンデマンドのストレージボリュームの作成を実現する動的モードです。

一般的に、商用アプリケーションでは多数の Pod が使用されます。各 Pod がストレージリソースを使用する必要がある場合、PV を随時手動で作成する必要があり、これも面倒です。解決策は、動的モードを使用することです。Pod が PVC を介してストレージリソースを申請すると、対応するサイズの PV が StorageClass を介して動的に作成され、PVC にバインドされます。したがって、PV と PVC の間には基本的に 1 対 1 の関係があります。

5. プロビジョナーのコンセプト

PVC を作成するときは、StorageClass を指定する必要があります。 PVC が対応する StorageClass を選択すると、それに関連付けられた Provisioner コンポーネントが PV リソースを動的に作成します。

では Provisioner とは何でしょうか?実際、これはオペレーティングシステムのディスクドライバーに似た単なるストレージドライバーです。

StorageClass リソースオブジェクトの定義には、主に、名前、プロビジョナー、ストレージ関連のパラメータ構成、リサイクルポリシーが含まれます。 StorageClass は一度作成されると変更することはできず、削除して再作成することしかできません。

PV と PVC のライフサイクルには、リソースのプロビジョニング、リソースのバインド、リソースの使用、リソースの再利用の 4 つの段階が含まれます。まず、古いものにはリソース供給があります。簡単に言えば、ストレージドライバーが存在し、それが作成、バインド、使用、リサイクルされる必要があります。

6. PV/PVC使用前後の比較

6.1.説明による比較

PV と PVC が使用される前は、各 Pod はストレージリソース (NFS など) にデータを自由に書き込むことができました。どのポッドでもディスク上で移動できます。長期的には、ディスク管理がますます混乱し、データ使用量が制限を超え、ディスクが爆発し、最終的にはディスク上のすべてのアプリケーションが停止することになります。

この問題を解決するために、PV と PVC の概念が導入され、Pod によって書き込まれるストレージデータのサイズが制限され、システムの可用性と安定性がより確実に確保されます。

PVC と PV では、すべてのポッドは、最初に計画し、後で適用し、後で使用するという原則に基づいてストレージリソースを使用します。

すると、「StorageClass は自動的に PV を作成しますが、これは元の無秩序で制御不能なものと同じ効果があり、ストレージリソースを自由に占有できます。」という疑問が湧くはずです。

実際、StorageClass を使用すると、PV の作成プロセスのみが自動化されますが、ストレージ制御可能なプロセスは実行されます。各ポッドが使用するストレージ容量は固定されています。 Pod がストレージ容量を超えることはなく、他のアプリケーションにも影響しません。障害が発生した場合、その原因は特定の Pod 自体のみになります。

6.2.写真で比較

PV と PVC が使用される前の状況を次の 2 つの図に示します。

PVとPVCを装着した後の状況は以下のようになります。

2. 練習

PV、PVC、StorageClass を実践する前に、読者は NFS サーバーを自分でインストールする必要があります。この記事では、YAML オーケストレーションを通じて NFS サーバー上に PV を自動的に作成する方法を説明します。

1. PodはPVとPVCを使用してストレージボリュームをマウントします

1.1、PV、PVC、ポッドマウントPVCのオーケストレーション

この記事では、Pod のディレクトリが NFS のディレクトリにマウントされることを示します。 nginx イメージを使用して、PV が配置されている NFS サーバーに HTML ファイルが書き込まれます。最後に、PV/PVC を使用して正常にマウントされていることがわかります。

yaml ファイルは次のとおりです。

 # PV编排apiVersion: v1 kind: PersistentVolume metadata: name: nfs-pv1 namespace: dev1 labels: pv: nfs-pv1 spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce # Recycle 删除PVC会同步删除PV | Retain 删除PVC不会同步删除PV persistentVolumeReclaimPolicy: Recycle nfs: path: /data/nfstest/share/pv1 server: 10.20.1.20 readOnly: false --- # PVC 编排，通过selector查找PV，K8S里的资源查找都是通过selector查找label标签apiVersion: v1 kind: PersistentVolumeClaim metadata: name: nfs-pvc1 namespace: dev1 labels: pv: nfs-pvc1 spec: resources: requests: storage: 100Mi accessModes: - ReadWriteOnce selector: matchLabels: pv: nfs-pv1 --- # Pod挂载PVC，这里为了测试，直接通过node节点的hostPort暴露服务apiVersion: v1 kind: Pod metadata: name: webapp namespace: dev1 labels: app: webapp spec: containers: - name: webapp image: nginx imagePullPolicy: IfNotPresent ports: - containerPort: 80 hostPort: 8081 volumeMounts: - name: workdir mountPath: /usr/share/nginx/html volumes: - name: workdir persistentVolumeClaim: claimName: nfs-pvc1

次のように kubectl コマンドを実行して実際の結果を表示します。

次に、ポッドのステータスを確認し、次のようにポッドがまだ作成中であることを確認します。

そこで、ポッドのステータス kubectl describe pod webapp -n dev1 をチェックしたところ、次の異常な情報が見つかりました。

これは、フォルダーが NFS 上に作成されていないためです。 NFS 上にこのフォルダーを作成した後、Pod を再起動すると、すべて正常になります。次に、ポッドが配置されているノードを見つけます。 http://nodeip:port にアクセスすると、成功したインターフェースが表示されます。

 [root@k8s-master pv-pvc-storageclass]# kubectl get pods -n dev1 -owide | grep webapp webapp 1/1 Running 0 4m17s 10.21.69.214 k8s-worker-3 <none> <none>

現時点では、nginx 配下に HTML ページが存在しないため、内容を見ることができません。次に、NFS サーバーに対応するディレクトリ /data/nfstest/share/pv1 に移動し、index.html ページを追加して、ページを更新します。インターフェースは次のとおりです。

ポッドに入ってマウントが成功したかどうかを確認することもできます。

kubectl exec -it webapp -n dev1 -- /bin/sh コマンドを実行して Pod に入ると、次のページが表示されます。

2. PodはStorageClassを使用してストレージボリュームを自動的にマウントします

2.1.プロビジョナーをインストールする

この記事では、比較的簡単な helm 経由で nfs-subdir-external-provisioner をインストールすることを選択します。インストールドキュメントとインストールプロセスは次のとおりです。

インストールドキュメント:

https://kubernetes.io/zh-cn/docs/concepts/storage/storage-classes/#nfs

https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner

インストールプロセス:

以下の 3 つの手順に従って、nfs-subdir-external-provisioner のインストールを完了します。

ヘルムをインストールします。この記事ではMacを例に説明します。

 brew install heml

nfs-subdir-external-provisioner をインストールし、次の 2 つのコマンドを実行します。

 $ helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/ $ helm install nfs-subdir-external-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner -n kube-system \ --set image.repository=dyrnq/nfs-subdir-external-provisioner \ --set nfs.server=10.20.1.20 \ --set nfs.path=/data/nfstest/nfs-storage

注目すべきパラメータをいくつか示します。

image.repository: イメージのアドレスが変更されました。デフォルトで使用される外部イメージが利用できない場合があります。

nfs.server: NFS サーバーのアドレス

nfs.path: ストレージディレクトリ

helm インストールの結果を表示します。

helm インストールの結果を表示するには、コマンド helm list -A を実行します。

対応するポッドが作成されているかどうかを確認します。イメージアドレスが変更されていない場合、次の図に示すように、プルは常に失敗します。

イメージアドレスを変更すると、以下に示すように、Pod が正常に起動します。

2.2. StorageClassの使用

この記事では、Pod が StorageClass を使用して PV を自動的に作成し、対応するストレージディレクトリにファイルを作成し、データを書き込む方法を説明します。

yaml ファイルは次のとおりです。

 apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: nfs-storage-1 provisioner: cluster.local/nfs-subdir-external-provisioner parameters: # 设置为"false"时删除PVC不会保留数据，"true"则保留数据archiveOnDelete: "false" mountOptions: # 指定NFS版本,这个需要根据NFS Server版本号设置- nfsvers=4 --- # 创建PVC kind: PersistentVolumeClaim apiVersion: v1 metadata: name: nfs-storage-pvc-1 namespace: dev1 spec: storageClassName: nfs-storage-1 #需要与上面创建的storageclass的名称一致accessModes: - ReadWriteOnce resources: requests: storage: 10Mi --- kind: Pod apiVersion: v1 metadata: name: nfs-storage-pod-1 namespace: dev1 spec: containers: - name: nfs-storage-pod-1 image: busybox command: - "/bin/sh" args: - "-c" - "touch /mnt/teststorage && echo 111 > /mnt/teststorage && exit 0 || exit 1" ## 创建一个名称为"SUCCESS"的文件volumeMounts: - name: nfs-pvc mountPath: "/mnt" restartPolicy: "Never" volumes: - name: nfs-pvc persistentVolumeClaim: claimName: nfs-storage-pvc-1

kubectl コマンドを実行すると、次の結果が表示されます。

写真

予想通り、storageClass を通じて PV が自動的に作成され、NFS に対応したストレージディレクトリにファイルが作成され、データが書き込まれます。

この時点で、練習プロセスは完了です。