Persistent VolumeとClaim

Podは作成と削除を繰り返しますが、アプリケーションのデータは残しておく必要があることがよくあります。データベースやユーザーがアップロードしたファイルを考えてみてください。

• Podが再起動または再スケジュールされると、コンテナーのファイルシステム内に直接保存されたデータは失われます。
• この一時的な性質はステートレスなアプリケーションには適していますが、重要なデータには永続的な保存方法が必要です。
• Kubernetesには、Podのライフサイクルをまたいで存続する永続ストレージを管理する強力な仕組みがあります。

PersistentVolume（PV）は、Kubernetesクラスター内のストレージです。

• クラスターをスコープとするリソースであり、特定のnamespaceには属しません。
• PVは管理者がプロビジョニングするか、StorageClassによって動的にプロビジョニングされます。
• 基盤となるストレージ技術（例: Google Persistent Disk、AWS EBS、NFS共有）の詳細を抽象化します。

PVには、容量、アクセスモード、ストレージの種類などの詳細を定義します。次のYAMLは、5ギガバイトのストレージを持つhostPath（ローカルテスト用）のPVを定義しています。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-local-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/mnt/data"

注: hostPathは通常、単一ノードでの開発に使用するものであり、本番環境には推奨されません。

PersistentVolumeClaim（PVC）は、特定のnamespace内でユーザーまたはアプリケーションが行うストレージ要求です。

• PodはPVを直接利用せず、PVCを通じてストレージを要求します。
• PVCはnamespaceをスコープとするため、特定のプロジェクトやチームの領域に属します。
• 必要なサイズ、アクセスモード、必要に応じてStorageClassを指定します。

Kubernetesはバインディングと呼ばれる処理によって、PVCと利用可能なPVを自動的に対応付けます。

• PVCが作成されると、KubernetesはPVCの要件（サイズ、アクセスモード、StorageClass）を満たすPVを探します。
• 適切なPVが見つかると、両者は1対1の関係で「バインド」されます。
• このバインディングにより、PVCは要求した特定のストレージを利用できます。

アクセスモードは、ストレージをPodにどのようにマウントして使用できるかを定義します。これらのモードをPVCが要求し、PVがサポートします。

• ReadWriteOnce（RWO）: 1つのノードがボリュームを読み書き可能な状態でマウントできます。
• ReadOnlyMany（ROX）: 複数のノードがボリュームを読み取り専用でマウントできます。
• ReadWriteMany（RWX）: 複数のノードがボリュームを読み書き可能な状態でマウントできます。

利用できるモードは、使用するストレージプロバイダーによって異なります。

StorageClassを使うと、管理者はストレージの「クラス」（例: 「fast-ssd」、「slow-hdd」）を定義できます。

• PVを手動で作成する代わりに、PVCが要求したときにStorageClassでPVを動的にプロビジョニングできます。
• 事前に定義したテンプレートに基づいてPVの作成を自動化できます。
• ストレージのプロビジョニングと利用を分離できるため、ユーザーにとって扱いやすくなります。

1ギガバイトのストレージをReadWriteOnceアクセスで要求するPVCを作成してみましょう。このPVCは既存のPVを探すか、StorageClassを通じて動的プロビジョニングを開始します。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-app-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: standard # Optional: if you have a 'standard' StorageClass

これをpvc.yamlとして保存し、kubectl apply -f pvc.yamlで適用します。

PVCがバインドされると、Podはボリューム設定でPVCの名前を参照して利用できます。Podが基盤となるPVを知る必要はなく、PVCだけを参照すればよいのです。

apiVersion: v1
kind: Pod
metadata:
  name: my-data-pod
spec:
  containers:
    - name: data-container
      image: busybox
      command: ["/bin/sh", "-c", "echo 'Hello from CoddyKit!' > /mnt/data/hello.txt && sleep 3600"]
      volumeMounts:
        - name: persistent-storage
          mountPath: /mnt/data
  volumes:
    - name: persistent-storage
      persistentVolumeClaim:
        claimName: my-app-pvc

このPodは、マウントされた永続ボリュームにファイルを書き込みます。

kubectlを使うと、永続ストレージリソースの状態を監視できます。

• すべてのPVを表示する: kubectl get pv
• namespace内のすべてのPVCを表示する: kubectl get pvc
• 状態やイベントなどの詳細情報を取得する:
• kubectl describe pv <pv-name>
• kubectl describe pvc <pvc-name>

PVがBoundになっており、PVCが正しいPVにBoundされていることを確認してください。

あるユーザーが、50GBの永続ストレージを必要とするデータベースをデプロイしようとしています。ユーザーのアプリケーションから見た、このストレージへの要求を直接表すKubernetesリソースはどれでしょうか。

Kubernetesがアプリケーションの永続ストレージを管理する方法について学びました。

• PersistentVolume（PV）はクラスターリソースで、実際のストレージを表します。
• PersistentVolumeClaim（PVC）は、ユーザーによるストレージ要求です。
• Kubernetesは要件に基づいて、PVCを適切なPVにバインドします。
• アクセスモードはストレージの使用方法（RWO、ROX、RWX）を定義します。
• StorageClassはPVの動的プロビジョニングを可能にし、セットアップを自動化します。

この仕組みにより、Podが作成と削除を繰り返してもアプリケーションデータが保持され、ステートフルなアプリケーションの信頼性が高まります。