返回文章列表
玄貓（BlackCat）

Kubernetes 持久化儲存詳解與實務應用

本文探討 Kubernetes 持久化儲存機制，包含 PersistentVolume（PV）、PersistentVolumeClaim（PVC）、StorageClass 和動態佈建等核心概念，同時解析靜態與動態儲存組態的差異、回收策略的選擇以及 CSI

容器技術 雲端原生
Kubernetes PV PVC StorageClass CSI 持久化儲存

Kubernetes 提供了 PV 和 PVC 作為持久化儲存的抽象層，讓使用者不必直接管理底層儲存技術。PV 代表實際的儲存資源，而 PVC 則代表使用者對儲存的請求。透過 StorageClass，Kubernetes 可以根據 PVC 的需求動態佈建儲存資源，簡化管理流程。同時，CSI 介面讓 Kubernetes 能夠與更多儲存解決方案整合，提升儲存管理的彈性。本文也涵蓋了 PV 的生命週期和回收策略，讓使用者能更有效地管理儲存資源。

Kubernetes 持久化儲存詳解

在 Kubernetes 中，持久化儲存是確保資料在 Pod 重啟或刪除後仍然存在的關鍵機制。本章將探討 Kubernetes 的 PersistentVolume（PV）與 PersistentVolumeClaim（PVC）資源型別，並介紹如何使用它們來實作資料的持久化。

PersistentVolume（PV）詳解

PersistentVolume 是 Kubernetes 中的一種資源型別，用於表示持久化儲存卷。它可以是根據主機的 hostPath、NFS、iSCSI 或其他儲存技術的儲存卷。PV 的生命週期獨立於 Pod，可以在不同的 Pod 之間共用。

建立 hostPath 型別的 PersistentVolume

以下是一個簡單的 hostPath 型別的 PV 組態檔範例：

# pv-hostpath.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-hostpath
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

執行以下命令，將 PV 組態檔應用到 Kubernetes 叢集：

$ kubectl apply -f pv-hostpath.yaml
persistentvolume/pv-hostpath created

建立 NFS 型別的 PersistentVolume

以下是一個 NFS 型別的 PV 組態檔範例：

# pv-nfs.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /appshare
    server: nfs.example.com

建立原始區塊卷的 PersistentVolume

以下是一個原始區塊卷的 PV 組態檔範例：

# pv-block.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-block
spec:
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteOnce
  volumeMode: Block
  persistentVolumeReclaimPolicy: Retain
  fc:
    targetWWNs: ["50060e801049cfd1"]
    lun: 0
    readOnly: false

PersistentVolume 與儲存資源的供應

Kubernetes 可以與雲端供應商或其他儲存後端的 API 進行互動，以動態建立儲存資源。這種機制稱為動態供應（Dynamic Provisioning）。動態供應簡化了 PersistentVolume 的建立流程，但僅適用於支援的儲存後端或雲端供應商。

將 PersistentVolume掛載到 Pod

要將 PV 掛載到 Pod，需要使用另一個資源型別：PersistentVolumeClaim（PVC）。PVC 是使用者對持久化儲存資源的請求。

PersistentVolumeClaim（PVC）簡介

PVC 是 Kubernetes 中的另一種資源型別，用於表示對持久化儲存資源的請求。可以使用 kubectl 命令列出叢集中的 PVC 資源：

$ kubectl get persistentvolumeclaims
No resources found in default namespace.

或者使用別名 pvc：

$ kubectl get pvc
No resources found in default namespace.

詳細內容解說：

  1. PV 組態檔解析：上述三個 PV 組態檔範例分別展示瞭如何建立 hostPath、NFS 和原始區塊卷型別的 PV。這些組態檔定義了 PV 的屬性，例如容量、存取模式和儲存型別。
  2. 動態供應機制：Kubernetes 的動態供應機制允許叢集根據 PVC 的請求自動建立 PV。這種機制簡化了儲存資源的管理，但需要雲端供應商或儲存後端的支援。
  3. PVC 的作用：PVC 是使用者對持久化儲存資源的請求。透過建立 PVC，可以將 PV 掛載到 Pod 中，從而實作資料的持久化。

此圖示說明瞭 PV 和 PVC 之間的關係：

此圖示顯示了 PV 和 PVC 之間的互動關係，以及 PVC 如何將 PV 掛載到 Pod 中。

