kuberbetes-PVC與PV的建立 和繫結

little小新發表於2024-06-13

PVC與PV的建立

如下yaml檔案

apiVersion: v1
kind: PersistentVolume  #PV是叢集中的一塊儲存，可以由PVC請求並使用。-虛擬儲存 - 實體機的儲存、不是容器中的儲存
metadata:
  name: postgresql-pv  
  namespace: ops-system
spec:
  storageClassName: nfs   #指定了與此PV關聯的儲存類（StorageClass）是nfs
  accessModes:            #這定義了PV可以被如何訪問
    - ReadWriteMany       #表示該PV可以被多個節點以讀寫模式同時訪問。
  capacity:               #這定義了PV的儲存容量。
    storage: 200Mi        #指定了該PV的儲存容量為200兆位元組。 可用於被PVC繫結的條件
  nfs:                                #定義了NFS（網路檔案系統）的具體配置
    path: /vol/nfsshare/kong/data     #這是NFS伺服器上的共享目錄的路徑，Kubernetes節點將掛載這個目錄來訪問儲存。
    server: 192.168.19.3              #這是NFS伺服器的IP地址
---
#PVC是使用者對儲存資源的請求，當PVC被建立後，Kubernetes會嘗試找到一個與之匹配的PersistentVolume（PV）來繫結
#如果沒有建立PV PVC也會透過StorageClass 動態的建立PV
#當 PVC 和 PV 成功繫結後，PVC 可以被應用（Pod）使用。應用程式透過 PVC 掛載儲存卷，獲取持久儲存空間
apiVersion: v1    #指定了Kubernetes API的版本，用於該資源定義
kind: PersistentVolumeClaim   #PVC是使用者對儲存資源的請求，當建立PVC後，Kubernetes將嘗試找到一個匹配的PV來滿足這個請求 - -虛擬儲存 - 實體機的儲存、不是容器中的儲存
metadata:
  name: postgresql-pvc    
  namespace: ops-system
spec:
  storageClassName: nfs   #這指定了PVC應該使用哪個StorageClass。在這裡，它指定了nfs，意味著這個PVC希望與一個基於NFS的PV進行繫結。
  accessModes:            #這定義了PVC可以如何訪問儲存資源。
    - ReadWriteMany       #表示這個PVC希望PV支援多個節點以讀寫模式同時訪問。
  resources:              #這定義了PVC對儲存資源的需求。
    requests:             #指定了PVC請求的儲存資源的大小
      storage: 200Mi      #找到對應的PV storage 為200Mi的進行繫結
  
#一旦這個PVC被建立，Kubernetes將嘗試找到一個與之匹配的PV（在這個例子中，可能是一個名為postgresql-pv的PV，其規格與這個PVC相匹配）並進行繫結。
#如果找到了匹配的PV，那麼這個PV的儲存資源就可以被使用這個PVC的Pod所使用。如果沒有找到匹配的PV，PVC將保持未繫結狀態，直到有匹配的PV可用為止
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: iam-pv
  namespace: ops-system
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteMany
  capacity:
    storage: 100Mi
  nfs:
    path: /vol/nfsshare/iam/assets
    server: 192.168.19.3
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: iam-pvc
  namespace: ops-system
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 100Mi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: lap-pv
  namespace: ops-system
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteMany
  capacity:
    storage: 1Gi
  nfs:
    path: /vol/nfsshare/lap/uploads
    server: 192.168.19.3
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: lap-pvc
  namespace: ops-system
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: ops-manage-pv
  namespace: ops-system
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteMany
  capacity:
    storage: 50Gi
  nfs:
    path: /vol/nfsshare/ops-manage/key_cfg_compare
    server: 192.168.19.3
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ops-manage-pvc
  namespace: ops-system
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 50Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: ops-ledger-pv
  namespace: ops-system
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteMany
  capacity:
    storage: 2Gi
  nfs:
    path: /vol/nfsshare/ops-ledger/images
    server: 192.168.19.3
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ops-ledger-pvc
  namespace: ops-system
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2Gi

PVC 繫結PV的屬性

注意：pvc繫結pv 與name無關

