Kubernetes 永続ボリュームクレーム（Persistent Volume Claim）の解説

永続的な Kubernetes ボリューム（Persistent Volume, PV）とは、Kubernetes の StorageClass を通じて定義されたストレージデバイス上の永続ストレージへ、Pod がアクセスできるようにするオブジェクトです。

一時的な性質を持つ通常のボリュームとは異なり、PVs は永続的に保持され、ステートフルなユースケースをサポートいたします。PV は Kubernetes クラスター内のリソースオブジェクトであり、それを使用する Pod が削除された後も存続いたします。

PV の利用には Persistent Volume Claim（PVC）、すなわちストレージ要求を通じたリクエストが必要となります。PVC とは、特定の PV を直接指定するものではなく、Pod が必要とする StorageClass を定義することで、条件に合致する PV をマウントするための要求です。

管理者は、ストレージデバイスのパフォーマンス、サービスレベル、バックエンドポリシーなどの特性を定義する StorageClass をあらかじめ設定することが可能です。

PVC モデルの大きな利点は、開発者が基盤となるストレージ実装の詳細を理解していなくとも、動的にストレージリソースを要求できる点にございます。

関連情報: 弊社の「Kubernetes StorageClass ガイド」をぜひご参照ください。

永続ボリュームクレーム：静的プロビジョニングと動的プロビジョニング

Pod を PV にバインドするためには、Pod 内にボリュームマウントおよび PVC を含める必要がございます。

これらの宣言により、ユーザーは基盤となるストレージデバイスの詳細を理解することなく、PV を Pod にマウントすることが可能となります。

PV を Pod にマウントする方法は 2 つございます：

静的構成では、管理者が手動で PV を作成し、これらの PV の条件に合致する StorageClass を定義いたします。Pod がその StorageClass を指定した PVC を使用する場合、該当する静的 PV のいずれかへアクセスできるようになります。

動的構成は、PVC に対応する静的 PV が存在しない場合に行われます。この場合、Kubernetes クラスターは StorageClass の定義に基づいて新しい PV を自動的にプロビジョニングいたします。

関連情報: 弊社の「Kubernetes 共有ストレージ ガイド」をぜひご参照ください。

永続ボリュームクレームの作成と永続ボリュームへのバインド

本チュートリアルでは、PV および PVC の動作を分かりやすく解説いたします。これは Kubernetes ドキュメントに掲載されている完全版チュートリアルの要約でございます。

1.    ノードのセットアップ

単一ノードを持つ Kubernetes クラスターを構築し、kubectl コマンドラインがコントロールプレーンへ接続されていることをご確認ください。

その後、ノード上に以下のようなディレクトリを作成いたします。

sudo mkdir /mnt/data

ディレクトリ内に index.html ファイルを作成いたします。

2.    永続ボリュームの作成

PV を定義するため、以下のような YAML ファイルを作成いたします。

このコマンドを実行し、ノード上に PV を作成いたします。

kubectl apply -f https://k8s.io/examples/pods/storage/pv-volume.yaml

3.    永続ボリュームクレームの作成と永続ボリュームへのバインド

以前に作成した PV と一致させるため、以下の条件を満たす PV を要求する PVC を作成いたします。

• 3GB 以上のストレージ容量
• 読み取り/書き込みアクセスの有効化

このコマンドを実行し、PVC を適用いたします.

kubectl apply -f https://k8s.io/examples/pods/storage/pv-claim.yaml

PVC（永続ボリュームクレーム）を作成すると、Kubernetes コントロールプレーンが適切な PV を検索いたします。該当する PV が見つかった場合、PVC はその PV にバインドされます。

以下のコマンドを実行し、先ほど作成した PV のステータスをご確認ください。

kubectl get pv task-pv-volume

バインドが正常に完了すると、出力は次のようになります.

4.    Pod の作成と永続ボリュームクレームのマウント

最後に、PVC を利用する Pod を作成いたします。

NGINX イメージを使用して Pod を実行し、Pod の仕様内の該当セクションに先ほど作成した PVC を指定してください。

Bash コマンドを使用して Pod 内に curl をインストールし、次のコマンドを実行してください。

curl http://localhost/

出力には、ステップ 1 で作成した index.html ファイルの内容が表示されるはずです。これにより、新しい Pod が PVC を通じて PV 上のデータにアクセスできることが確認できます。

