DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

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

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

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

Kubernetesの永続ストレージは、シンプルな問題を解決します。コンテナは消えても、データベースファイル、アップロード、キュー内のデータは消えてはいけません。ステートレスなPodはいつでも置き換え可能です。ステートフルなアプリケーションには、Podの再起動、再スケジュール、ノードメンテナンスを乗り越えるストレージが必要です。

このガイドでは、PersistentVolume（PV）、PersistentVolumeClaim（PVC）、アクセスモード、StorageClassについて、実際のワークロードに適用できる実践的なYAML例を用いて説明します。

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

ストレージをPodにマウントする前に、各オブジェクトの役割を把握しましょう。

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

この分離により、プラットフォームチームはストレージの詳細を管理し、アプリケーションチームは必要な容量とアクセスパターンを要求できます。

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

2つの設定がPVCの動作の大部分を制御します。ボリュームのマウント方法と、どのストレージバックエンドがそれを作成するかです。

アクセスモード

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

  • ReadWriteOnce（RWO）：ボリュームは単一のノードによって読み取り/書き込み可能としてマウントできます。
  • ReadOnlyMany（ROX）：ボリュームは多くのノードによって読み取り専用としてマウントできます。
  • ReadWriteMany（RWX）：ボリュームは多くのノードによって読み取り/書き込み可能としてマウントできます。
  • ReadWriteOncePod（RWOP）：ボリュームは単一のPodによって読み取り/書き込み可能としてマウントできます。これは、より厳密な単一ライター動作が必要で、CSIドライバーがサポートしている場合に便利です。

これらのモードの実際のサポートは、基盤となるストレージプロバイダーに依存することに注意してください。

StorageClass

StorageClassは、管理者が提供するストレージの「クラス」を記述する方法を提供します。異なるクラスは、サービス品質レベル、バックアップポリシー、またはクラスター管理者によって決定される任意のポリシーに対応する場合があります。StorageClassには、ストレージをプロビジョニングするプロビジョナーと、そのプロビジョナー用の一連のパラメーターがあります。特定のPVなしでPVCが作成され、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：単一ノードで読み取り/書き込み可能としてマウントできるストレージを要求しています。
  • 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は動的プロビジョニングを提供しており、既存のPVでは満たせないストレージ要求がPVCによって行われた場合に、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 は単一レプリカのデータベースで一般的であり、ReadWriteMany は複数のPodで使用される共有ファイルシステムに必要です。
  • ストレージのパフォーマンスを理解する： ストレージプロバイダーやStorageClassによって、パフォーマンス特性（IOPS、スループット）は異なります。アプリケーションのパフォーマンス要件を満たすStorageClassを選択してください。
  • バックアップ戦略： 永続ストレージは自動的にバックアップを意味するわけではありません。特に重要なデータについては、永続ボリュームの堅牢なバックアップ戦略を実装してください。
  • PVの回収ポリシー： PVには persistentVolumeReclaimPolicy があり、一般的には Delete または Retain です。動的にプロビジョニングされたボリュームは、多くの場合、そのStorageClassで定義された回収ポリシーを使用します。古い Recycle ポリシーは非推奨であり、新しいセットアップでは使用しないでください。
  • 名前空間の考慮事項： PVCは名前空間にスコープされます。バインディングが発生するには、PodとPVCが同じ名前空間にあることを確認してください。

まとめ

Kubernetesの永続ストレージは、PVC、Podのマウント、そしてワークロードに合ったStorageClassから始まります。単一レプリカのデータベースの場合は、ReadWriteOnce クレームから始め、Bound 状態になることを確認し、コンテナにマウントし、初日からバックアップを設計の一部にしてください。