Kubernetes（k8s）中文文件名詞解釋：PV/PVC/StorageClass_Kubernetes中文社群

介紹

PersistentVolume（PV）是叢集中已由管理員配置的一段網路儲存。叢集中的資源就像一個節點是一個叢集資源。 PV是諸如卷之類的卷外掛，但是具有獨立於使用PV的任何單個pod的生命週期。該API物件捕獲儲存的實現細節，即NFS，iSCSI或雲提供商特定的儲存系統。
PersistentVolumeClaim（PVC）是使用者儲存的請求。它類似於pod。 Pod消耗節點資源，PVC消耗光伏資源。莢可以請求特定級別的資源（CPU和記憶體）。權利要求可以請求特定的大小和訪問模式（例如，可以一旦讀/寫或只讀許多次安裝）。
雖然PersistentVolumeClaims允許使用者使用抽象儲存資源，但是常見的是，使用者需要具有不同屬性（如效能）的PersistentVolumes，用於不同的問題。群集管理員需要能夠提供多種不同於PersistentVolumes的PersistentVolumes，而不僅僅是大小和訪問模式，而不會使使用者瞭解這些卷的實現細節。對於這些需求，存在StorageClass資源。

StorageClass為管理員提供了一種描述他們提供的儲存的“類”的方法。不同的類可能對映到服務質量級別，或備份策略，或者由群集管理員確定的任意策略。 Kubernetes本身對於什麼類別代表是不言而喻的。這個概念有時在其他儲存系統中稱為“配置檔案”

例子
https://kubernetes.io/docs/user-guide/persistent-volumes/walkthrough/

Lifecycle of a volume and claim

PV是叢集中的資源。 PVC是對這些資源的請求，也是對資源的索賠檢查。 PV和PVC之間的相互作用遵循這個生命週期:

Provisioning ——-> Binding ——–>Using——>Releasing——>Recycling

Provisioning

這裡有兩種PV的提供方式:靜態或者動態

Static
叢集管理員建立多個PV。 它們攜帶可供叢集使用者使用的真實儲存的詳細資訊。 它們存在於Kubernetes API中，可用於消費。
Dynamic
當管理員建立的靜態PV都不匹配使用者的PersistentVolumeClaim時，叢集可能會嘗試為PVC動態配置卷。 此配置基於StorageClasses：PVC必須請求一個類，並且管理員必須已建立並配置該類才能進行動態配置。 要求該類的宣告有效地為自己禁用動態配置

Binding

在動態配置的情況下，使用者建立或已經建立了具有特定數量的儲存請求和特定訪問模式的PersistentVolumeClaim。主機中的控制迴路監視新的PVC，找到匹配的PV（如果可能），並將它們繫結在一起。如果為新的PVC動態配置PV，則迴圈將始終將該PV繫結到PVC。否則，使用者總是至少得到他們要求的內容，但是卷可能超出了要求。一旦繫結，PersistentVolumeClaim繫結是排他的，不管用於繫結它們的模式。

如果匹配的卷不存在，PVC將保持無限期。隨著匹配卷變得可用，PVC將被繫結。例如，提供許多50Gi PV的叢集將不匹配要求100Gi的PVC。當叢集中新增100Gi PV時，可以繫結PVC。

Using

Pod使用PVC作為卷。叢集檢查宣告以找到繫結的卷並掛載該卷的卷。對於支援多種訪問模式的卷，使用者在將其宣告用作pod中的卷時指定所需的模式。

一旦使用者有宣告並且該宣告被繫結，繫結的PV屬於使用者，只要他們需要它。使用者通過在其Pod的卷塊中包含persistentVolumeClaim來安排Pods並訪問其宣告的PV。

Releasing

當用戶完成卷時，他們可以從允許資源回收的API中刪除PVC物件。當宣告被刪除時，卷被認為是“釋放的”，但是它還不能用於另一個宣告。以前的索賠人的資料仍然保留在必須根據政策處理的捲上.

Reclaiming
PersistentVolume的回收策略告訴叢集在釋放其聲明後，該卷應該如何處理。目前，卷可以是保留，回收或刪除。保留可以手動回收資源。對於那些支援它的卷外掛，刪除將從Kubernetes中刪除PersistentVolume物件，以及刪除外部基礎架構（如AWS EBS，GCE PD，Azure Disk或Cinder卷）中關聯的儲存資產。動態配置的卷始終被刪除