Kubernetes 中的持久儲存（Persistent Storage）解析

在 Kubernetes 環境中工作時，經常會遇到 PersistentVolumeClaim 資源被簡稱為 pvc。理解 PersistentVolumeClaim 的概念對於有效地使用 Kubernetes 至關重要。

儲存建立與消耗的分離

PersistentVolume 和 PersistentVolumeClaim 之間的區別在於，前者代表儲存本身，而後者代表 Pod 對儲存的請求。這種區分的原因在於 Kubernetes 的設計初衷是為兩類別使用者提供服務：

  • Kubernetes 管理員：負責維護叢集、新增計算資源和持久儲存。
  • Kubernetes 應用開發者：負責開發和佈署應用程式，消耗由管理員提供的計算資源和儲存。

在實際操作中，PersistentVolume 物件屬於叢集管理員的作用域，而 PersistentVolumeClaim 物件屬於應用開發者的作用域。管理員負責新增 PersistentVolume，而開發者則根據應用需求請求適當的儲存。

PersistentVolume 工作流程

當開發者需要持久儲存時，他們會建立兩個 YAML 清單檔：

  1. 一個用於 Pod 或 Deployment。
  2. 另一個用於 PersistentVolumeClaim。

Pod 的 YAML 檔案中必須包含 volumeMount 組態鍵，以掛載 PersistentVolumeClaim 物件。值得注意的是，PersistentVolumeClaim 物件必須與掛載它的應用 Pod 在相同的名稱空間中。

以下是靜態儲存組態的工作流程圖：

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title Kubernetes 持久化儲存詳解與實務應用

package "Kubernetes Cluster" {
    package "Control Plane" {
        component [API Server] as api
        component [Controller Manager] as cm
        component [Scheduler] as sched
        database [etcd] as etcd
    }

    package "Worker Nodes" {
        component [Kubelet] as kubelet
        component [Kube-proxy] as proxy
        package "Pods" {
            component [Container 1] as c1
            component [Container 2] as c2
        }
    }
}

api --> etcd : 儲存狀態
api --> cm : 控制迴圈
api --> sched : 調度決策
api --> kubelet : 指令下達
kubelet --> c1
kubelet --> c2
proxy --> c1 : 網路代理
proxy --> c2

note right of api
  核心 API 入口
  所有操作經由此處
end note

@enduml

建立使用 PersistentVolumeClaim 的 Pod

在本文中，我們將在 minikube 叢集中建立一個掛載 PersistentVolume 的 Pod。首先，需要建立一個 hostPath 型別的 PersistentVolume 物件。以下是相關的 YAML 檔案：

# pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-hostpath-pv
  labels:
    type: hostpath

內容解密：

  • apiVersion 和 kind 定義了 Kubernetes 資源的版本和型別。
  • metadata 部分定義了 PersistentVolume 的名稱和標籤，這些標籤將用於與 PersistentVolumeClaim 進行匹配。
  • 使用 hostPath 型別的 PersistentVolume 將其生命週期與 Pod 分離，使其能夠獨立管理。

接下來，開發者需要建立一個 PersistentVolumeClaim 物件來請求儲存。然後，Kubernetes 將匹配合適的 PersistentVolume 並將其繫結到 PersistentVolumeClaim。最後，Pod 將能夠透過 volumeMount 使用持久儲存。

深入理解Kubernetes中的持久化儲存

PersistentVolume與PersistentVolumeClaim的實作

在Kubernetes中，持久化儲存的管理是透過PersistentVolume（PV）與PersistentVolumeClaim（PVC）這兩個資源物件來完成的。PV代表了叢集中的實際儲存資源，而PVC則是對儲存資源的請求。

首先，我們來建立一個PersistentVolume物件，使用hostPath作為儲存型別。以下是一個範例的YAML檔案：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-hostpath-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/tmp/test"
  storageClassName: slow

內容解密：

  • capacity定義了PV的儲存容量。
  • accessModes指定了PV的存取模式，ReadWriteOnce表示該PV可以被一個節點以讀寫模式掛載。
  • hostPath指定了PV在節點上的實際路徑。
  • storageClassName定義了PV所屬的儲存類別。

接下來，建立一個PersistentVolumeClaim物件來請求儲存資源：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-hostpath-pvc
  namespace: pv-ns
