iT邦幫忙

2025 iThome 鐵人賽

DAY 19
0
自我挑戰組

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

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

  • 分享至 

  • xImage
  •  

在 Kubernetes 學習的過程中,我曾經對 PersistentVolume(PV)和 PersistentVolumeClaim(PVC)的設計產生過一個疑問:

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

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


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

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

  1. Pod 是短暫的(ephemeral)

    • Pod 隨時可能因為調度、升級、或異常而被刪除、重建。
    • 如果儲存空間直接跟 Pod 綁定,那 Pod 消失時,資料也會跟著消失。
  2. 責任分工問題

    • 叢集的儲存資源通常由基礎架構或系統管理員負責(例如掛載 NFS、配置 Ceph、設定 AWS EBS)。
    • 而應用程式開發者只需要「要一塊存放資料的空間」就好,不該知道底層是 NFS 還是 SSD。
    • PV/PVC 的機制正好提供了這個分層:
      • PV → 管理員定義可用的儲存資源池。
      • PVC → 開發者只要提出需求(例如 10Gi 的可讀寫空間)。
  3. 資源分配與管理

    • 儲存空間跟 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。


小結

透過這次的學習,我理解了為什麼 Kubernetes 不允許在 Pod 裡直接創建持久化 Volume,而是引入了 PV/PVC 的抽象:

  • Pods 是短暫的,但資料需要持久化
  • 責任分工:基礎架構 vs. 應用程式開發。
  • 資源管理:公平分配與追蹤使用情況。
  • 靈活性:支援靜態配置與動態配置。

這種設計看似「複雜」,但其實是為了在多租戶、共享資源的叢集環境下,提供更高的彈性與可管理性。


📖 參考資料:


上一篇
k8s雜記-6 為什麼會有 CRD 與 Operator?
下一篇
k8s雜記-8 Linux 網路基礎 (上篇) — interface、IP 與 route
系列文
30 天工程師雜學之旅22
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言