Kubernetes永続ボリュームの概要

はじめに

Kubernetesは、本番環境でコンテナをホストするための最も人気のあるオーケストレーションソリューションの1つです。このプラットフォームにより、ユーザーは、需要に応じてスケールアップおよびスケールダウンしながら、アプリケーションの多数のインスタンスのデプロイを自動化できます。

ただし、Kubernetesポッドは不安定であるため、ストレージボリュームをまったく新しいアプローチで解決する必要がありました。

この記事では、Kubernetes永続ボリュームとは何か、およびそれらが非常に重要である理由について説明します。

Kubernetes永続ボリュームとは

Kubernetes永続ボリュームは、Kubernetesクラスターに割り当てられたユーザープロビジョニングのストレージボリュームです。永続ボリュームのライフサイクルは、それを使用するポッドから独立しています。したがって、永続ボリュームは、Kubernetesポッドの予測できないライフプロセスに関係なくデータを保持する必要があるユースケースに最適です。

永続的なボリュームがなければ、データベースと同じくらい一般的なサービスを維持することは不可能です。ポッドが交換されるたびに、そのポッドのライフサイクル中に取得されたデータは失われます。ただし、永続的なボリュームのおかげで、データは一貫した状態で含まれています。

Kubernetesボリュームの種類

永続ボリュームとは何かを理解するには、まずボリュームタイプの違いを説明する必要があります。 Kubernetesポッドで使用できるボリュームにはさまざまな種類があります：

ノードローカルメモリ（ emptyDir およびhostPath ）
クラウドボリューム（例： awsElasticBlockStore 、gcePersistentDisk 、 およびazureDiskVolume ）
ネットワークファイルシステムなどのファイル共有ボリューム（nfs ）
分散ファイルシステム（例： cephfs 、 rbd 、および glusterfs ）
PersistentVolumeClaimなどの特別なボリュームタイプ 、secret 、および gitRepo

両方のemptyDir およびhostPath ポッドに接続され、RAMまたはドライブの永続ストレージに保存されます。それらはポッドに依存しているため、ポッドが実行されている限り、それらのコンテンツを利用できます。ダウンすると、データが失われます。

クラウドボリュームを使用、 nfs 、および PersistentVolumeClaim 、ボリュームは独立しており、ポッドの外側に配置されます。これらは基本的にすべてデータを保持するように設計されていますが、クラウドボリューム 取り扱いが非常に困難です。 ポッドをプロバイダーに接続するには、ユーザーは多くのストレージの詳細を知っている必要があります。

ネットワークファイルシステムと永続ボリュームははるかに実用的です。実際、これら2つのボリュームタイプは同じ原則で機能します。

NFS yamlを介してボリュームに接続できますファイル。ポッドがない場合、ボリュームのコンテンツはマウント解除されますが、引き続き使用できます。ただし、NFSセットアップの場合でも、永続ボリュームクレーム（PVC）を送信する必要がありますリクエスト。

したがって、永続ボリュームクレームはKubernetesの永続ボリュームのコアソリューションです。

永続的なボリュームクレームとは

永続ボリュームクレームは、一連の抽象化を通じてバックエンドストレージボリュームに接続するオブジェクトです。導入に必要なストレージリソースを要求します。

主な利点は、PVCがはるかにユーザーフレンドリーであり、開発者が接続しているクラウド環境の詳細をあまり知らなくてもPVCを使用できることです。管理者はPVCに完全なクレームの詳細をリストしますが、ポッド自体はそれにアクセスするためのリンクのみを必要とします。

したがって、永続ボリュームを使用するポッドには、それとストレージの間にいくつかの抽象レイヤーも含まれます。

永続ボリュームの使用

ポッドを永続ボリュームにバインドするには、ボリュームマウントと永続ボリュームクレーム（PVC）を含める必要があります。これらの主張により、ユーザーはクラウド環境の詳細を知らなくても、永続ボリュームをポッドにマウントできます。

永続ボリュームクレームでは、ユーザーは、ストレージのサイズ、セレクター、適切なPVへの転送、およびストレージクラスを指定します。ストレージクラスは、静的か動的かに関係なく、プロビジョニングのタイプを指します。

静的プロビジョニング は、管理者が既存のストレージデバイスを利用して、クラスターユーザーが利用できるようにする機能です。クラスタ管理者は、消費に利用でき、KubernetesAPIに存在するいくつかの永続ボリュームを作成します。

動的プロビジョニング 静的永続ボリュームのいずれもPVCと一致しない場合に発生します。この場合、プロビジョニングは、管理者によって作成および構成されたストレージクラスに基づいています。

永続ボリュームのライフサイクル

PVCを削除すると、その主張のPVを解放します。再利用ポリシーセットに応じて、ボリュームは保持、リサイクル、または削除されます。

再利用ポリシーを保持に設定した場合、ストレージ内のボリュームは、クレームから解放された後も残ります。
または、リサイクルすることもできますボリューム。その中のコンテンツを削除し、他のPVCで使用できるようにします。
再利用ポリシーを削除するように構成している PVCから切断されると、ボリュームとストレージが完全に削除されます。

永続ボリュームを作成する方法

1.永続ボリュームを作成するには、まず .yamlを作成します選択したエディターでファイルを作成します。この例では、ファイルに example-pv.yamlという名前を付けます。 nanoエディターで編集します：

nano example-pv.yaml

2.次のコンテンツをファイルに追加します。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: [pv_name]
spec:
capacity:
  storage: 10Gi
accessModes:
  - ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
mountPath: [path of where the volume is accessible from within the container]
volumeID: [your_volume_id]

3. nameの仕様を置き換えます 、storage 、mountpath 、および volumeID 尊敬する価値観を持って。

4.ファイルを保存して終了します。

5.次に、前の手順で作成した.yamlファイルの名前で次のコマンドを使用して、永続ボリュームをデプロイします。

kubectl create -f example-pv.yaml

永続的なボリュームクレームを作成する方法

PVと同様に、 .yamlを使用してPVCを作成します次のコンテンツで構成されるファイル：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: [pvc_name]
spec:
  storageClassName: manual
  selector:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

コンテンツを追加したら、ファイルを保存して終了します。

永続ボリュームと永続ボリュームクレームを設定および構成したら、必要なポッドでPVCを指定できます。