spec:
  resources:
    requests:
      storage: 1Gi
  accessModes:
    - ReadWriteOnce
  storageClassName: slow
  selector:
    matchLabels:
      type: hostpath
      env: prod

內容解密：

  • resources.requests.storage指定了PVC請求的儲存容量。
  • accessModes與PV的存取模式相匹配。
  • storageClassName與PV的儲存類別相匹配。
  • selector.matchLabels用於匹配具有特定標籤的PV。

建立一個Pod來使用PVC：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: pv-ns
spec:
  containers:
    - image: nginx
      name: nginx
      volumeMounts:
        - mountPath: "/var/www/html"
          name: mypersistentvolume
  volumes:
    - name: mypersistentvolume
      persistentVolumeClaim:
        claimName: my-hostpath-pvc

內容解密：

  • volumeMounts指定了容器內掛載的卷。
  • volumes.persistentVolumeClaim.claimName指定了要使用的PVC名稱。

理解PersistentVolume的生命週期

PersistentVolume物件具有獨立的生命週期，與Pod或容器的生命週期無關。其生命週期階段包括：

  1. Provisioning：管理員建立PV。
  2. Unbound state：PV建立後處於未繫結狀態。
  3. Claiming：開發者建立PVC請求儲存資源。
  4. Matching and binding：Kubernetes將符合PVC要求的PV繫結到PVC。
  5. Using：Pod透過卷掛載使用繫結的PV。
  6. Releasing：當使用PVC的Pod被刪除，PVC變為未繫結狀態。
  7. Deletion：管理員可以根據設定的回收策略刪除PV物件。

PersistentVolume的回收策略

回收策略決定了當PVC被刪除後，PV的處理方式。常見的回收策略包括：

  • Retain：保留PV，等待管理員手動處理。
  • Delete：刪除PV及其實際儲存資料。
  • Recycle（已棄用）：回收PV，使其可供新的PVC使用。

瞭解這些機制有助於更好地管理和使用Kubernetes中的持久化儲存資源。

持久化儲存的回收策略與動態佈建

在 Kubernetes 中，持久化儲存（Persistent Storage）的管理是透過 PersistentVolume（PV）和 PersistentVolumeClaim（PVC）來實作的。當 PVC 被刪除後，PV 的回收策略（Reclaim Policy）決定了 PV 的下一步處理方式。瞭解不同的回收策略和動態佈建對於有效地管理持久化儲存至關重要。

回收策略

Kubernetes 提供了三種回收策略，分別是 Delete、Retain 和 Recycle。

Delete

當設定為 Delete 時，一旦對應的 PVC 被刪除，PV 將被自動刪除，其上的資料也會被清除。這種策略適用於不需要保留資料的情況，但需要注意，一旦刪除，資料將無法還原。

Retain

Retain 策略與 Delete 相反，當 PVC 被刪除後，PV 不會被刪除，而是進入 Released 狀態。這意味著 PV 仍然存在於叢集中，其上的資料可以被管理員手動檢索。這種策略適用於需要保留資料的情況。

Recycle（已棄用）

Recycle 策略曾經是一種折衷方案，它會清除 PV 上的資料，但保留 PV 本身，使其可以被再次使用。然而，這種策略已被棄用，現在推薦使用動態佈建。

更新回收策略

幸運的是，回收策略可以在 PV 建立後進行更新。這提供了很大的靈活性，可以根據實際需求調整策略。

演示回收策略的差異

首先，刪除正在使用 PVC 的 Pod，然後刪除 PVC。接著，檢查 PV 的狀態。如果 PV 的回收策略是 Retain，它將進入 Released 狀態，但不會被刪除。可以透過 kubectl patch 命令更新 PV 的回收策略為 Delete。一旦更新，PV 將被自動刪除。

$ kubectl delete pod nginx -n pv-ns
$ kubectl delete pvc my-hostpath-pvc -n pv-ns
$ kubectl get pv
$ kubectl patch pv/my-hostpath-pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Delete"}}'
$ kubectl get pv

PersistentVolume 和 PersistentVolumeClaim 的狀態

PV 和 PVC 可以具有不同的狀態，瞭解這些狀態對於有效地管理持久化儲存非常重要。

