DevOpsナレッジハブ
DevOpsナレッジハブ

Kubernetesで永続ストレージを実装するためのシンプルなガイド

Kubernetesでステートフルアプリケーションのための永続ストレージを実装する方法を学びます。このガイドでは、PersistentVolume（PV）とPersistentVolumeClaim（PVC）の仕組みを解き明かし、アクセスモードとStorageClassについて説明します。PVCを定義し、ストレージをPodにマウントするための実践的なYAML例が含まれており、コンテナ化されたアプリケーションで信頼性の高いデータ永続性を実現できます。

30 ビュー

Kubernetes における永続ストレージ実装のシンプルなガイド

コンテナオーケストレーションの世界では、Kubernetes はステートレスアプリケーション（再起動やスケーリングイベント間でデータを保持する必要のないアプリケーション）の管理に優れています。しかし、データベース、メッセージキュー、キーバリューストアなど、多くの最新アプリケーションは本質的にステートフルです。これらのアプリケーションは、それらを実行している Pod が再スケジュールされたり置き換えられたりしても、データを永続的に保存およびアクセスするための信頼性の高い方法を必要とします。ここで Kubernetes の永続ストレージが登場します。

このガイドでは、Kubernetes で永続ストレージを管理するためのコアコンポーネントである PersistentVolume（PV）と PersistentVolumeClaim（PVC）の概念を明確にします。YAML の実践的な例を通して、ストレージを Pod に定義、要求、およびバインドする方法を順を追って説明し、Kubernetes クラスターでステートフルアプリケーションを自信を持ってデプロイできるようにします。

PersistentVolume（PV）と PersistentVolumeClaim（PVC）の理解

実装に入る前に、PV と PVC の役割を理解することが重要です。

  • PersistentVolume（PV）: PV は、管理者によってプロビジョニングされた、または StorageClass を使用して動的にプロビジョニングされたクラスター内のストレージの一部です。PV は Node と同様に、クラスターリソースです。PV を使用する個々の Pod とは独立したライフサイクルを持ちます。PV は、基盤となるストレージ実装の詳細（例: NFS、iSCSI、クラウドプロバイダーのブロックストレージ）を抽象化します。
  • PersistentVolumeClaim（PVC）: PVC は、ユーザーからのストレージ要求です。PV としてクラスターで利用可能なストレージリソースを消費します。PVC は、コンピューティングリソースを消費するという点で Pod に似ており、名前空間にスコープされます。PVC は、必要なストレージ容量、アクセスモード、およびオプションで StorageClass を指定します。

この関心の分離により、クラスター管理者はストレージリソースを独立してプロビジョニングおよび管理でき、アプリケーション開発者は基盤となる実装の詳細を知らなくてもストレージを要求できます。

主要な概念: アクセスモードと StorageClass

PV と PVC を扱う際に理解すべき重要な 2 つの概念は、アクセスモードと StorageClass です。

アクセスモード

アクセスモードは、ボリュームが Pod にマウントされる方法を定義します。利用可能なアクセスモードは次のとおりです。

  • ReadWriteOnce（RWO）: ボリュームは 1 つのノードから読み書き可能としてマウントできます。
  • ReadOnlyMany（ROX）: ボリュームは複数のノードから読み取り専用としてマウントできます。
  • ReadWriteMany（RWX）: ボリュームは複数のノードから読み書き可能としてマウントできます。

これらのモードの実際のサポートは、基盤となるストレージプロバイダーに依存することに注意することが重要です。

StorageClass

StorageClass は、管理者が提供するストレージの「クラス」を記述するための方法を提供します。異なるクラスは、品質レベル、バックアップポリシー、またはクラスター管理者が決定した任意のポリシーに対応する場合があります。StorageClass はストレージをプロビジョニングするプロビジョナーと、プロビジョナーのパラメータセットを持ちます。PVC が特定の PV なしで作成され、StorageClass を要求すると、Kubernetes は指定された StorageClass を使用して PV を動的にプロビジョニングします。

永続ストレージの実装: ステップバイステップ

Pod の永続ストレージを要求して使用する一般的なシナリオを順を追って説明しましょう。

ステップ 1: PersistentVolumeClaim（PVC）の定義

まず、ストレージ要件を指定する PVC を作成する必要があります。この PVC は、アプリケーションからのストレージ要求として機能します。

例 pvc.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

