• 一、PVC和PV
  • 1.1 PV概念
  • 1.2 PVC概念
  • 1.3 PV與PVC之間的關係
  • 1.4 兩種PV的提供方式
• 二、基於nfs建立靜態PV資源和PVC資源
  • 2.1 配置nfs儲存（192.168.80.14）
  • 2.2 k8s的master節點定義PV
  • 2.3 定義PVC
  • 2.4 測試多路讀寫
• 三、基於動態storageclass建立pv與pvc
  • 3.1 storageclass的用處
  • 3.2 storageclass的yaml格式

一、PVC和PV

1.1 PV概念

1.PersistentVolume(PV)是叢集中已由管理員配置的一段網路儲存。叢集中的資源就像一個節點是一個叢集資源，可以從遠端的NFS或分散式物件儲存系統中建立得來（pv儲存空間大小、訪問方式）
2.Pv是諸如卷之類的卷外掛，但是隻有獨立於使用Pv的任何單個pod的生命週期。
3.該API物件捕獲儲存的實現細節，即NFS，isCSI或雲提供商特定的儲存系統
4.PV就是從儲存裝置中的空間創建出一個儲存資源

1.2 PVC概念

1. PersistentVolumeClaim (Pvc)是使用者儲存的請求。Pvc的使用邏輯:在podt中定義一個儲存卷（該儲存卷型別為pvc)，定義的時候直按指定大小，pvc必須與對應的pv建立關係，pvc會根據定義去pv申請，而pv是由儲存空間創建出來的。pr和pvc是kubernetes抽象出來的一種儲存資源
2. 雖然PersistentVolumeClaims允許使用者使用抽象儲存資源，但是常見的需求是，使用者需要根據不同的需求去建立v，用於不同的場景。而此時需要叢集管理員提供不同需求的Pv，而不僅僅是Pv的大小和訪問模式，但又不需要使用者瞭解這些卷的實現細節
3. 對於這樣的需求,此時可以採用storageclass資源

1.3 PV與PVC之間的關係

PV是叢集中的資源。Pvc是對這些資源的請求，也是對資源的索引檢查。PV和Pvc之間的相互作用遵循這個生命週期：Provisioning(配置)---> Binding(繫結)--->Using(使用)--->Releasing(釋放)--->Recycling(回收)

1.4 兩種PV的提供方式

1. 這裡有兩種PV的提供方式:靜態或者動態
2. 靜態-->直接固定儲存空間:
   叢集管理員建立一些PV。它們攜帶可供叢集使用者使用的真實儲存的詳細資訊。它們存在於Ktbernetes API中，可用於消費
3. 動態-->通過儲存類進行動態建立儲存空間:
   當管理員建立的靜態PV都不匹配使用者的 PvC時，叢集可能會嘗試動態地為 Pvc配置卷。此配置基於StorageClasses: PvC必須請求儲存類，並且管理員必須已建立並配置該類才能進行動態配置。要求該類的宣告有效地為自己禁用動態配置

二、基於nfs建立靜態PV資源和PVC資源

2.1 配置nfs儲存（192.168.80.14）

