Kubernetesポッドに永続ストレージを追加する方法
Kubernetes ポッドのファイルシステムはデフォルトで一時的です。これはコンテナのステートレスな性質に沿ったものです。永続的なデータはコンテナの外に保存するべきで、たとえそれがコンテナのファイルシステム内にあるように見えてもです。Kubernetes で永続ストレージをプロビジョニングする方法は以下の通りです。
Kubernetesの永続ストレージの基本単位はPersistent Volumeです。これは、より基本的なVolume上の抽象です。
Persistent Volumesは特定のPodに依存せずに存在します。通常のDockerボリュームと同様に、KubernetesのPersistent Volumesは、それを使用しているPodがない場合でも、クラスター内に残ることができます。
Pod は Persistent Volume Claim を作成することで Persistent Volume へのアクセスを得ます。これは、Pod の永続ストレージの使用要求を表す別のリソースタイプです。このクレームは、要求を満たす Persistent Volume のプロビジョニングを処理します。
基本的な例
永続ストレージシステムを作成する方法を見てみましょう。これは、永続ボリュームと永続ボリューム要求を手動で設定することによって行います。それぞれのリソースは独自のマニフェストファイルに入ります。これらのファイルをクラスターに適用することができます。
kubectl apply永続ボリュームを作成する
まずはボリュームを作成してください。
apiVersion: v1
kind: PersistentVolume
metadata:
name: my-volume
namespace: pvc-demo
spec:
storageClassName: manual
capacity:
storage: 2Gi
accessModes:
- ReadWriteOnce
hostPath:
path: /mnt/data
この定義は、呼ばれるボリュームを作成します
my-volume容量は2Giであり、次の場所に保存されます。
/mnt/dataホストノード上で。このボリュームを手動で作成しているため、storageClassNameはmanualに設定されています。ストレージクラスは、ボリュームが同じクラスを要求するボリュームクレームにのみバインドされることを義務付けるために使用できます。
永続ボリュームクレームを作成する
Persistent Volume Claimを構成できるようになりました:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-volume-claim
namespace: pvc-demo
spec:
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
要求は、manualクラスを使用してボリュームから1Giのストレージを要求します。前に作成したボリュームはこれらの条件を満たすことができます。要求が作成されると、Kubernetesはこれを認識し、要求をボリュームにバインドする必要があります。
ボリュームとクレームの詳細を確認すれば、両方とも状態が表示されているのがわかります。
Boundkubectl get pv my-volume
kubectl get pvc my-volume-claim
ポッドを追加する
最終段階は、ボリュームクレームを使用してPodに永続ストレージを追加することです。
apiVersion: v1
kind: Pod
metadata:
name: my-pod
namespace: pvc-demo
spec:
containers:
- name: my-container
image: my-image:latest
volumeMounts:
- mountPath: /path/in/container
name: my-pod-volume
volumes:
- name: my-pod-volume
persistentVolumeClaim:
claimName: my-volume-claim
ボリュームセクション内で、永続ボリュームクレームへの参照が構成されています。ボリュームに関する他の情報を指定する必要はありません。Podは、そのボリュームにバインドされているクレームを使用します。
その主張はvolumeMountsで参照されています。volumesとvolumeMountsで同じ名前を使用することを確認してください。ボリュームは、mountPathで指定された場所にPodにマウントされます。
あなたのポッドには現在、永続ストレージが利用可能です。/path/in/container に書き込まれたものはすべて、永続ボリュームに保存されます。永続ボリュームクレームは、それを参照する新しいポッドによって再利用され、データは個々のポッドを超えて生き続けることができます。
ストレージクラス
マニュアルストレージクラスは、自分のボリュームとボリュームクレームマニフェストを作成する際に使用されます。異なるボリュームプラグインドライバは、それぞれ独自のストレージクラスを提供します。使用したいボリュームタイプを表すストレージクラスを参照してください。
管理されたKubernetesサービスは通常、プラットフォームのブロックストレージ実装に対応する独自のストレージクラスを提供します。例えば、Google Kubernetes EngineのgcePersistentDiskや、DigitalOcean Managed Kubernetesのdo-block-storageなどがあります。
これらのシナリオでは、PersistentVolume マニフェストを手動で作成する必要はありません。正しい storageClassName を持つ PersistentVolumeClaim を作成し、希望する容量を指定するために resources.requests.storage フィールド（上記に示されている）を使用します。ストレージドライバーが自動的にクレームを互換性のあるボリュームインスタンスにバインドします。
アクセスモード
accessModesフィールドには、次の3つのサポートされている値があります:
ReadWriteOnce- ボリュームは単一のKubernetesノードにのみマウントできます。そのノードはボリュームに対して完全な読み書きアクセスを持ちます。ReadOnlyMany- ボリュームは複数のノードによって同時に使用できます。各ノードは読み取り専用アクセスを持ち（ボリュームに書き込みはできません）。ReadWriteMany- ボリュームは複数のノードに同時にマウントできます。各ノードはボリュームを読み書きすることができます。
特定のボリュームに対しては、同時に一つのアクセスモードしか使用できません。つまり、二つのボリュームクレームが同じアクセスモードを宣言しない限り、同じボリュームにバインドすることはありません。
ボリュームのアクセスモードは、Kubernetes スケジューラーのポッドのレプリカを複数のノードに分散させる能力に影響します。ポッドが永続的なストレージを共有し、複数のノードにレプリケートされる必要がある場合は、ReadOnlyMany/ReadWriteMany モードを使用する必要があります。
すべてのストレージドライバーがすべてのアクセスモードをサポートしているわけではないことに注意してください。プラグインのプロバイダーに確認する必要があります。ボリュームプラグインと互換性のあるアクセスモードの非網羅的なリストはKubernetesのドキュメントに提供されています。
結論
Kubernetesにおける永続ストレージは、一見すると思ったほど難しくありません。ストレージにアクセスする必要があるPodは、永続ボリュームクレームにバインドされたボリュームを持っていることを確認してください。
Persistent Volume Claimsが使用されると、Kubernetesは個々のPodよりも長生きするPersistent Volumesを作成します。Podが置き換えられると、請求されたボリュームは自動的に新しいPodにマウントされます。請求が削除されるまでデータは破壊されません。