這篇文章給大家分享的是有關(guān)Kubernetes存儲中Persistent Volumes有什么用的內(nèi)容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

創(chuàng)新互聯(lián)公司專業(yè)為企業(yè)提供橫山網(wǎng)站建設(shè)、橫山做網(wǎng)站、橫山網(wǎng)站設(shè)計、橫山網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、橫山企業(yè)網(wǎng)站模板建站服務(wù)，10年橫山做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。

簡介

管理存儲和管理計算有著明顯的不同。PersistentVolume子系統(tǒng)給用戶和管理員提供了一套API，從而抽象出存儲是如何提供和消耗的細節(jié)。在這里，我們介紹兩種新的API資源：PersistentVolume（簡稱PV）和PersistentVolumeClaim（簡稱PVC）。
　　PersistentVolume（持久卷，簡稱PV）是集群內(nèi)，由管理員提供的網(wǎng)絡(luò)存儲的一部分。就像集群中的節(jié)點一樣，PV也是集群中的一種資源。它也像Volume一樣，是一種volume插件，但是它的生命周期卻是和使用它的Pod相互獨立的。PV這個API對象，捕獲了諸如NFS、ISCSI、或其他云存儲系統(tǒng)的實現(xiàn)細節(jié)。
　　PersistentVolumeClaim（持久卷聲明，簡稱PVC）是用戶的一種存儲請求。它和Pod類似，Pod消耗Node資源，而PVC消耗PV資源。Pod能夠請求特定的資源（如CPU和內(nèi)存）。PVC能夠請求指定的大小和訪問的模式（可以被映射為一次讀寫或者多次只讀）。
　　PVC允許用戶消耗抽象的存儲資源，用戶也經(jīng)常需要各種屬性（如性能）的PV。集群管理員需要提供各種各樣、不同大小、不同訪問模式的PV，而不用向用戶暴露這些volume如何實現(xiàn)的細節(jié)。因為這種需求，就催生出一種StorageClass資源。
　　StorageClass提供了一種方式，使得管理員能夠描述他提供的存儲的等級。集群管理員可以將不同的等級映射到不同的服務(wù)等級、不同的后端策略。

volume和claim的生命周期

PV是集群中的資源，PVC是對這些資源的請求，同時也是這些資源的“提取證”。PV和PVC的交互遵循以下生命周期：

供給

有兩種PV提供的方式：靜態(tài)和動態(tài)。

靜態(tài)

集群管理員創(chuàng)建多個PV，它們攜帶著真實存儲的詳細信息，這些存儲對于集群用戶是可用的。它們存在于Kubernetes API中，并可用于存儲使用。

動態(tài)

當管理員創(chuàng)建的靜態(tài)PV都不匹配用戶的PVC時，集群可能會嘗試專門地供給volume給PVC。這種供給基于StorageClass：PVC必須請求這樣一個等級，而管理員必須已經(jīng)創(chuàng)建和配置過這樣一個等級，以備發(fā)生這種動態(tài)供給的情況。請求等級配置為“”的PVC，有效地禁用了它自身的動態(tài)供給功能。

綁定

用戶創(chuàng)建一個PVC（或者之前就已經(jīng)就為動態(tài)供給創(chuàng)建了），指定要求存儲的大小和訪問模式。master中有一個控制回路用于監(jiān)控新的PVC，查找匹配的PV（如果有），并把PVC和PV綁定在一起。如果一個PV曾經(jīng)動態(tài)供給到了一個新的PVC，那么這個回路會一直綁定這個PV和PVC。另外，用戶總是至少能得到它們所要求的存儲，但是volume可能超過它們的請求。一旦綁定了，PVC綁定就是專屬的，無論它們的綁定模式是什么。
　　如果沒找到匹配的PV，那么PVC會無限期得處于unbound未綁定狀態(tài)，一旦PV可用了，PVC就會又變成綁定狀態(tài)。比如，如果一個供給了很多50G的PV集群，不會匹配要求100G的PVC。直到100G的PV添加到該集群時，PVC才會被綁定。

使用