Recycling

如果受適當的卷外掛支援，回收將對卷執行基本的擦除（rm -rf / thevolume / *），並使其再次可用於新的宣告。
但是，管理員可以使用Kubernetes控制器管理器命令列引數來配置自定義的回收站pod模板，如這裡所述。定製回收站模板必須包含卷規範，如下例所示：

apiVersion: v1
kind: Pod
metadata:
  name: pv-recycler-
  namespace: default
spec:
  restartPolicy: Never
  volumes:
  - name: vol
    hostPath:
      path: /any/path/it/will/be/replaced
  containers:
  - name: pv-recycler
    image: "gcr.io/google_containers/busybox"
    command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/*  && test -z \"$(ls -A /scrub)\" || exit 1"]
    volumeMounts:
    - name: vol
      mountPath: /scrub

Types of Persistent Volumes

PV當前支援的型別

GCEPersistentDisk 
AWSElasticBlockStore 
AzureFile 
AzureDisk 
FC (Fibre Channel) 
FlexVolume 
Flocker 
NFS 
iSCSI 
RBD (Ceph Block Device) 
CephFS 
Cinder (OpenStack block storage) 
Glusterfs 
VsphereVolume 
Quobyte Volumes 
HostPath (single node testing only – local storage is not supported in any way and WILL NOT WORK in a multi-node cluster) 
VMware Photon 
Portworx Volumes 
ScaleIO Volumes

Persistent Volumes

每個PV包含了Spec和Staus, 在PV的定義中指定該內容

  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: pv0003
  spec:
    capacity:
      storage: 5Gi
    accessModes:
      - ReadWriteOnce
    persistentVolumeReclaimPolicy: Recycle
    storageClassName: slow
    nfs:
      path: /tmp
      server: 172.17.0.2

Capacity

通常，PV將具有特定的儲存容量。這是使用PV的容量屬性設定的。看到庫伯納斯資源模型，以瞭解容量預期的單位。

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

Access Modes

PersistentVolume可以以資源提供者支援的任何方式安裝在主機上。如下表所示，提供商將具有不同的功能，每個PV的訪問模式都被設定為該特定卷支援的特定模式。例如，NFS可以支援多個讀/寫客戶端，但是特定的NFS PV可能會以只讀方式在伺服器上匯出。每個PV都有自己的一組訪問模式來描述具體的PV功能。
訪問模式:
ReadWriteOnce – the volume can be mounted as read-write by a single node (單node的讀寫)
ReadOnlyMany – the volume can be mounted read-only by many nodes (多node的只讀)
ReadWriteMany – the volume can be mounted as read-write by many nodes (多node的讀寫)
Notice:單個PV掛載的時候只支援一種訪問模式
PV提供外掛支援的access mode參考kubernetes官方文件

Class

PV可以有一個類，通過將storageClassName屬性設定為StorageClass的名稱來指定。特定類的PV只能繫結到請求該類的PVC。沒有storageClassName的PV沒有類，只能繫結到不需要特定類的PVC。
在過去，使用了註釋volume.beta.kubernetes.io/storage-class而不是storageClassName屬性。該註釋仍然可以工作，但將來Kubernetes版本將不再適用。

Reclaim Policy

目前的回收政策是：

Retain – manual reclamation 
Recycle – basic scrub (“rm -rf /thevolume/*”) 
Delete – associated storage asset such as AWS EBS, GCE PD, Azure Disk, or OpenStack Cinder volume is deleted

目前，只有NFS和HostPath支援回收。 AWS EBS，GCE PD，Azure Disk和Cinder卷支援刪除

Phase

卷將處於以下階段之一：

Available – a free resource that is not yet bound to a claim 
Bound – the volume is bound to a claim 
Released – the claim has been deleted, but the resource is not yet reclaimed by the cluster 
Failed – the volume has failed its automatic reclamation

Mount Options

Kubernetes管理員可以指定在一個節點上掛載一個持久卷時的其他安裝選項。
您可以通過使用持久捲上的註釋volume.beta.kubernetes.io/mount-options來指定安裝選項。

apiVersion: "v1"
kind: "PersistentVolume"
metadata:
  name: gce-disk-1
  annotations:
    volume.beta.kubernetes.io/mount-options: "discard"
spec:
  capacity:
    storage: "10Gi"
  accessModes:
    - "ReadWriteOnce"
  gcePersistentDisk:
    fsType: "ext4"
    pdName: "gce-disk-1

安裝選項是一個字串，在將卷安裝到磁碟時將被累積地連線和使用。

請注意，並非所有Persistent卷型別都支援安裝選項。在Kubernetes 1.6版中，以下卷型別支援安裝選項。

GCEPersistentDisk 
AWSElasticBlockStore 
AzureFile 
AzureDisk 
NFS 
iSCSI 
RBD (Ceph Block Device) 
CephFS 
Cinder (OpenStack block storage) 
Glusterfs 
VsphereVolume 
Quobyte Volumes 
VMware Photon

PersistentVolumeClaims

每個PVC包含spec和status

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi
  storageClassName: slow
  selector:
    matchLabels:
      release: "stable"
    matchExpressions:
      - {key: environment, operator: In, values: [dev]}

Access Modes

當請求具有特定訪問模式的儲存時，宣告使用與卷相同的約定

Resources

宣告（如pod）可以請求特定數量的資源。在這種情況下，請求用於儲存。相同的資源模型適用於卷和宣告

Selector

宣告可以指定標籤選擇器以進一步過濾該卷集。只有標籤與選擇器匹配的卷才能繫結到宣告。選擇器可以由兩個欄位組成：

matchLabels - 卷必須具有帶此值的標籤
matchExpressions - 通過指定關鍵字和值的關鍵字，值列表和運算子所做的要求列表。 有效運算子包括In，NotIn，Exists和DoesNotExist。

所有來自matchLabels和matchExpressions的要求都與AND一起使用，所有這些要求都必須滿足才能匹配。

Class

宣告可以通過使用屬性storageClassName指定StorageClass的名稱來請求特定的類。只有所請求的類的PV，與PVC相同的storageClassName的PV可以繫結到PVC。

PVC不一定要求一個班級。它的storageClassName設定為等於“”的PVC總是被解釋為請求沒有類的PV，因此它只能繫結到沒有類的PV（沒有註釋或一個等於“”）。沒有storageClassName的PVC不完全相同，並且根據是否啟用了DefaultStorageClass入門外掛，叢集的處理方式不同。

如果接納外掛已開啟，則管理員可以指定預設的StorageClass。沒有storageClassName的所有PVC只能繫結到該預設的PV。通過將StorageClass物件中的annotation storageclass.kubernetes.io/is-default-class設定為“true”來指定預設的StorageClass。如果管理員沒有指定預設值，則叢集會對PVC建立做出響應，就像入門外掛被關閉一樣。如果指定了多個預設值，則驗收外掛禁止建立所有PVC。
如果入門外掛已關閉，則不存在預設StorageClass的概念。沒有storageClassName的所有PVC只能繫結到沒有類的PV。在這種情況下，沒有storageClassName的PVC的處理方式與將其storageClassName設定為“”的PVC相同。

根據安裝方法，安裝過程中可以通過addon manager在Kubernetes群集中部署預設的StorageClass。

當PVC指定一個選擇器，除了請求一個StorageClass之外，這些要求被AND組合在一起：只有所請求的類和所請求的標籤的PV可能被繫結到PVC。請注意，當前，具有非空選擇器的PVC不能為其動態配置PV。

在過去，使用了註釋volume.beta.kubernetes.io/storage-class，而不是storageClassName屬性。該註釋仍然可以工作，但在未來的Kubernetes版本中它將不被支援。

宣告PVC作為Volumes

Pods通過將宣告用作捲來訪問儲存。宣告必須存在於與使用宣告的pod相同的名稱空間中。群集在pod的名稱空間中查詢宣告，並使用它來獲取支援宣告的PersistentVolume。然後將體積安裝到主機並進入Pod。

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: dockerfile/nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim

PersistentVolumes繫結是獨佔的，並且由於PersistentVolumeClaims是名稱空間物件，所以只能在一個名稱空間內安裝“許多”模式（ROX，RWX）—PVC支援被多個pod掛載

StorageClasses

每個StorageClass包含欄位provisioninger和引數，當屬於類的PersistentVolume需要動態配置時使用。

StorageClass物件的名稱很重要，使用者可以如何請求特定的類。管理員在首次建立StorageClass物件時設定類的名稱和其他引數，並且在建立物件後無法更新物件。

管理員可以僅為不要求任何特定類繫結的PVC指定預設的StorageClass：有關詳細資訊，請參閱PersistentVolumeClaim部分。

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: standard
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2

Provisioner

儲存類有一個供應商，它確定用於配置PV的卷外掛。必須指定此欄位。

您不限於指定此處列出的“內部”供應商（其名稱字首為“kubernetes.io”並與Kubernetes一起運送）。您還可以執行和指定外部提供程式，它們是遵循Kubernetes定義的規範的獨立程式。外部提供者的作者對程式碼的生命週期，供應商的運輸狀況，執行狀況以及使用的卷外掛（包括Flex）等都有充分的自主權。儲存庫kubernetes-incubator /外部儲存庫包含一個庫用於編寫實施大部分規範的外部提供者以及各種社群維護的外部提供者。

Parameters

儲存類具有描述屬於儲存類的卷的引數。取決於供應商，可以接受不同的引數。例如，引數型別的值io1和引數iopsPerGB特定於EBS。當省略引數時，使用一些預設值。

AWS/GCE/Glusterfs/

OpenStack Cinder

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: gold
provisioner: kubernetes.io/cinder
parameters:
  type: fast
  availability: nova

type: VolumeType created in Cinder. Default is empty. 
availability: Availability Zone. If not specified, volumes are generally round-robin-ed across all active zones where Kubernetes cluster has a node.

其它型別的storageClass配置參考

https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes

配置

如果您正在編寫在各種群集上執行並需要持久儲存的配置模板或示例，我們建議您使用以下模式：

在您的配置資料夾（包括部署，ConfigMaps等）中包含PersistentVolumeClaim物件。
在配置中不要包含PersistentVolume物件，因為例項化配置的使用者可能沒有建立PersistentVolumes的許可權。
給使用者提供例項化模板時提供儲存類名稱的選項。
１．　如果使用者提供儲存類名稱，並且叢集是1.4或更高版本，請將該值放入PVC的volume.beta.kubernetes.io/storage-class註釋中。如果叢集的管理員啟用了StorageClasses，這將導致PVC與正確的儲存類匹配。
２．　如果使用者不提供儲存類名稱或者叢集是版本1.3，那麼在PVC上放置一個volume.alpha.kubernetes.io/storage-class：default註釋。
這將導致在某些群集上為使用者自動配置PV，並具有合理的預設特性。
儘管在名稱中使用了alpha，但這個註釋背後的程式碼具有beta級別的支援。
３．　不要使用volume.beta.kubernetes.io/storage-class：包含空字串的任何值，因為它將阻止DefaultStorageClass接納控制器執行（如果啟用）。

在您的工具中，請注意在一段時間後未繫結的PVC，並將其表示給使用者，因為這可能表明叢集沒有動態儲存支援（在這種情況下，使用者應建立匹配的PV）或叢集沒有儲存系統（在這種情況下，使用者無法部署需要PVC的配置）。

在將來，我們預計大多數叢集都將啟用DefaultStorageClass，並提供某種形式的儲存。但是，可能沒有任何儲存類名可用於所有叢集，因此預設情況下繼續不設定。在某種程度上，alpha註釋將不再有意義，但PVC上的未設定的storageClass欄位將具有所需的效果。

譯者：阿僕來耶 http://blog.csdn.net/jettery/article/details/72722324

Kubernetes（k8s）中文文件 名詞解釋：PV/PVC/StorageClass_Kubernetes中文社群

介紹

Lifecycle of a volume and claim

Provisioning

Binding

Using

Releasing

Recycling

Types of Persistent Volumes

Persistent Volumes

Capacity

Access Modes

Class

Reclaim Policy

Phase

Mount Options

PersistentVolumeClaims

Access Modes

Resources

Selector

Class

宣告PVC作為Volumes

StorageClasses

Provisioner

Parameters

配置

相關推薦

Kubernetes（k8s）中文文件名詞解釋：PV/PVC/StorageClass_Kubernetes中文社群