PersistentVolume 的狀態

  • Available：新建立的 PV，尚未被繫結到 PVC。
  • Bound：PV 已被 PVC 繫結，目前正在被使用。
  • Released：PVC 已被刪除，但 PV 仍保留在叢集中。
  • Failed：PV 發生錯誤，無法使用。
  • Unknown：由於與底層儲存系統的通訊失敗，PV 的狀態未知。

PersistentVolumeClaim 的狀態

  • Pending：PVC 正在等待被繫結到 PV。
  • Bound：PVC 已被繫結到 PV，目前正在被使用。
  • Terminating：PVC 正在被刪除。

靜態佈建與動態佈建

靜態佈建需要事先手動建立儲存資源，然後在 Kubernetes 中建立 PV 和 PVC。動態佈建則是透過 StorageClass 自動建立 PV，無需手動干預。動態佈建大大簡化了持久化儲存的管理，尤其是在大規模環境中。

Kubernetes 中的持久儲存：深入解析與實務應用

在 Kubernetes 環境中，持久儲存（Persistent Storage）是確保資料在 Pod 重啟或刪除後仍然存在的關鍵技術。本文將探討 Kubernetes 中的持久儲存機制，涵蓋 PersistentVolume（PV）、PersistentVolumeClaim（PVC）、StorageClass（SC）以及 Container Storage Interface（CSI）等重要概念。

靜態與動態儲存組態

在 Kubernetes 中，儲存組態可以分為靜態和動態兩種方式。

靜態儲存組態

靜態儲存組態需要管理員手動建立 PersistentVolume（PV），然後由開發者建立 PersistentVolumeClaim（PVC）來請求儲存資源。這種方式需要管理員事先準備好儲存資源，並手動建立 PV。

靜態儲存組態的步驟如下：

  1. 管理員建立 EBS Volume。
  2. 管理員建立 PV YAML 定義檔，並將 EBS Volume 的 ID 複製到該檔中。
  3. 使用 YAML 檔建立 PV。
  4. 開發者建立 PVC 來請求儲存資源。
  5. 將 PVC 掛載到 Pod 中。

動態儲存組態

動態儲存組態則是由 Kubernetes 自動建立 PV，以滿足 PVC 的請求。這種方式需要使用 StorageClass（SC）來定義儲存資源的型別和引數。

動態儲存組態的步驟如下：

  1. 管理員安裝和設定 CSI Driver 和 StorageClass。
  2. 開發者建立 PVC，並指定 StorageClass。
  3. Kubernetes 自動觸發 CSI Driver 建立儲存資源。
  4. CSI Driver 與後端儲存系統通訊，建立 Volume 並產生 PV。
  5. 將 PVC 掛載到 Pod 中。

Container Storage Interface（CSI）

CSI 是 Kubernetes 與各種儲存解決方案之間的橋樑，提供了一個標準化的介面來暴露儲存資源給容器工作負載。CSI Driver 是由儲存供應商提供的容器化實作，負責提供儲存資源的建立、掛載、解除安裝和管理等功能。

StorageClass（SC）

StorageClass 是 Kubernetes 中的一種資源型別，用於定義儲存資源的型別和引數。SC 提供了一個使用者友好的介面，讓開發者可以請求儲存資源，而無需關心底層的儲存技術細節。

使用 kubectl get sc 命令可以列出目前叢集中的 StorageClass 資源。

實務應用與最佳實踐

在實務應用中，建議使用動態儲存組態，以簡化儲存資源的管理和提高效率。同時，應根據實際需求選擇合適的 StorageClass 和 CSI Driver，以確保儲存資源的可靠性和效能。

程式碼範例：建立 PVC 和 Pod

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: standard

---
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
    volumeMounts:
    - name: my-pvc
      mountPath: /data
  volumes:
  - name: my-pvc
    persistentVolumeClaim:
      claimName: my-pvc

內容解密：

  1. PVC 定義：首先定義了一個名為 my-pvc 的 PVC，請求 1Gi 的儲存空間，並指定使用 standard StorageClass。
  2. Pod 定義：然後定義了一個名為 my-pod 的 Pod，使用 nginx 映像，並將 my-pvc 掛載到 /data 目錄下。
  3. 動態儲存組態：當建立 PVC 時，Kubernetes 會自動觸發 CSI Driver 建立儲存資源，並產生 PV 以滿足 PVC 的請求。