2025年05月10日玄貓（BlackCat）

Kubernetes 持久化儲存實務操作

本文探討 Kubernetes 持久化儲存的實務操作，涵蓋 Persistent Volume（PV）與 Persistent Volume Claim（PVC）的使用方法，並以實際案例展示如何驗證佈署擴充套件、測試 Web 伺服器連線以及釋放資源。文章也詳細說明瞭如何在 AWS EKS 環境中使用 EFS CSI

Kubernetes 雲端原生

持久化儲存 PV PVC EKS EFS CSI Driver

Kubernetes 提供了 PV 和 PVC 機制來管理持久化儲存，確保應用程式資料的可靠性。本文將逐步示範如何操作 PV 和 PVC，並驗證其在實際佈署中的效果。首先，透過 kubectl get pods 指令確認佈署的 Pod 狀態是否為 Running，接著使用 kubectl describe service 指令檢查 Service 的 Endpoints，確保所有 Pod 都正常連線到 Service。為了驗證 Web 伺服器功能，我們使用 curl 指令模擬使用者端請求，並透過 kubectl logs 指令檢查每個 Pod 的存取日誌，確認請求分佈情況。操作完成後，依序刪除 Deployment、PVC 和 PV 以釋放資源。在 AWS EKS 環境中，持久化儲存的實作方式略有不同。由於無法直接存取底層節點，需要使用雲端提供的儲存服務，例如 EFS。透過佈署 EFS CSI Driver，Kubernetes 可以動態組態和管理 EFS 檔案系統。首先，建立 IAM Policy 賦予 Driver 操作 EFS 的許可權，接著建立 IAM Service Account 並將其與 Policy 關聯。最後，使用 kubectl get sa 指令驗證 Service Account 是否成功建立。

Kubernetes 資料持久化實務操作

在前面的章節中，我們已經瞭解了 Kubernetes 中的資料持久化概念與相關技術。本章節將探討如何在實際環境中操作 Kubernetes 的 Persistent Volume（PV）與 Persistent Volume Claim（PVC），並透過實際案例展示其使用方法。

驗證佈署擴充套件是否成功

首先，我們需要確認 Kubernetes 佈署的擴充套件是否如預期般成功執行。透過以下指令，我們可以檢視目前執行的 Pod 狀態：

microk8s kubectl get pods

執行結果如下所示：

NAME                                    READY   STATUS    RESTARTS   AGE
mydeployment-ch15pvc-fb65494b8-rmtst   1/1     Running   0          57m
mydeployment-ch15pvc-fb65494b8-6j8x8   1/1     Running   0          85s
mydeployment-ch15pvc-fb65494b8-p9bph   1/1     Running   0          85s

內容解密：

此指令用於查詢目前 Kubernetes 叢集中所有執行的 Pod。輸出結果顯示了 Pod 的名稱、準備就緒的容器數量、目前狀態、重啟次數以及 Pod 的存在時間。在這個案例中，我們可以看到有三個 Pod 正在執行，狀態均為 Running，表示我們的佈署擴充套件成功。

另一種確認擴充套件成功的方法是透過描述 Service 物件並檢查其 Endpoints：

microk8s kubectl describe service myservice

執行結果範例如下：

Name:              myservice
Namespace:         default
Labels:            <none>
Annotations:       <none>
Selector:         app=mynginx
Type:              LoadBalancer
IP Family Policy: SingleStack
IP Families:       IPv4
IP:                10.152.183.191
IPs:               10.152.183.191
Port:              <unset>  80/TCP
TargetPort:        80/TCP
NodePort:          <unset> 30439/TCP
Endpoints:         10.1.166.3:80,10.1.166.4:80,10.1.166.5:80
Session Affinity:  None

內容解密：

此指令用於查詢特定 Service 的詳細資訊。輸出結果中的 Endpoints 欄位列出了目前與該 Service 相關聯的 Pod IP 位址與連線埠號。在本例中，我們可以看到有三個 Endpoints 對應到不同的 Pod，這與我們設定的 replica 數量相符，進一步確認了佈署擴充套件的成功。

測試 Web 伺服器連線