この例では:

  • name: my-pvc: PVC の名前です。
  • accessModes: - ReadWriteOnce: 1 つのノードから読み書き可能としてマウントできるストレージを要求しています。
  • resources.requests.storage: 1Gi: 1 ギガバイトのストレージを要求しています。

PVC の適用:

上記のコンテンツを pvc.yaml という名前のファイルに保存し、クラスターに適用します。

kubectl apply -f pvc.yaml

適用後、PVC のステータスを確認できます。

kubectl get pvc my-pvc

適切な PV が利用可能であるか、または動的にプロビジョニングされた場合、PVC が Bound であることを示す出力が表示されるはずです。

ステップ 2: PVC を使用する Pod の作成

次に、PVC によって要求されたストレージを利用する Pod を作成しましょう。PVC によって提供されるボリュームを、コンテナ内の特定のディレクトリにマウントします。

例 pod-with-pv.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: my-stateful-pod
spec:
  containers:
    - name: my-container
      image: nginx
      ports:
        - containerPort: 80
      volumeMounts:
        - name: my-persistent-storage
          mountPath: /usr/share/nginx/html
  volumes:
    - name: my-persistent-storage
      persistentVolumeClaim:
        claimName: my-pvc

この例では:

  • volumes: my-persistent-storage という名前のボリュームを定義します。
  • persistentVolumeClaim.claimName: my-pvc: これにより、ボリュームが以前に作成した PVC にリンクされます。
  • volumeMounts: コンテナ定義内では、このボリュームをどこにマウントするか（mountPath: /usr/share/nginx/html）を指定します。

Pod の適用:

上記のコンテンツを pod-with-pv.yaml という名前のファイルに保存し、適用します。

kubectl apply -f pod-with-pv.yaml

これで、nginx コンテナは my-pvc によって定義された永続ストレージに /usr/share/nginx/html パスでアクセスできるようになります。コンテナ内でこのパスに書き込まれたデータは、PVC とその基盤となる PV が存続する限り、Pod が削除および再作成されても永続化されます。

StorageClass による動的プロビジョニング

PV を手動で作成するのは面倒な場合があります。Kubernetes は動的プロビジョニングを提供しており、PVC が既存の PV では満たせないストレージを要求すると、PV が自動的に作成されます。これは StorageClass を介して実現されます。

ほとんどのクラウドプロバイダー（AWS、GCP、Azure）は、事前設定された StorageClass を提供しています。これらは次のように確認できます。

kubectl get storageclass

動的プロビジョニングを使用するには、PVC 定義に storageClassName フィールドを追加するだけです。

例 pvc-dynamic.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-dynamic-pvc
spec:
  storageClassName: standard # 'standard' を実際の StorageClass 名に置き換えてください
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

この PVC を適用すると、Kubernetes は standard という名前の StorageClass（または指定した名前）を探し、そのプロビジョナーに 5Gi の新しい PV を作成してこの PVC にバインドするように指示します。

ヒントとベストプラクティス

  • 適切なアクセスモードの選択: アプリケーションが必要とするアクセスモードを慎重に検討してください。ReadWriteOnce は単一レプリカデータベースに一般的ですが、複数の Pod で使用される共有ファイルシステムには ReadWriteMany が必要です。
  • ストレージパフォーマンスの理解: ストレージプロバイダーや StorageClass によって、パフォーマンス特性（IOPS、スループット）が異なります。アプリケーションのパフォーマンスニーズを満たす StorageClass を選択してください。
  • バックアップ戦略: 永続ストレージが自動的にバックアップを意味するわけではありません。特に重要なデータについては、永続ボリュームの堅牢なバックアップ戦略を実装してください。
  • PV の回収ポリシー: PV には Delete（デフォルト）、Retain、または Recycle（非推奨）のいずれかになる reclaimPolicy があります。PV が削除されても基盤となるストレージが存在する場合にデータが失われないようにするには、Retain が役立ちます。
  • 名前空間の考慮事項: PVC は名前空間にスコープされます。バインディングが発生するため、Pod と PVC が同じ名前空間にあることを確認してください。

結論

Kubernetes でステートフルアプリケーションを実行するには、永続ストレージの実装が基本的な要件です。PersistentVolume と PersistentVolumeClaim、および StorageClass の柔軟性を理解して利用することで、アプリケーションのデータを確実に管理できます。このガイドでは、出発点となる基本的な知識と実践的な例を提供し、Kubernetes でより洗練された回復力のあるステートフルワークロードをデプロイできるようにします。