Kubernetes PVC エラー：一般的な原因と解決策

Kubernetes PVC の利用は複雑になる場合があり、診断や解決が難しいエラーを引き起こす可能性がございます。

PVC に関連するエラーは、一般的に以下の 3 つの大きなカテゴリに分類されます。

• PV 作成時の問題
• PV プロビジョニング時の問題
• PV または PVC の仕様変更による問題

PVC に関連する最も一般的なエラーには、FailedAttachVolume、FailedMount、および CrashLoopBackOff がございます。

FailedAttachVolume エラーおよび FailedMount エラー

これら 2 つのエラーは、Pod が PV をマウントできなかったことを示しております。

違いとしては、「FailedAttachVolume」 はボリュームが前のノードから切り離せない場合に発生し、「FailedMount」 はボリュームが必要なパスにマウントできない場合に発生いたします。

これらのエラーには多数の原因が考えられます。代表的なものとしては、新しいノードの障害、新しいノードに接続されたディスク数の過多、ネットワーク分断による障害、あるいは前のノードでのストレージデバイス障害などがございます。

問題の診断

FailedAttachVolume や FailedMount といった問題の原因を診断するためには、describe pod コマンドを実行してください。「Events（イベント）」セクション内のエラーメッセージを確認し、その内容からエラーの原因を特定できます。

問題解決

Kubernetes は 「FailedAttachVolume」 や 「FailedMount」 を自動的に解決することはできません。そのため、手動での対応が必要となります。

• 原因が切り離しの失敗である場合は、ストレージデバイスのインターフェースを使用して手動でボリュームを切り離してください。
• エラーが「アタッチまたはマウントの失敗」である場合は、ネットワーク分断や誤ったネットワークパスの有無を確認してください。それらが原因でない場合は、Pod を別のノードでスケジューリングするよう Kubernetes に再試行させるか、新しいノード側の問題を調査・解決してください。

PersistentVolumeClaim に起因する CrashLoopBackOff エラー

CrashLoopBackOff は、Pod が繰り返しクラッシュし、再起動しては再びクラッシュする状態を示しております。場合によっては、破損した PersistentVolumeClaim（PVC）が原因でこのエラーが発生することがございます。

問題の診断

CrashLoopBackOff エラーが PVC に起因しているかどうかを確認するためには、以下を実施してください。

• PV をマウントした以前のコンテナインスタンスのログを確認する
• デプロイメントのログを確認する
• 必要に応じてコンテナにシェルでアクセスし、クラッシュの原因を特定する

CrashLoopBackOff が PVC に関連する問題の結果である場合は、以下の手順をお試しください。

1.    デバッグを行えるよう、デプロイメントを 0 インスタンスにスケールダウンする

2.    次のクエリを使用して、失敗した PVC の識別子を取得する

kubectl get deployment -o jsonpath="{.spec.template.spec.volumes[*].persistentVolumeClaim.claimName}" failed-deployment 

3.    デバッグ用に新しい Pod を作成し、次のコマンドを使用してシェルを実行してください。

exec -it volume-debugger sh

4.    ディレクトリに現在マウントされているボリュームを特定し、Pod のクラッシュを引き起こしている問題を解決してください。

5.    その後、シェルを終了し、デバッグ用の Pod を削除したうえで、デプロイメントを必要なレプリカ数にスケールバックしてください。

Cloud Volumes ONTAP を用いた Kubernetes ストレージ最適化

NetApp Cloud Volumes ONTAP は、エンタープライズ向けのリーディングストレージ管理ソリューションであり、AWS、Azure、Google Cloud 上で安全かつ実績あるストレージ管理サービスを提供いたします。

Cloud Volumes ONTAP はペタバイト規模までスケール可能であり、ファイルサービス、データベース、DevOps など、幅広いエンタープライズワークロードをサポートいたします。その豊富な機能には、高可用性、データ保護、ストレージ効率、Kubernetes との統合などが含まれます。

特に、Cloud Volumes ONTAP はコンテナ化されたワークロードにおける Kubernetes Persistent Volume のプロビジョニングおよび管理要件をサポートしております。

Kubernetes ワークロードにおける Cloud Volumes ONTAP の活用事例をご覧いただくことで、Cloud Volumes ONTAP がコンテナ化アプリケーションの課題解決にどのように貢献するかをご理解いただけます。