接下來，我們需要測試 Web 伺服器是否正常運作。透過以下 bash 指令碼，我們可以模擬多次請求存取 Web 伺服器：

i=0; while [ $i -le 13 ]; do curl localhost:30439; ((i=i+1)); echo -e "count: $i \n"; done

執行結果範例如下：

<html>
<title>
new title
</title>
<body>
new content
</body>
</html>
count:1

<html>
<title>
new title
</title>
<body>
new content
</body>
</html>
count:2
...

內容解密：

此指令碼使用 curl 指令重複存取本地端的 30439 連線埠，並在每次請求後輸出目前的計數。從輸出結果中，我們可以看到每次請求都傳回相同的網頁內容，這表明我們的 Web 伺服器正在正常運作。

為了確認請求是否均勻分佈到各個 Pod 上，我們可以檢查每個 Pod 的存取日誌：

microk8s kubectl logs mydeployment-ch15pvc-fb65494b8-rmtst --tail 7
microk8s kubectl logs mydeployment-ch15pvc-fb65494b8-6j8x8 --tail 7
microk8s kubectl logs mydeployment-ch15pvc-fb65494b8-p9bph --tail 7

執行結果範例如下：

192.168.0.81 - - [27/Aug/2023:17:00:02 +0000] "GET / HTTP/1.1" 200 69 "-" "curl/7.81.0" "-"
192.168.0.81 - - [27/Aug/2023:17:04:16 +0000] "GET / HTTP/1.1" 200 69 "-" "curl/7.81.0" "-"
...

內容解密：

透過檢查每個 Pod 的日誌，我們可以確認請求是否被均勻分配到各個 Pod 上。在本例中，我們可以看到每個 Pod 都接收到了請求，並且傳回了相同的內容，這證明瞭我們的佈署使用了相同的 PVC，並且資料被正確分享。

釋放 PVC 與 PV

當我們完成相關操作後，需要清理資源以釋放 PVC 與 PV。首先，我們需要刪除使用 PVC 的 Deployment：

microk8s kubectl delete deployment mydeployment-ch15pvc

執行結果如下所示：

deployment.apps "mydeployment-ch15pvc" deleted

內容解密：

此指令用於刪除指定的 Deployment 物件。刪除後，所有與該 Deployment 相關的 Pod 都將被終止。

接著，我們可以刪除 PVC：

microk8s kubectl delete pvc webcontent

執行結果如下所示：

persistentvolumeclaim "webcontent" deleted

內容解密：

刪除 PVC 後，相關的 Persistent Volume 也將被釋放。我們可以透過以下指令確認 PVC 是否已被刪除：

microk8s kubectl get pvc

執行結果如下所示：

No resources found in default namespace.

最後，我們需要手動刪除 PV：

microk8s kubectl delete pv <pv_name>

內容解密：

刪除 PV 是資源清理的最後一步。確保在刪除 PV 之前，相關的 PVC 已經被刪除，否則可能會導致刪除失敗。

在未來的章節中，我們將進一步探討 Kubernetes 中的其他進階主題，例如 StatefulSet、網路策略等。這些內容將幫助讀者更全面地掌握 Kubernetes 的應用與管理技巧。

在AWS EKS中實作持久化儲存

佈署Nginx容器並存取

首先，我們需要在AWS EKS叢集中佈署一個Nginx容器，以確保我們的環境設定正確。建立一個名為mydeployment.yaml的佈署檔案，內容如以下程式碼所示：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mydeployment
spec:
  selector:
    matchLabels:
      app: label-nginx
  template:
    metadata:
      labels:
        app: label-nginx
    spec:
      containers:
      - ports:
        - containerPort: 80
        name: name-nginx
        image: nginx

內容解密：

apiVersion 和 kind 定義了Kubernetes資源的版本和型別，這裡是Deployment。
metadata 包含了佈署的後設資料，如名稱。
spec 定義了佈署的規格，包括選擇器、範本和容器細節。
selector 和 template.metadata.labels 必須匹配，以便Deployment管理正確的Pod。
containers 部分定義了容器埠和使用的映象。

執行以下命令以佈署Nginx：

kubectl apply -f mydeployment.yaml

建立服務並存取Nginx

建立一個服務以存取Nginx容器，執行以下命令：

