k8s雜記-7 Pod 為什麼需要 PVC？談 Kubernetes 的資源分工與管理

2025 iThome 鐵人賽

DAY 19

自我挑戰組

30 天工程師雜學之旅系列第 19 篇

17th鐵人賽 #k8s #kubernetes #pv #pvc

celin

2025-08-31 02:19:44

165 瀏覽

分享至

在 Kubernetes 學習的過程中，我曾經對 PersistentVolume（PV）和 PersistentVolumeClaim（PVC）的設計產生過一個疑問：

為什麼需要先有 PV，再去建立 PVC，最後才綁定？為什麼不能在部署 Pod 的時候，直接指定一個 Volume 就好？

這個問題看似簡單，但其實牽涉到 Kubernetes 背後對「資源管理」與「責任分工」的設計哲學。本文就從這個疑問出發，逐步整理我對 PV/PVC 的理解，並分享一些實務上的觀察。

Pod 為什麼不能直接綁定 Volume？

如果我們能在 Pod 裡面直接宣告一個 Volume，聽起來簡單明瞭。但實際上會遇到幾個問題：

Pod 是短暫的（ephemeral）
- Pod 隨時可能因為調度、升級、或異常而被刪除、重建。
- 如果儲存空間直接跟 Pod 綁定，那 Pod 消失時，資料也會跟著消失。
責任分工問題
- 叢集的儲存資源通常由基礎架構或系統管理員負責（例如掛載 NFS、配置 Ceph、設定 AWS EBS）。
- 而應用程式開發者只需要「要一塊存放資料的空間」就好，不該知道底層是 NFS 還是 SSD。
- PV/PVC 的機制正好提供了這個分層：
  - PV → 管理員定義可用的儲存資源池。
  - PVC → 開發者只要提出需求（例如 10Gi 的可讀寫空間）。
資源分配與管理
- 儲存空間跟 CPU/Memory 一樣，是叢集裡需要公平分配的資源。
- 如果大家都能隨意在 Pod 裡面創建 Volume，叢集資源很快就會失控。
- PV/PVC 提供了一個「宣告需求 → 由系統分配 → 明確綁定」的流程，避免資源衝突。

PV/PVC 的運作方式

PersistentVolume (PV)
- 類似「已存在的房間」，由管理員準備好，指定容量、存取模式、後端儲存類型（NFS、EBS...）。
PersistentVolumeClaim (PVC)
- 類似「入住需求」，由使用者提出「我要一間 10Gi 的雙人房」這樣的需求。
綁定過程
- Kubernetes 負責把 PVC 和符合條件的 PV 配對起來。
- 如果有 StorageClass，PVC 甚至可以自動觸發動態建立 PV，完全不需要管理員手動配置。
Reclaim Policy
- 當 PVC 被刪掉時，PV 的命運取決於它的政策：
  - Retain → 保留資料，等待手動清理。
  - Delete → 自動刪掉底層儲存資源。
  - Recycle（已廢棄） → 清空資料後再釋出。

為什麼要「先準備容量，再提出需求」？

這就像是飯店管理：

飯店（管理員）先準備好一批房間（PV）。
客人（開發者）只需要提出需求（PVC）。
櫃檯（Kubernetes）幫忙媒合，指派合適的房間。
當客人退房（刪掉 PVC），飯店依照政策來決定房間是否清理、保留或拆掉。

如果沒有這一層流程，每個客人都要自己蓋房子（直接在 Pod 定義 Volume），那麼：

成本會變高（重複造輪子）。
空間利用率變差（有些房間閒置，有些超賣）。
管理混亂（沒有統一的規則追蹤誰用了多少資源）。

StorageClass 與動態配置

在真實環境中，管理員通常不會一個一個手動建立 PV，而是定義 StorageClass，讓系統自動處理：

範例：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3

開發者只需要在 PVC 裡面指定：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: fast-ssd

這樣就會自動產生一個 EBS Volume 當作 PV，並且綁定到 PVC。