Kubernetes Pod 的生命週期特性決定了資料持久化的必要性。本文將探討如何在 EKS 平台上使用 Persistent Volume 和 Persistent Volume Claim 來解決這個問題，確保資料在 Pod 重新啟動或刪除後依然存在。首先，我們會解釋 PV 和 PVC 的核心概念，並提供 YAML 檔案範例，讓讀者瞭解如何設定這些資源。接著，會逐步說明如何在 Deployment 中使用 PVC，將持久化儲存掛載到 Pod 中。最後，我們將透過實際案例，演示如何驗證持久化儲存的功能，並探討一些常見的錯誤排除方法和擴充套件測試場景。
在EKS中實作資料持久化：探討Persistent Volumes與Persistent Volume Claims
導言
在現代雲端原生應用程式的開發與佈署過程中，資料持久化（Data Persistence）是一項至關重要的議題。Amazon Elastic Kubernetes Service（EKS）作為一個受管理的Kubernetes服務，為開發者提供了強大的容器協調能力。然而，在預設情況下，Kubernetes中的Pod並不具備持久化資料的能力，一旦Pod被刪除或重新排程，其內部的資料將會遺失。因此，如何在EKS中實作資料持久化，成為了一個關鍵性的挑戰。
本文將探討在EKS中使用Persistent Volumes（PV）與Persistent Volume Claims（PVC）來實作資料持久化的過程。我們將詳細介紹PV與PVC的概念、組態方法，以及如何在實際應用中有效地利用這些資源來確保資料的安全與永續性。
Persistent Volumes（PV）的基本概念
在Kubernetes中，Persistent Volume（PV）是一種用於抽象底層儲存資源的API物件。PV代表了一塊可被Pod使用的儲存空間，它獨立於Pod的生命週期存在，從而實作了資料的持久化。PV的建立與管理通常由叢集管理員負責，而開發者則透過Persistent Volume Claim（PVC）來請求所需的儲存資源。
PV的關鍵屬性
- accessModes：定義了PV的存取模式，包括ReadWriteOnce（RWO）、ReadOnlyMany（ROX）、ReadWriteMany（RWX）以及ReadWriteOncePod（RWOP）。在EKS環境中，選擇合適的存取模式對於確保資料的一致性和可用性至關重要。
- capacity：指定了PV的儲存容量，單位可以是Gi（Gigabytes）或Mi（Mebibytes）等。
- storageClassName：用於將PV歸類別到特定的StorageClass中，這使得開發者可以根據不同的儲存需求請求合適的儲存資源。
- hostPath：在某些環境中（如本地開發或測試），PV可以透過hostPath直接對映到主機上的特定目錄。
建立Persistent Volume（PV）
以下是一個建立PV的YAML檔案範例，用於在EKS叢集中提供一塊2GB的儲存空間：
apiVersion: v1
kind: PersistentVolume
metadata:
name: nginxdata
spec:
accessModes:
- ReadWriteOnce
capacity:
storage: 2Gi
hostPath:
path: /nginxdata
storageClassName: webcontent
程式碼解析：
- apiVersion 與 kind：定義了該資源的API版本和型別，在此為
PersistentVolume。 - metadata.name：指定了PV的名稱為
nginxdata。 - spec.accessModes：設定為
ReadWriteOnce，表示該PV可以被單一節點以讀寫模式掛載。 - spec.capacity.storage：定義了PV的容量為2Gi。
- spec.hostPath.path：指定了在主機上的儲存路徑為
/nginxdata。 - spec.storageClassName：將該PV歸類別到名為
webcontent的StorageClass中。
內容解密：
此YAML檔案定義了一個名為nginxdata的PV，容量為2GB，存取模式為ReadWriteOnce，並且被歸類別到webcontent StorageClass中。這意味著該PV適用於需要持久化儲存的應用程式，例如網頁伺服器的內容儲存。
建立Persistent Volume Claim（PVC）
當PV建立完成後，開發者可以透過建立Persistent Volume Claim（PVC）來請求所需的儲存資源。PVC是一種宣告式的API，用於請求特定大小和存取模式的儲存資源。
以下是一個建立PVC的YAML檔案範例：
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: webcontent
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: webcontent
程式碼解析：
- metadata.name：指定了PVC的名稱為
webcontent。 - spec.accessModes：與PV一致，設定為
ReadWriteOnce。 - spec.resources.requests.storage：請求1Gi的儲存空間。
- spec.storageClassName：指定了所需的StorageClass名稱為
webcontent，與PV一致。
內容解密：
此PVC請求了1Gi的儲存空間，並且指定了ReadWriteOnce的存取模式，同時要求StorageClass為webcontent。當PVC被建立後，Kubernetes會自動將其與符合條件的PV進行繫結，從而實作儲存資源的分配。
驗證PV與PVC的狀態
在建立PV和PVC之後，我們需要驗證它們的狀態，以確保儲存資源被正確分配。
檢查PV狀態：
microk8s kubectl get pv
輸出範例：
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
nginxdata 2Gi RWO Retain Available webcontent 2m15s
檢查PVC狀態：
microk8s kubectl get pvc
輸出範例（在修正StorageClass名稱之前）：
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
webdata Pending webdata 19s
輸出範例（在修正StorageClass名稱之後）：
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
webcontent Bound nginxdata 2Gi RWO webcontent 1m
內容解密：
在初始階段，由於PVC中指定的StorageClass名稱webdata與PV中的webcontent不匹配，導致PVC的狀態為Pending。當我們將PVC中的StorageClass名稱修正為webcontent後，PVC成功綁定了名為nginxdata的PV，狀態變為Bound。
修正StorageClass名稱並重新佈署
當發現PVC的StorageClass名稱與PV不一致時，我們需要進行修正並重新佈署。
操作步驟：
-
刪除錯誤的PVC：
microk8s kubectl delete pvc webdata -
更新PVC的YAML檔案： 將
storageClassName從webdata修正為webcontent。 -
重新建立PV和PVC：
microk8s kubectl apply -f pv.yaml microk8s kubectl apply -f pvc.yaml
內容解密：
透過上述步驟，我們確保了PVC能夠正確繫結到預先建立的PV，從而實作了儲存資源的有效利用。
隨著雲端原生技術的持續發展，資料持久化的解決方案也在不斷進化。未來，我們可以期待更多創新性的儲存解決方案，以滿足日益增長的資料儲存和管理需求。在EKS環境中，持續關注最新的儲存技術和最佳實踐，將有助於構建更加穩健和高效的雲端原生應用程式。
Kubernetes 中的持久化儲存實戰：使用 Persistent Volume Claim (PVC)
在 Kubernetes 叢集中，資料持久化是確保應用程式穩定執行的關鍵因素之一。Persistent Volume Claim (PVC) 為開發者提供了一種宣告式的方式來請求持久化儲存資源。本文將詳細介紹如何在 Kubernetes 中使用 PVC 實作資料持久化，並結合實際案例進行深入剖析。
建立 Persistent Volume Claim (PVC)
首先，我們需要建立一個 PVC 物件來請求持久化儲存資源。以下是一個簡單的 pvc.yaml 組態檔案範例：
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: webdata
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 2Gi
storageClassName: webcontent
內容解密：
apiVersion和kind指定了 Kubernetes 物件的版本和型別。metadata.name定義了 PVC 的名稱。spec.accessModes設定了 PVC 的存取模式，ReadWriteOnce表示該 PVC 可以被一個節點以讀寫模式掛載。spec.resources.requests.storage指定了所需的儲存空間大小。storageClassName定義了使用的 StorageClass。
執行以下命令建立 PVC：
microk8s kubectl apply -f pvc.yaml
檢查 PVC 狀態：
microk8s kubectl get pvc
輸出結果顯示 PVC 的狀態為 Bound，表示 PVC 已成功繫結到一個 Persistent Volume (PV)。
在 Deployment 中使用 PVC
接下來，我們需要在 Deployment 組態檔案中使用剛才建立的 PVC。以下是一個包含 PVC 的 mynginx-pvc.yaml 組態檔案範例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: mydeployment-ch15pvc
spec:
selector:
matchLabels:
app: mynginx
template:
metadata:
labels:
app: mynginx
spec:
containers:
- name: mynginx
image: nginx
ports:
- containerPort: 80
volumeMounts:
- name: nginxdata
mountPath: /usr/share/nginx/html
volumes:
- name: nginxdata
persistentVolumeClaim:
claimName: webdata
內容解密：
spec.template.spec.containers.volumeMounts定義了容器內部的掛載點。spec.template.spec.volumes定義了持久化儲存卷，並關聯到名為webdata的 PVC。
執行以下命令佈署應用：
microk8s kubectl apply -f mynginx-pvc.yaml
驗證持久化儲存功能
首先，建立一個 LoadBalancer 服務來暴露我們的 Nginx 應用：
microk8s kubectl apply -f myservice01.yaml
檢查服務狀態：
microk8s kubectl get service
使用 curl 命令存取 Nginx 服務：
curl -L localhost:30439
由於掛載點下沒有 index.html 檔案，Nginx 將傳回 403 Forbidden 錯誤。
在主機上建立 index.html 檔案並寫入內容：
sudo chown shiva:shiva /nginxdata
sudo chmod 755 /nginxdata
echo -e "<html>\n<title>\nnew title\n</title>\n<body>\nnew content\n</body>\n</html>" > /nginxdata/index.html
再次存取 Nginx 服務：
curl localhost:30439
此時，Nginx 將傳回我們剛才建立的 index.html 內容。
擴充套件測試
將 Deployment 縮放至 3 個副本：
microk8s kubectl scale --replicas=3 deployment mydeployment-ch15pvc
檢查 Deployment 狀態：
microk8s kubectl get deployments
所有 Pod 都將分享同一個 PVC，並傳回相同的內容。
隨著 Kubernetes 生態系統的不斷發展，持久化儲存解決方案也在不斷演進。未來，我們可以期待更多高效、可靠的儲存方案出現，以滿足日益增長的資料儲存需求。
參考資料
圖表說明
graph LR
A[Kubernetes 叢集] -->|建立|> B(Persistent Volume Claim)
B -->|繫結|> C(Persistent Volume)
C -->|掛載|> D[Deployment]
D -->|分享|> E[多個 Pod]
E -->|存取|> F[持久化儲存]
圖表翻譯：
此圖示展示了在 Kubernetes 叢集中建立 PVC、繫結 PV、掛載到 Deployment 以及多個 Pod 分享持久化儲存的流程。透過這個流程，可以實作應用的資料持久化，提高資料的可靠性和一致性。