kubectl create service nodeport label-nginx --tcp=80:80
kubectl get services

內容解密：

kubectl create service nodeport 建立了一個NodePort型別的服務，將容器的80埠對映到節點的某個埠上。
kubectl get services 列出了叢集中的所有服務，可以檢視服務的埠對映情況。

取得節點的外部IP，以便存取Nginx服務：

kubectl describe nodes | grep -i ExternalIP

使用取得的外部IP和埠號存取Nginx服務：

curl <節點的外部IP>:<NodePort>

內容解密：

需要更新安全組規則以允許流入的流量到指定的NodePort，否則連線會超時。

更新安全組規則

登入AWS管理控制檯，前往EKS服務。
選擇叢集，點選「組態」標籤，然後點選「網路」下的安全組。
在安全組頁面，選擇「入站規則」標籤，點選「編輯入站規則」。
新增一條規則：
- 型別：自定義TCP
- 埠範圍：對應的NodePort（例如31747）
- 來源：自定義，0.0.0.0/0
- 描述：可選，例如「Nginx服務」

更新安全組規則後，再次嘗試存取Nginx服務：

curl <節點的外部IP>:<NodePort>

內容解密：

正確的組態應該傳回Nginx的預設首頁。

持久化儲存的需求

在AWS EKS中，由於無法直接存取底層節點，因此不能像在microk8s中那樣直接在主機上建立目錄作為持久化儲存。Kubernetes支援多種儲存機制，包括NFS、iSCSI和雲端提供商特定的儲存系統。AWS提供了多種儲存選項。

Persistent Volumes在AWS EKS中的實作

AWS EKS支援使用Persistent Volumes（PV）和StatefulSets來實作持久化儲存。具體實作細節包括：

使用Amazon EBS（Elastic Block Store）作為持久化儲存卷。
建立Persistent Volume Claims（PVC）來請求儲存資源。
將PVC掛載到Pod中使用。

程式碼範例：建立Persistent Volume Claim

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

內容解密：

accessModes 定義了PVC的存取模式，ReadWriteOnce表示該卷可以被一個節點以讀寫模式掛載。
resources.requests.storage 指定了所需的儲存容量。

隨著雲端原生技術的發展，Kubernetes和AWS EKS的整合將變得更加緊密。未來，我們可以期待更多的儲存解決方案和更高效的持久化儲存管理機制。

EKS持久化儲存架構

圖表翻譯： 此圖示展示了在AWS EKS中使用Persistent Volume Claims和Persistent Volumes實作持久化儲存的架構。Pod透過PVC請求儲存資源，PVC繫結到PV，而PV則由Amazon EBS提供具體的儲存實作。

在 Amazon EKS 中實作持久化儲存：EFS CSI Driver 的佈署與組態

在 Amazon Elastic Kubernetes Service（EKS）中，持久化儲存是確保應用程式資料得以保留的關鍵。根據 AWS 官方檔案，EKS 提供了兩種持久化儲存方案：Amazon Elastic Block Store（EBS）和 Amazon Elastic File System（EFS）。本篇文章將重點介紹如何使用 EFS 來實作持久化儲存，並詳細闡述 EFS CSI Driver 的佈署與組態過程。

為什麼選擇 Amazon EFS？

Amazon EFS 提供了一個類別似於 NFS 的檔案系統，能夠讓多個 Pod 同時掛載並存取相同的檔案系統。這對於需要分享檔案的應用程式（如靜態網站內容）來說非常有用。相較於 EBS，EFS 的優勢在於其可擴充套件性和多個例項同時存取的能力。

佈署 Amazon EFS CSI Driver

要使用 EFS，首先需要佈署 Amazon EFS CSI Driver。CSI（Container Storage Interface）是一種標準化介面，讓 Kubernetes 能夠與不同的儲存系統進行互動。EFS CSI Driver 使得 Kubernetes 能夠動態地組態和管理 EFS 檔案系統。

步驟 1：建立 IAM Policy

首先，需要建立一個 IAM Policy，以允許 EFS CSI Driver 對 EFS 進行操作。可以使用 AWS 提供的範例 Policy 檔案。

