CLOUD SECURITY LAB

🏗️ [Kubernetes] Podにディスクを直接接続してはいけない理由 (PV, PVC, SCの必要性)

—

by

cslab
in

こんにちは！今日は、Kubernetesストレージの「花形」とも言えるPV(PersistentVolume)、PVC(PersistentVolumeClaim)、SC(StorageClass)が一体なぜ必要なのかについて深く掘り下げていきたいと思います。

初めてKubernetesを勉強する際、このような疑問を抱くかもしれません。

> _”Podの設定ファイル(YAML)にAWS EBS IDやNFSパスを直接書けば便利じゃないか？

> なぜわざわざ複雑にPV、PVCを別々に作って接続しなければならないのか？”_

結論から申し上げると、「直接接続は便利に見えるが、地獄への近道」だからです。なぜそうなのか、そしてPV/PVCシステムがどのように私たちを救ってくれるのか、4つの主要な理由にまとめてご紹介します。🚀

image

1. ☁️ 移植性(Portability)の破壊: 「私のPodはAWSでしか生きられない！」

もしPodのYAMLファイルに特定のクラウドのボリュームIDを直接記述したと仮定してみましょう。

YAML

# ❌ 悪い例 (直接接続)
volumes:
  - name: my-data
    awsElasticBlockStore: # AWSに依存！
      volumeID: 
      fsType: ext4

この方式の最大の問題は依存性(Lock-in)です。

  • 問題点: このPodはAWS環境でのみ動作します。もし会社がGoogle Cloud(GCP)に移行したり、オンプレミス(IDC)環境に移動する必要がある場合、このYAMLファイルはゴミになります。いちいち全て修正しなければなりません。
  • 解決策 (PVC): PVCを使用すれば、開発者は「10GBの容量が必要だ」と抽象的なリクエストをするだけです。その背後で実際のストレージがAWSなのか、Azureなのか、ローカルディスクなのかを気にする必要はありません。

2. 👨‍💻 役割の分離 (DevOps哲学): 「開発者はインフラを知らなくてもよい」

Kubernetesは開発者(Developer)と運用者(Admin/Ops)の役割を明確に分けることを目指しています。

  • 直接接続の場合: 開発者がPodを起動するには、ストレージサーバーのIPアドレス、ディスクID、ファイルシステムタイプなどを詳細に知る必要があります。開発者がインフラの複雑な詳細まで学ぶ負担が生じます。
  • PV/PVC使用の場合:
  • 運用者(Admin): ストレージインフラを構築し、PV(リソース)またはSC(ストレージクラス)を設定しておきます。
  • 開発者(User): インフラの内容を知らなくてもPVC(リクエスト書)を作成するだけで済みます。「運用者さん、高速ディスクを50ギガください！」とチケットを切るのと同じです。

3. ⚡ 動的プロビジョニング (Dynamic Provisioning)の魔法

最も強力な理由の一つは、StorageClass(SC)のおかげで可能になる「自動化」です。

  • 直接接続/手動管理: Podが100個必要なら、運用者がクラウドコンソールに入ってディスクを100個一つ一つクリックして作成し、IDを取得しなければなりません。恐ろしいですよね？ 😱
  • SC使用の場合: StorageClassを定義しておけば、開発者がPVCを作成した瞬間、Kubernetesが自動的にクラウドにコマンドを送り、ディスクを生成してPodに接続してくれます。

このプロセスはわずか数秒で自動的に行われます。

4. 🛡️ リソース管理とセキュリティ

ストレージは高価なリソースです。誰でも好き勝手に使わせてはいけませんよね？

  • 直接接続の場合: 開発者が任意に非常に高価な高性能ディスクを接続してしまったり、会社のポリシーに合わない設定をしてしまうリスクがあります。
  • PV/PVCパターン: 運用者はStorageClassを通じて作成可能なディスクの種類を制限したり、ResourceQuotaを通じて特定のチームが使用できるストレージの総量を制御したりできます。体系的なリソース管理が可能になります。

📝 要約: PV, PVC, SC 関係図

理解を助けるために、レストランに例えてみましょう。🍽️

| Kubernetes概念 | 比喩 (レストラン) | 説明 |

| — | — | — |

| Pod | お客様 | ご飯(データ空間)を食べたい主体 |

| PVC (Claim) | 注文書 | 「ご飯(10GB)一つください！」 (リクエスト) |

| StorageClass | 料理長/マニュアル | 注文が入ったらご飯を炊く方法とポリシー |

| PV (Volume) | 実際の茶碗 | 実際に用意されたご飯 (準備されたストレージリソース) |

| 実際のディスク | 米 | ご飯を作る原材料 (AWS EBS, NFSなど) |

  1. お客様(Pod)が注文書(PVC)を出します。
  2. 料理長(StorageClass)が注文を見て米(実際のディスク)でご飯(PV)を炊きます。(動的プロビジョニング)
  3. 用意されたご飯(PV)が注文書(PVC)とマッチング(バインディング)されてお客様に提供されます。

💡 結論

Podにディスクを直接接続するのは、一人でテントを張る際に釘を一本一本全て打つようなものです。一方、PV、PVC、SCを使用するのは「ホテルにチェックインする」ようなものです。

私たちはただ「部屋を一つください(PVC)」と言うだけで、ホテルシステム(K8s)が自動的に「はい、鍵です(PVバインディング)」と処理してくれるのです。

Kubernetesを運用環境で適切に使うには、この抽象化レイヤー(Abstraction Layer)を必ず理解し、使用する必要があります！ 😊

Comments

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です