Pod使用PVC就像使用volume一樣。集群檢查PVC，查找綁定的PV，并映射PV給Pod。對于支持多種訪問模式的PV，用戶可以指定想用的模式。
　　一旦用戶擁有了一個PVC，并且PVC被綁定，那么只要用戶還需要，PV就一直屬于這個用戶。用戶調(diào)度Pod，通過在Pod的volume塊中包含PVC來訪問PV。

釋放

當用戶使用PV完畢后，他們可以通過API來刪除PVC對象。當PVC被刪除后，對應(yīng)的PV就被認為是已經(jīng)是“released”了，但還不能再給另外一個PVC使用。前一個PVC的屬于還存在于該PV中，必須根據(jù)策略來處理掉。

回收

PV的回收策略告訴集群，在PV被釋放之后集群應(yīng)該如何處理該PV。當前，PV可以被Retained（保留）、 Recycled（再利用）或者Deleted（刪除）。保留允許手動地再次聲明資源。對于支持刪除操作的PV卷，刪除操作會從Kubernetes中移除PV對象，還有對應(yīng)的外部存儲（如AWS EBS，GCE PD，Azure Disk，或者Cinder volume）。動態(tài)供給的卷總是會被刪除。

Recycled（再利用）

如果PV卷支持再利用，再利用會在PV卷上執(zhí)行一個基礎(chǔ)的擦除操作（rm -rf /thevolume/*），使得它可以再次被其他PVC聲明利用。
　　管理員可以通過Kubernetes controller manager的命令行工具（點擊查看），來配置自定義的再利用Pod模板。自定義的再利用Pod模板必須包含PV卷的詳細內(nèi)容，如下示例：

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

如上，在volumes部分的指定路徑，應(yīng)該被替換為PV卷需要再利用的路徑。

PV類型

PV類型使用插件的形式來實現(xiàn)。Kubernetes現(xiàn)在支持以下插件：
　　GCEPersistentDisk
　　AWSElasticBlockStore
　　AzureFile
　　Azuredisk
　　FC (Fibre Channel)
　　Flocker
　　NFS
　　iSCSI
　　RBD (Ceph Block Device)
　　CephFS
　　Cinder (OpenStack block storage)
　　Glusterfs
　　VsphereVolume
　　Quobyte Volumes
　　HostPath (僅測試過單節(jié)點的情況——不支持任何形式的本地存儲，多節(jié)點集群中不能工作)
　　VMware Photon
　　Portworx Volumes
　　ScaleIO Volumes

PV介紹

每個PV都包含一個spec和狀態(tài)，即說明書和PV卷的狀態(tài)。

  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的capacity屬性來設(shè)置。查看Kubernetes的Resource Model來了解capacity。
　　當前，存儲大小是唯一能被設(shè)置或請求的資源。未來可能包含IOPS，吞吐率等屬性。

訪問模式

PV可以使用存儲資源提供商支持的任何方法來映射到host中。如下的表格中所示，提供商有著不同的功能，每個PV的訪問模式被設(shè)置為卷支持的指定模式。比如，NFS可以支持多個讀/寫的客戶端，但可以在服務(wù)器上指定一個只讀的NFS PV。每個PV有它自己的訪問模式。
　　訪問模式包括：
　　　? ReadWriteOnce —— 該volume只能被單個節(jié)點以讀寫的方式映射
　　　? ReadOnlyMany —— 該volume可以被多個節(jié)點以只讀方式映射
　　　? ReadWriteMany —— 該volume只能被多個節(jié)點以讀寫的方式映射
　　在CLI中，訪問模式可以簡寫為：
　　　? RWO - ReadWriteOnce
　　　? ROX - ReadOnlyMany
　　　? RWX - ReadWriteMany
　　注意：即使volume支持很多種訪問模式，但它同時只能使用一種方式來映射。比如，GCEPersistentDisk可以被單個節(jié)點映射為ReadWriteOnce，或者多個節(jié)點映射為ReadOnlyMany，但不能同時使用這兩種方式來映射。

Volume Plugin	ReadWriteOnce	ReadOnlyMany	ReadWriteMany
AWSElasticBlockStore	?	-	-
AzureFile	?	?	?
AzureDisk	?	-	-
CephFS	?	?	?
Cinder	?	-	-
FC	?	?	-
FlexVolume	?	?	-
Flocker	?	-	-
GCEPersistentDisk	?	?	-
Glusterfs	?	?	?
HostPath	?	-	-
iSCSI	?	?	-
PhotonPersistentDisk	?	-	-
Quobyte	?	?	?
NFS	?	?	?
RBD	?	?	-
VsphereVolume	?	-	-
PortworxVolume	?	-	?
ScaleIO	?	?	-

Class

一個PV可以有一種class，通過設(shè)置storageClassName屬性來選擇指定的StorageClass。有指定class的PV只能綁定給請求該class的PVC。沒有設(shè)置storageClassName屬性的PV只能綁定給未請求class的PVC。
　　過去，使用volume.beta.kubernetes.io/storage-class注解，而不是storageClassName屬性。該注解現(xiàn)在依然可以工作，但在Kubernetes的未來版本中已經(jīng)被完全棄用了。

回收策略

當前的回收策略有：
　　　? Retain：手動回收
　　　? Recycle：需要擦出后才能再使用
　　　? Delete：相關(guān)聯(lián)的存儲資產(chǎn)，如AWS EBS，GCE PD，Azure Disk，or OpenStack Cinder卷都會被刪除
　　當前，只有NFS和HostPath支持回收利用，AWS EBS，GCE PD，Azure Disk，or OpenStack Cinder卷支持刪除操作。

階段

一個volume卷處于以下幾個階段之一：
　　　? Available：空閑的資源，未綁定給PVC
　　　? Bound：綁定給了某個PVC
　　　? Released：PVC已經(jīng)刪除了，但是PV還沒有被集群回收
　　　? Failed：PV在自動回收中失敗了
　　CLI可以顯示PV綁定的PVC名稱。

映射選項

當PV被映射到一個node上時，Kubernetes管理員可以指定額外的映射選項?？梢酝ㄟ^使用標注volume.beta.kubernetes.io/mount-options來指定PV的映射選項。
　　比如：

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

映射選項是當映射PV到磁盤時，一個可以被遞增地添加和使用的字符串。
　　注意，并非所有的PV類型都支持映射選項。在Kubernetes v1.6中，以下的PV類型支持映射選項。
　　　● GCEPersistentDisk
　　　● AWSElasticBlockStore
　　　● AzureFile
　　　● AzureDisk
　　　● NFS
　　　● iSCSI
　　　● RBD (Ceph Block Device)
　　　● CephFS
　　　● Cinder (OpenStack block storage)
　　　● Glusterfs
　　　● VsphereVolume
　　　● Quobyte Volumes
　　　● VMware Photon

PersistentVolumeClaims（PVC）

每個PVC都包含一個spec和status，即該PVC的規(guī)則說明和狀態(tài)。

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]}

訪問模式

當請求指定訪問模式的存儲時，PVC使用的規(guī)則和PV相同。

資源

PVC，就像pod一樣，可以請求指定數(shù)量的資源。請求資源時，PV和PVC都使用相同的資源樣式。

選擇器（Selector）

PVC可以指定標簽選擇器進行更深度的過濾PV，只有匹配了選擇器標簽的PV才能綁定給PVC。選擇器包含兩個字段：
　　　● matchLabels（匹配標簽） - PV必須有一個包含該值得標簽
　　　● matchExpressions（匹配表達式） - 一個請求列表，包含指定的鍵、值的列表、關(guān)聯(lián)鍵和值的操作符。合法的操作符包含In，NotIn，Exists，和DoesNotExist。
　　所有來自matchLabels和matchExpressions的請求，都是邏輯與關(guān)系的，它們必須全部滿足才能匹配上。

等級（Class）

PVC可以使用屬性storageClassName來指定StorageClass的名稱，從而請求指定的等級。只有滿足請求等級的PV，即那些包含了和PVC相同storageClassName的PV，才能與PVC綁定。
　　PVC并非必須要請求一個等級。設(shè)置storageClassName為“”的PVC總是被理解為請求一個無等級的PV，因此它只能被綁定到無等級的PV（未設(shè)置對應(yīng)的標注，或者設(shè)置為“”）。未設(shè)置storageClassName的PVC不太相同，DefaultStorageClass的權(quán)限插件打開與否，集群也會區(qū)別處理PVC。
　　　? 如果權(quán)限插件被打開，管理員可能會指定一個默認的StorageClass。所有沒有指定StorageClassName的PVC只能被綁定到默認等級的PV。要指定默認的StorageClass，需要在StorageClass對象中將標注storageclass.kubernetes.io/is-default-class設(shè)置為“true”。如果管理員沒有指定這個默認值，集群對PVC創(chuàng)建請求的回應(yīng)就和權(quán)限插件被關(guān)閉時一樣。如果指定了多個默認等級，那么權(quán)限插件禁止PVC創(chuàng)建請求。
　　　? 如果權(quán)限插件被關(guān)閉，那么久沒有默認StorageClass的概念。所有沒有設(shè)置StorageClassName的PVC都只能綁定到?jīng)]有等級的PV。因此，沒有設(shè)置StorageClassName的PVC就如同設(shè)置StorageClassName為“”的PVC一樣被對待。
　　 根據(jù)安裝方法的不同，默認的StorageClass可能會在安裝過程中被插件管理默認的部署在Kubernetes集群中。
　　 當PVC指定selector來請求StorageClass時，所有請求都是與操作的。只有滿足了指定等級和標簽的PV才可能綁定給PVC。當前，一個非空selector的PVC不能使用PV動態(tài)供給。
　　 過去，使用volume.beta.kubernetes.io/storage-class注解，而不是storageClassName屬性。該注解現(xiàn)在依然可以工作，但在Kubernetes的未來版本中已經(jīng)被完全棄用了。

使用PVC

Pod通過使用PVC（使用方式和volume一樣）來訪問存儲。PVC必須和使用它的pod在同一個命名空間，集群發(fā)現(xiàn)pod命名空間的PVC，根據(jù)PVC得到其后端的PV，然后PV被映射到host中，再提供給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

命名空間注意事項

PV綁定是獨有的，因為PVC是命名空間對象，映射PVC時只能在同一個命名空間中使用多種模式（ROX，RWX）。

StorageClass

每個StorageClass都包含字段provisioner和parameters，在所屬的PV需要動態(tài)供給時使用這些字段。
　　StorageClass對象的命名是非常重要的，它是用戶請求指定等級的方式。當創(chuàng)建StorageClass對象時，管理員設(shè)置等級的名稱和其他參數(shù)，但對象不會在創(chuàng)建后馬上就被更新。
　　管理員可以指定一個默認的StorageClass，用于綁定到那些未請求指定等級的PVC。詳細信息可參考PersistentVolumeClaim章節(jié)。

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

Provisioner

StorageClass都有存儲供應(yīng)商provisioner，用來決定哪種volume插件提供給PV使用。必須制定該字段。
　　你不限于指定此處列出的“內(nèi)部”供應(yīng)商（其名稱前綴為“kubernetes.io”并與Kubernetes一起分發(fā)）。你還可以運行和指定外部供應(yīng)商，它們是遵循Kubernetes定義的規(guī)范的獨立程序。外部提供者的作者對代碼的生命周期，供應(yīng)商的分發(fā)方式，運行狀況以及使用的卷插件（包括Flex）等都有充分的自主權(quán)。庫kubernetes-incubator/external-storage存放了一個庫， 用于編寫外部存儲供應(yīng)商，而這些提供者實現(xiàn)了大量的規(guī)范，并且是各種社區(qū)維護的。

參數(shù)

StorageClass有一些參數(shù)用于描述歸屬于該StorageClass的volume。不同的存儲提供商可能需要不同的參數(shù)。比如，參數(shù)type對應(yīng)的值io1，還有參數(shù)iopsPerGB，都是EBS專用的參數(shù)。當參數(shù)省略時，就會使用它的默認值。

AWS

...

GCE

...

Glusterfs

...

OpenStack Cinder

...

vSphere

...

Ceph RBD

  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    name: fast
  provisioner: kubernetes.io/rbd
  parameters:
    monitors: 10.16.153.105:6789
    adminId: kube
    adminSecretName: ceph-secret
    adminSecretNamespace: kube-system
    pool: kube
    userId: kube
    userSecretName: ceph-secret-user

● monitors：Ceph的monitor，逗號分隔。該參數(shù)是必須的。
　　● adminId：Ceph的客戶端ID，可在pool中創(chuàng)建鏡像。默認的是“admin”。
　　● adminSecretNamespace：adminSecret的命名空間，默認值是“default”。
　　● adminSecretName：adminId的Secret Name。改參數(shù)是必須的，提供的秘鑰必須有類型“kubernetes.io/rbd”。
　　● pool：Ceph的RBD pool，默認值是“rbd”。
　　● userId：Ceph的客戶ID，用于映射RBD鏡像的，默認值和adminId參數(shù)相同。
　　● userSecretName：Ceph Secret的名稱，userId用該參數(shù)來映射RBD鏡像。它必須和PVC在相同的命名空間。該參數(shù)也是必須的。提供的秘鑰必須有類型“kubernetes.io/rbd”。比如，按照下面的方式來創(chuàng)建：

$ kubectl create secret generic ceph-secret --type="kubernetes.io/rbd" --from-literal=key='QVFEQ1pMdFhPUnQrSmhBQUFYaERWNHJsZ3BsMmNjcDR6RFZST0E9PQ==' --namespace=kube-system

Quobyte

...

Azure Disk

...

Portworx Volume

...

ScaleIO

...

配置

如果你在寫配置模板和示例，用于在需要持久化存儲的集群中使用，那么，我們建議你使用以下的一些模式：
　　　● 在你的捆綁配置（如Deployment、ConfigMap胖）中包含PVC對象。
　　　● 在配置中不要包含PersistentVolume對象，因為實例化配置的用戶可能沒有創(chuàng)建PersistentVolumes的權(quán)限
　　　● 當用戶提供實例化模板時，給用戶提供存儲類名稱的選項。
　　　　? 如果用戶提供了一個StorageClass名稱，并且Kubernetes版本是1.4及以上，那么將該值設(shè)置在PVC的volume.beta.kubernetes.io/storage-class標注上。這會使得PVC匹配到正確的StorageClass。
　　　　? 如果用戶沒有提供StorageClass名稱，或者集群版本是1.3，那么久需要在PVC配置中設(shè)置volume.alpha.kubernetes.io/storage-class: default標注。
　　　　　? 這會使得在一些默認配置健全的集群中，PV可以動態(tài)的提供給用戶。
　　　　　? 盡管在名稱中包含了alpha單詞，但是該標注對應(yīng)的代碼有著beta級別的支持。
　　　　　? 不要使用volume.beta.kubernetes.io/storage-class，無論設(shè)置什么值，甚至是空字符串。因為它會阻止DefaultStorageClass許可控制器。
　　　● 在你的工具中，要監(jiān)視那些一段時間后還沒有獲得綁定的PVC，并且展示給用戶。因為這可能表明集群沒有支持動態(tài)存儲（此時我們應(yīng)該創(chuàng)建匹配的PV），或者集群沒有存儲系統(tǒng)（此時用戶不能部署需要PVC的情況）。
　　　● 未來，我們期望大多數(shù)集群都可以使能DefaultStorageClass，并且能有一些可用的存儲形式。然而，可能沒有行在所有集群都能運的StorageClass，所以默認情況下不要只設(shè)置一種。在某些時候，alpha標注將不再具有意義，但復(fù)位PVC的storageClass字段將具有所需的效果。

感謝各位的閱讀！關(guān)于“Kubernetes存儲中Persistent Volumes有什么用”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學(xué)到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！

本文題目：Kubernetes存儲中PersistentVolumes有什么用
鏈接地址：http://jinyejixie.com/article44/iiecee.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計、網(wǎng)站排名、企業(yè)建站、小程序開發(fā)、網(wǎng)站制作、網(wǎng)站設(shè)計公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)