curl -o iam-policy-example.json https://raw.githubusercontent.com/kubernetes-sigs/aws-efs-csi-driver/v1.2.0/docs/iam-policy-example.json

內容解密：

此命令下載了一個 JSON 檔案，其中定義了 EFS CSI Driver 所需的許可權。該檔案包含了允許 Driver 對 EFS 進行操作所需的 IAM 動作。

接下來，使用下載的 JSON 檔案建立 IAM Policy。

aws iam create-policy \
--policy-name AmazonEKS_EFS_CSI_Driver_Policy \
--policy-document file://iam-policy-example.json

內容解密：

此命令建立了一個名為 AmazonEKS_EFS_CSI_Driver_Policy 的 IAM Policy，並將下載的 JSON 檔案作為 Policy 檔案。建立成功後，會輸出 Policy 的 ARN 和 ID。

步驟 2：建立 IAM Service Account

接下來，需要建立一個 IAM Service Account，以允許 EFS CSI Driver 使用剛剛建立的 IAM Policy。

eksctl create iamserviceaccount \
--cluster myeks01 \
--namespace kube-system \
--name efs-csi-controller-sa \
--attach-policy-arn arn:aws:iam::000381057009:policy/AmazonEKS_EFS_CSI_Driver_Policy \
--approve \
--region us-east-2

內容解密：

此命令建立了一個名為 efs-csi-controller-sa 的 IAM Service Account，並將其與剛剛建立的 IAM Policy 進行關聯。eksctl 工具會自動處理 IAM Role 和 Service Account 的建立。

在執行上述命令之前，需要先將 EKS Cluster 與 AWS OIDC Provider 進行關聯。

eksctl utils associate-iam-oidc-provider --region=us-east-2 --cluster=myeks01 --approve

內容解密：

此命令建立了一個 IAM OIDC Provider，並將其與 EKS Cluster 進行關聯。這是建立 IAM Service Account 的必要步驟。

驗證與測試

建立完成後，可以透過檢查 IAM Service Account 是否成功建立來驗證組態是否正確。

kubectl get sa efs-csi-controller-sa -n kube-system

內容解密：

此命令檢查 kube-system 名稱空間中是否存在 efs-csi-controller-sa Service Account。

程式碼與組態範例

以下是本文中使用的程式碼和組態範例的總結：

@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

圖表翻譯： 此圖表展示了佈署 EFS CSI Driver 的主要步驟，包括建立 IAM Policy、建立 IAM Service Account 和驗證組態。

隨著容器化和 Kubernetes 的普及，持久化儲存的需求將越來越大。未來，我們將繼續探索更多關於 EKS 和 EFS 的最佳實踐，包括效能最佳化、安全性和可擴充套件性等方面。

關鍵字：EKS、EFS、CSI Driver、持久化儲存、Kubernetes。

參考資料

透過本文，我們希望能夠幫助讀者更好地理解在 EKS 中使用 EFS 進行持久化儲存的方法和最佳實踐。未來，我們將繼續分享更多關於雲端運算和 Kubernetes 的技術文章和經驗分享。敬請期待！

Kubernetes 資料持久化實務操作

驗證佈署擴充套件是否成功

內容解密：

內容解密：

測試 Web 伺服器連線

內容解密：

內容解密：

釋放 PVC 與 PV

內容解密：

內容解密：

內容解密：

相關圖表

在AWS EKS中實作持久化儲存

佈署Nginx容器並存取

內容解密：

建立服務並存取Nginx

內容解密：

內容解密：

更新安全組規則

內容解密：

持久化儲存的需求

Persistent Volumes在AWS EKS中的實作

程式碼範例：建立Persistent Volume Claim

內容解密：

EKS持久化儲存架構

在 Amazon EKS 中實作持久化儲存：EFS CSI Driver 的佈署與組態

為什麼選擇 Amazon EFS？

佈署 Amazon EFS CSI Driver

步驟 1：建立 IAM Policy

內容解密：

內容解密：

步驟 2：建立 IAM Service Account

內容解密：

內容解密：

驗證與測試

內容解密：

程式碼與組態範例

關鍵字：EKS、EFS、CSI Driver、持久化儲存、Kubernetes。

參考資料