kubernetes 使用 PV 和 PVC 管理數據存儲

文章鏈接
容器磁盤上的文件的生命周期是短暫的，這就使得在容器中運行重要應用時會出現一些問題。首先，當容器崩潰時，kubelet 會重啟它，但是容器中的文件將丟失——容器以干凈的狀態（鏡像最初的狀態）重新啟動。其次，在 Pod 中同時運行多個容器時，這些容器之間通常需要共享文件。所以我會用 NFS 為例，創建 PV 、PVC.

PV 屬於集群中的資源。PVC 是對這些資源的請求，也作為對資源的請求的檢查。 PV 和 PVC 之間的相互作用遵循這樣的生命周期.

PersistentVolume（PV）

PersistentVolume（PV）是由管理員設置的存儲，它是群集的一部分。就像節點是集群中的資源一樣，PV 也是集群中的資源。 PV 是 Volume 之類的卷插件，但具有獨立於使用 PV 的 Pod 的生命周期。此 API 對象包含存儲實現的細節，即 NFS、iSCSI 或特定於雲供應商的存儲系統。

PV 有兩種方式來配置：靜態和動態。

• 靜態
  集群管理員創建一些 PV。它們帶有可供群集用戶使用的實際存儲的細節。它們存在於 Kubernetes API 中，可用於消費。
• 動態
  根據 StorageClasses，當管理員創建的靜態 PV 都不匹配用戶的 PersistentVolumeClaim 時，集群可能會嘗試動態地為 PVC 創建卷。

安裝並配置 nfs rpcbind

yum install -y nfs-utils rpcbind
mkdir -p /home/bsh/nfs
vim /etc/exports
/home/bsh/nfs *(rw,sync,no_root_squash)

配置詳解：
---|---
ro |只讀訪問
rw |讀寫訪問
sync |所有數據在請求時寫入共享
async |NFS在寫入數據前可以相應請求
secure |NFS通過1024以下的安全TCP/IP端口發送
insecure |NFS通過1024以上的端口發送
wdelay |如果多個用戶要寫入NFS目錄，則歸組寫入（默認）
no_wdelay |如果多個用戶要寫入NFS目錄，則立即寫入，當使用async時，無需此設置。
Hide |在NFS共享目錄中不共享其子目錄
no_hide |共享NFS目錄的子目錄
subtree_check |如果共享/usr/bin之類的子目錄時，強制NFS檢查父目錄的權限（默認）
no_subtree_check |和上面相對，不檢查父目錄權限
all_squash |共享文件的UID和GID映射匿名用戶anonymous，適合公用目錄。
no_all_squash |保留共享文件的UID和GID（默認）
root_squash |root用戶的所有請求映射成如anonymous用戶一樣的權限（默認）
no_root_squas |root用戶具有根目錄的完全管理訪問權限
anonuid=xxx |指定NFS服務器/etc/passwd文件中匿名用戶的UID

啟動 nfs rpcbind

systemctl enable nfs rpcbind
systemctl start nfs rpcbind

創建PV

創建 yaml 文件
vim tomcat-log-pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: tomcat
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  nfs:
    path: /home/bsh/nfs/tomcat-log
    server: 10.0.10.51

創建 pv

kubectl  apply  -f  tomcat-log-pv.yaml

查看pv

[root@master ]# kubectl  get  pv
NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
tomcat   1Gi        RWX            Retain           Available                                   26s

pv 屬性詳解

PV的存儲容量

PV 將具有特定的存儲容量。這是使用PV的capacity屬性設置的。

目前，存儲大小是可以設置或請求的唯一資源。未來的屬性可能包括 IOPS、吞吐量等。

PV的訪問模式

PersistentVolume可以以資源提供者支持的任何方式掛載到主機上。如下表所示，供應商具有不同的功能，每個 PV 的訪問模式都將被設置為該卷支持的特定模式。例如，NFS 可以支持多個讀/寫客戶端，但特定的 NFS PV 可能以只讀方式導出到服務器上。每個 PV 都有一套自己的用來描述特定功能的訪問模式。
存儲模式包括：