在 Kubernetes 中，PersistentVolumeClaim (PVC) 和 PersistentVolume (PV) 的繫結是基於一組特定的屬性進行匹配和選擇的。
以下是 PVC 和 PV 繫結時所考慮的主要屬性：

#PVC 和 PV 繫結的關鍵屬性
# 1. 儲存容量
容量匹配: PV 的 spec.capacity.storage 必須至少等於 PVC 請求的 spec.resources.requests.storage。
單位相容性: Kubernetes 支援多種單位（如 Gi、Mi 等），要求 PV 的容量單位與 PVC 請求的單位相容。

# 2. 訪問模式
訪問模式型別: PV 和 PVC 必須具有相容的訪問模式，如 ReadWriteOnce (RWO)、ReadOnlyMany (ROX) 和 ReadWriteMany (RWX)。
精確匹配: PVC 的 spec.accessModes 必須與 PV 的 spec.accessModes 中的至少一種匹配。

# 3. 儲存類別 (StorageClass)
StorageClass 匹配: PVC 的 spec.storageClassName 必須與 PV 的 spec.storageClassName 相匹配。
預設行為: 如果 PVC 和 PV 都沒有指定 storageClassName 或都設定為 ""，則它們可以互相匹配。
動態供應: 如果沒有現成的 PV 與 PVC 匹配，且 PVC 指定了 storageClassName，Kubernetes 會嘗試根據 StorageClass 動態建立一個 PV。

# 4. 標籤和選擇器
PV 標籤: PV 可以有多個標籤（鍵值對），用於描述 PV 的屬性或特性。
PVC 選擇器: PVC 可以使用 spec.selector 來指定必須匹配的標籤。
選擇器可以是一個標籤的集合，PVC 只有找到匹配這些標籤的 PV 才會繫結。

yaml
spec:
  selector:
    matchLabels:
      key: value

# 5. 區域和可用區
區域性匹配: 在多區域部署中，PVC 和 PV 需要在同一區域或可用區，特別是對於一些需要區域性儲存的雲服務。
拓撲約束: 一些儲存提供者可能要求 PV 和 PVC 在同一個拓撲（如同一資料中心或可用區），這在雲環境中尤為重要。

# 6. 回收策略
回收策略要求: PVC 只能繫結到回收策略與其預期相匹配的 PV。常見的回收策略有 Recycle、Retain 和 Delete。
動態繫結的策略: 動態建立的 PV 通常具有 Delete 策略，意味著當 PVC 被刪除時，PV 也會自動刪除。

# 7. 繫結狀態
未繫結狀態: 只有狀態為 Available 的 PV 才能與 PVC 繫結。
繫結後狀態: 一旦繫結，PVC 和 PV 的狀態會分別更新為 Bound，表示已成功建立連線。

#8. 持久卷索賠後設資料
PVC 後設資料: 包括 PVC 的名稱和名稱空間，它們必須唯一且符合 Kubernetes 的命名規則。
PV 後設資料: PV 包含類似的後設資料，以及它與 PVC 的繫結關係。

# 9. 其他特性
PV 型別: PV 的型別（如 NFS、Ceph、AWS EBS 等）需要與 PVC 的使用要求相匹配。
效能要求: 有些儲存型別可能對效能有特定要求，比如 IOPS、吞吐量等，PVC 可以透過註釋等方式指定。
PVC 和 PV 的繫結是 Kubernetes 中儲存資源管理的核心機制，透過對儲存容量、訪問模式、StorageClass、標籤選擇器等屬性的匹配
確保 PVC 和 PV 能夠準確地連線和使用。這種機制不僅提供了靈活和高效的儲存管理，還簡化了應用程式對儲存資源的使用、使得儲存管理變得更加自動化和透明化。

案例

在這個例子中，my-pvc 將與標籤為 type: fast-storage 且滿足容量和訪問模式要求的 my-pv 進行繫結。

PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: standard
  selector:
    matchLabels:
      type: fast-storage

PV

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
  labels:
    type: fast-storage
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  storageClassName: standard
  hostPath:
    path: /mnt/data

相關文章