1. mkdir -p /data/v{1..5}
chmod 777 -R /data/*

2. vim /etc/exports
/data/v1 192.168.10.0/24(rw,no_root_squash,sync)
/data/v2 192.168.10.0/24(rw,no_root_squash,sync)
/data/v3 192.168.10.0/24(rw,no_root_squash,sync)
/data/v4 192.168.10.0/24(rw,no_root_squash,sync)
/data/v5 192.168.10.0/24(rw,no_root_squash,sync)

3. systemctl start rpcbind
  systemctl start nfs

4. showmount -e

5. hostnamectl set-hostname nfs01
su

6. echo '11111' > /data/v1/index.html
echo '22222' > /data/v2/index.html
echo '33333' > /data/v3/index.html
echo '44444' > /data/v4/index.html
echo '55555' > /data/v5/index.html

2.2 k8s的master節點定義PV

//這裡定義5個Pv，並且定義掛載的路徑以及訪問模式，還有pv劃分的大小
vim pv-demo.yaml
==========================================================
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv001
  labels:
    name: pv001
spec:
  nfs:
    path: /data/v1
    server: nfs01
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv002
  labels:
    name: pv002
spec:
  nfs:
    path: /data/v2
    server: nfs01
  accessModes: ["ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv003
  labels:
    name: pv003
spec:
  nfs:
    path: /data/v3
    server: nfs01
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv004
  labels:
    name: pv004
spec:
  nfs:
    path: /data/v4
    server: nfs01
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 4Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv005
  labels:
    name: pv005
spec:
  nfs:
    path: /data/v5
    server: nfs01
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 5Gi
==========================================================
kubectl apply -f pv-demo.yaml

kubectl get pv

2.3 定義PVC

//這裡定義了pvc的訪問模式為多路讀寫，該訪問模式必須在前面pv定義的訪問模式之中。定義Pvc申請的大小為2Gi，此時pvc會自動去匹配多路讀寫且大小為2Gi的Pv，匹配成功獲取PVC的狀態即為Bound
vim pvc-demo.yaml
==========================================================
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  accessModes: ["ReadWriteMany"]
  resources:
    requests:
      storage: 2Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: pv-pvc
spec:
  containers:
  - name: myapp
    image: nginx
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html
  volumes:
  - name: html
    persistentVolumeClaim:
      claimName: mypvc
==========================================================
kubectl apply -f pvc-demo.yaml

kubectl get pv

2.4 測試多路讀寫

1. 我們通過相同的儲存卷，只修改pod的名稱
cp pvc-demo.yaml 1.yaml
cp pvc-demo.yaml 2.yaml
2. 修改pod的名稱後，apply執行建立
kubectl apply -f 1.yaml
kubectl apply -f 2.yaml
3. 檢視ip
kubectl get pod -o wide 
4. curl進行測試，檢視是否共享儲存卷，多路讀寫

三、基於動態storageclass建立pv與pvc

3.1 storageclass的用處

在pv和pvc使用過程中存在的問題，在pvc申請儲存空間時，未必就有現成的pv符合pvc申請的需求，上面nfs在做pvc可以成功的因素是因為我們做了指定的需求處理。當PvC申請的儲存空間不一定有滿足PvC要求的Pv時,Kubernetes為管理員提供了描述儲存"class(類)"的方法(StorageClass）。舉個例子，在儲存系統中劃分一個1TB的儲存空間提供給Kubernetes使用，當用戶需要一個10G的PvC時，會立即通過restful傳送請求，從而讓儲存空間建立一個10G的image，之後在我們的叢集中定義成10c的Pv供給給當前的Pvc作為掛載使用。在此之前我們的儲存系統必須支援restful介面，比如ceph分散式儲存，而glusterfs則需要藉助第三方介面完成這樣的請求

3.2 storageclass的yaml格式

kubectl explain storageclass #storageclass也是k8s上的資源
KIND: Storageclass
VERSION: storage.k8s.io/vl
FIELDS:
  allowVolumeExpansion <boolean>
  allowedTopologies<[]Object>apiversion<string>
  kind <string>
  metadata <object>
  mountOptions <[]string>掛載選項
  parameters <map[string]string#引數，取決於分配器，可以接受不同的引數。例如，引數type的值 io1和引數iopsPerGB特定於EBS PV。當引數被省略時,會使用預設值。
  provisioner <string-requred-#儲存分配器，用來決定使用哪個卷外掛分配 PV。該欄位必須指定。
  reclaimPolicy <string>#回收策略，可以是 Delete或者 Retain。如果 StorageClass 物件被建立時沒有指定 reclaimPolicy，它將預設為 Delete。
  volumeBindingMode<string>#卷的繫結模式

StorageClass 中包含 provisioner、parameters和 reclaimPolicy欄位，當 class需要動態分配 PersistentVolume時會使用到。由於storageclass需要一個獨立的儲存系統，此處就不再演示。從其他資料檢視定義storageclass的方式如下:
==========================================================
kind: storageClass
apiversion: storage.k8s.io/v1432
metadata :
  name : standard
provisioner: kubernetes.iol aws-ebs435 parameters:
  type: gp2
reclaimPolicy: Retain
mountoptions:
  - debug