• ReadWriteOnce——該卷可以被單個節點以讀/寫模式掛載
• ReadOnlyMany——該卷可以被多個節點以只讀模式掛載
• ReadWriteMany——該卷可以被多個節點以讀/寫模式掛載
  在命令行中，訪問模式縮寫為：
• RWO - ReadWriteOnce
• ROX - ReadOnlyMany
• RWX - ReadWriteMany
  一個卷一次只能使用一種訪問模式掛載，即使它支持很多訪問模式。例如，GCEPersistentDisk 可以由單個節點作為 ReadWriteOnce 模式掛載，或由多個節點以 ReadOnlyMany 模式掛載，但不能同時掛載
  PV的回收策略
  persistentVolumeReclaimPolicy屬性用來指定PV的回收策略

當前的回收策略包括：

• Retain（保留）——手動回收
• Recycle（回收）——基本擦除（rm -rf /thevolume/*）
• Delete（刪除）——關聯的存儲資產（例如 AWS EBS、GCE PD、Azure Disk 和 OpenStack Cinder 卷）將被刪除
  當前，只有 NFS 和 HostPath 支持回收策略。AWS EBS、GCE PD、Azure Disk 和 Cinder 卷支持刪除策略。

storageClassName PV 可以具有一個類，通過將 storageClassName 屬性設置為 StorageClass 的名稱來指定該類。一個特定類別的 PV 只能綁定到請求該類別的 PVC。沒有 storageClassName 的 PV 就沒有類，它只能綁定到不需要特定類的 PVC。

PersistentVolumeClaim（PVC）

PersistentVolumeClaim（PVC）是用戶存儲的請求。它與 Pod 相似。Pod 消耗節點資源，PVC 消耗 PV 資源。Pod 可以請求特定級別的資源（CPU 和內存）。聲明可以請求特定的大小和訪問模式（例如，可以以讀/寫一次或 只讀多次模式掛載）。

創建PVC

創建 yaml 文件
vim tomcat-log-pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: tomcat
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

創建 pv

kubectl  apply  -f  tomcat-log-pvc.yaml

查看pv

[root@master ]# kubectl  get pvc
NAME     STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
tomcat   Bound    tomcat   1Gi        RWX                           18s

使用PVC

vim tomcat.yaml

apiVersion: apps/v1 
kind: Deployment   
metadata:             
  name: tomcat-deployment     
  labels:       
    app: tomcat  
spec:          
  replicas: 3
  selector:      
    matchLabels: 
      app: tomcat
  minReadySeconds: 1
  progressDeadlineSeconds: 60
  revisionHistoryLimit: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:        
    metadata:  
      labels:  
        app: tomcat
    spec:         
      containers:     
      - name: tomcat     
        image: wenlongxue/tomcat:tomcat-demo-62-8fe6052    
        imagePullPolicy: Always          
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "2Gi"
            cpu: "80m"
          limits: 
            memory: "2Gi" 
            cpu: "80m"
        readinessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 180
          periodSeconds: 5
          timeoutSeconds: 3
          successThreshold: 1
          failureThreshold: 30
        volumeMounts:
        - mountPath: "/usr/local/tomcat/logs"
          name: tomcat

      volumes:
      - name: tomcat
        persistentVolumeClaim:
          claimName: tomcat

部署查看 pod

# 部署
kubectl  apply  -f tomcat.yaml 
# 查看
kubectl  get  pods |grep  tomcat
tomcat-deployment-7588b5c8fd-4grh2       1/1     Running   0          31s
tomcat-deployment-7588b5c8fd-l89t7       1/1     Running   0          31s
tomcat-deployment-7588b5c8fd-mb8bh       1/1     Running   0          31s

最后

PVC 不關心后端存儲提供者是 NFS 還是 GFS，具體使用哪種類型的存儲由 PV 來定義，PVC 只和隱藏了存儲實現細節的 PV 對接。
本方式為靜態分配，如果有一千個 Pod，每個 Pod 有一個 PVC，那么管理員需要人工開設一千個 PV，隨着集群規模的擴大，將導致無法有效管理。
K8S 提供了一種可以動態分配的工作機制，可以自動創建 PV，該機制依賴一個叫做 StorageClass 的 API 對象。
文章鏈接