這篇文章給大家分享的是有關(guān)Kubernetes存儲(chǔ)中Persistent Volumes有什么用的內(nèi)容。小編覺(jué)得挺實(shí)用的，因此分享給大家做個(gè)參考，一起跟隨小編過(guò)來(lái)看看吧。
創(chuàng)新互聯(lián)公司專(zhuān)業(yè)為企業(yè)提供橫山網(wǎng)站建設(shè)、橫山做網(wǎng)站、橫山網(wǎng)站設(shè)計(jì)、橫山網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁(yè)設(shè)計(jì)與制作、橫山企業(yè)網(wǎng)站模板建站服務(wù)，10年橫山做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。
管理存儲(chǔ)和管理計(jì)算有著明顯的不同。PersistentVolume子系統(tǒng)給用戶和管理員提供了一套API，從而抽象出存儲(chǔ)是如何提供和消耗的細(xì)節(jié)。在這里，我們介紹兩種新的API資源：PersistentVolume（簡(jiǎn)稱(chēng)PV）和PersistentVolumeClaim（簡(jiǎn)稱(chēng)PVC）。
PersistentVolume（持久卷，簡(jiǎn)稱(chēng)PV）是集群內(nèi)，由管理員提供的網(wǎng)絡(luò)存儲(chǔ)的一部分。就像集群中的節(jié)點(diǎn)一樣，PV也是集群中的一種資源。它也像Volume一樣，是一種volume插件，但是它的生命周期卻是和使用它的Pod相互獨(dú)立的。PV這個(gè)API對(duì)象，捕獲了諸如NFS、ISCSI、或其他云存儲(chǔ)系統(tǒng)的實(shí)現(xiàn)細(xì)節(jié)。
PersistentVolumeClaim（持久卷聲明，簡(jiǎn)稱(chēng)PVC）是用戶的一種存儲(chǔ)請(qǐng)求。它和Pod類(lèi)似，Pod消耗Node資源，而PVC消耗PV資源。Pod能夠請(qǐng)求特定的資源（如CPU和內(nèi)存）。PVC能夠請(qǐng)求指定的大小和訪問(wèn)的模式（可以被映射為一次讀寫(xiě)或者多次只讀）。
PVC允許用戶消耗抽象的存儲(chǔ)資源，用戶也經(jīng)常需要各種屬性（如性能）的PV。集群管理員需要提供各種各樣、不同大小、不同訪問(wèn)模式的PV，而不用向用戶暴露這些volume如何實(shí)現(xiàn)的細(xì)節(jié)。因?yàn)檫@種需求，就催生出一種StorageClass資源。
StorageClass提供了一種方式，使得管理員能夠描述他提供的存儲(chǔ)的等級(jí)。集群管理員可以將不同的等級(jí)映射到不同的服務(wù)等級(jí)、不同的后端策略。
PV是集群中的資源，PVC是對(duì)這些資源的請(qǐng)求，同時(shí)也是這些資源的“提取證”。PV和PVC的交互遵循以下生命周期：
有兩種PV提供的方式：靜態(tài)和動(dòng)態(tài)。
集群管理員創(chuàng)建多個(gè)PV，它們攜帶著真實(shí)存儲(chǔ)的詳細(xì)信息，這些存儲(chǔ)對(duì)于集群用戶是可用的。它們存在于Kubernetes API中，并可用于存儲(chǔ)使用。
當(dāng)管理員創(chuàng)建的靜態(tài)PV都不匹配用戶的PVC時(shí)，集群可能會(huì)嘗試專(zhuān)門(mén)地供給volume給PVC。這種供給基于StorageClass：PVC必須請(qǐng)求這樣一個(gè)等級(jí)，而管理員必須已經(jīng)創(chuàng)建和配置過(guò)這樣一個(gè)等級(jí)，以備發(fā)生這種動(dòng)態(tài)供給的情況。請(qǐng)求等級(jí)配置為“”的PVC，有效地禁用了它自身的動(dòng)態(tài)供給功能。
用戶創(chuàng)建一個(gè)PVC（或者之前就已經(jīng)就為動(dòng)態(tài)供給創(chuàng)建了），指定要求存儲(chǔ)的大小和訪問(wèn)模式。master中有一個(gè)控制回路用于監(jiān)控新的PVC，查找匹配的PV（如果有），并把PVC和PV綁定在一起。如果一個(gè)PV曾經(jīng)動(dòng)態(tài)供給到了一個(gè)新的PVC，那么這個(gè)回路會(huì)一直綁定這個(gè)PV和PVC。另外，用戶總是至少能得到它們所要求的存儲(chǔ)，但是volume可能超過(guò)它們的請(qǐng)求。一旦綁定了，PVC綁定就是專(zhuān)屬的，無(wú)論它們的綁定模式是什么。
如果沒(méi)找到匹配的PV，那么PVC會(huì)無(wú)限期得處于unbound未綁定狀態(tài)，一旦PV可用了，PVC就會(huì)又變成綁定狀態(tài)。比如，如果一個(gè)供給了很多50G的PV集群，不會(huì)匹配要求100G的PVC。直到100G的PV添加到該集群時(shí)，PVC才會(huì)被綁定。
Pod使用PVC就像使用volume一樣。集群檢查PVC，查找綁定的PV，并映射PV給Pod。對(duì)于支持多種訪問(wèn)模式的PV，用戶可以指定想用的模式。
一旦用戶擁有了一個(gè)PVC，并且PVC被綁定，那么只要用戶還需要，PV就一直屬于這個(gè)用戶。用戶調(diào)度Pod，通過(guò)在Pod的volume塊中包含PVC來(lái)訪問(wèn)PV。
當(dāng)用戶使用PV完畢后，他們可以通過(guò)API來(lái)刪除PVC對(duì)象。當(dāng)PVC被刪除后，對(duì)應(yīng)的PV就被認(rèn)為是已經(jīng)是“released”了，但還不能再給另外一個(gè)PVC使用。前一個(gè)PVC的屬于還存在于該P(yáng)V中，必須根據(jù)策略來(lái)處理掉。
PV的回收策略告訴集群，在PV被釋放之后集群應(yīng)該如何處理該P(yáng)V。當(dāng)前，PV可以被Retained（保留）、 Recycled（再利用）或者Deleted（刪除）。保留允許手動(dòng)地再次聲明資源。對(duì)于支持刪除操作的PV卷，刪除操作會(huì)從Kubernetes中移除PV對(duì)象，還有對(duì)應(yīng)的外部存儲(chǔ)（如AWS EBS，GCE PD，Azure Disk，或者Cinder volume）。動(dòng)態(tài)供給的卷總是會(huì)被刪除。
如果PV卷支持再利用，再利用會(huì)在PV卷上執(zhí)行一個(gè)基礎(chǔ)的擦除操作（rm -rf /thevolume/*），使得它可以再次被其他PVC聲明利用。
管理員可以通過(guò)Kubernetes controller manager的命令行工具（點(diǎn)擊查看），來(lái)配置自定義的再利用Pod模板。自定義的再利用Pod模板必須包含PV卷的詳細(xì)內(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類(lèi)型使用插件的形式來(lái)實(shí)現(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 (僅測(cè)試過(guò)單節(jié)點(diǎn)的情況——不支持任何形式的本地存儲(chǔ)，多節(jié)點(diǎn)集群中不能工作)
VMware Photon
Portworx Volumes
ScaleIO Volumes
每個(gè)PV都包含一個(gè)spec和狀態(tài)，即說(shuō)明書(shū)和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
一般來(lái)說(shuō)，PV會(huì)指定存儲(chǔ)的容量，使用PV的capacity屬性來(lái)設(shè)置。查看Kubernetes的Resource Model來(lái)了解capacity。
當(dāng)前，存儲(chǔ)大小是唯一能被設(shè)置或請(qǐng)求的資源。未來(lái)可能包含IOPS，吞吐率等屬性。
PV可以使用存儲(chǔ)資源提供商支持的任何方法來(lái)映射到host中。如下的表格中所示，提供商有著不同的功能，每個(gè)PV的訪問(wèn)模式被設(shè)置為卷支持的指定模式。比如，NFS可以支持多個(gè)讀/寫(xiě)的客戶端，但可以在服務(wù)器上指定一個(gè)只讀的NFS PV。每個(gè)PV有它自己的訪問(wèn)模式。
訪問(wèn)模式包括：
? ReadWriteOnce —— 該volume只能被單個(gè)節(jié)點(diǎn)以讀寫(xiě)的方式映射
? ReadOnlyMany —— 該volume可以被多個(gè)節(jié)點(diǎn)以只讀方式映射
? ReadWriteMany —— 該volume只能被多個(gè)節(jié)點(diǎn)以讀寫(xiě)的方式映射
在CLI中，訪問(wèn)模式可以簡(jiǎn)寫(xiě)為：
? RWO - ReadWriteOnce
? ROX - ReadOnlyMany
? RWX - ReadWriteMany
注意：即使volume支持很多種訪問(wèn)模式，但它同時(shí)只能使用一種方式來(lái)映射。比如，GCEPersistentDisk可以被單個(gè)節(jié)點(diǎn)映射為ReadWriteOnce，或者多個(gè)節(jié)點(diǎn)映射為ReadOnlyMany，但不能同時(shí)使用這兩種方式來(lái)映射。
| Volume Plugin | ReadWriteOnce | ReadOnlyMany | ReadWriteMany |
|---|---|---|---|
| AWSElasticBlockStore | ? | - | - |
| AzureFile | ? | ? | ? |
| AzureDisk | ? | - | - |
| CephFS | ? | ? | ? |
| Cinder | ? | - | - |
| FC | ? | ? | - |
| FlexVolume | ? | ? | - |
| Flocker | ? | - | - |
| GCEPersistentDisk | ? | ? | - |
| Glusterfs | ? | ? | ? |
| HostPath | ? | - | - |
| iSCSI | ? | ? | - |
| PhotonPersistentDisk | ? | - | - |
| Quobyte | ? | ? | ? |
| NFS | ? | ? | ? |
| RBD | ? | ? | - |
| VsphereVolume | ? | - | - |
| PortworxVolume | ? | - | ? |
| ScaleIO | ? | ? | - |
一個(gè)PV可以有一種class，通過(guò)設(shè)置storageClassName屬性來(lái)選擇指定的StorageClass。有指定class的PV只能綁定給請(qǐng)求該class的PVC。沒(méi)有設(shè)置storageClassName屬性的PV只能綁定給未請(qǐng)求class的PVC。
過(guò)去，使用volume.beta.kubernetes.io/storage-class注解，而不是storageClassName屬性。該注解現(xiàn)在依然可以工作，但在Kubernetes的未來(lái)版本中已經(jīng)被完全棄用了。
當(dāng)前的回收策略有：
? Retain：手動(dòng)回收
? Recycle：需要擦出后才能再使用
? Delete：相關(guān)聯(lián)的存儲(chǔ)資產(chǎn)，如AWS EBS，GCE PD，Azure Disk，or OpenStack Cinder卷都會(huì)被刪除
當(dāng)前，只有NFS和HostPath支持回收利用，AWS EBS，GCE PD，Azure Disk，or OpenStack Cinder卷支持刪除操作。
一個(gè)volume卷處于以下幾個(gè)階段之一：
? Available：空閑的資源，未綁定給PVC
? Bound：綁定給了某個(gè)PVC
? Released：PVC已經(jīng)刪除了，但是PV還沒(méi)有被集群回收
? Failed：PV在自動(dòng)回收中失敗了
CLI可以顯示PV綁定的PVC名稱(chēng)。
當(dāng)PV被映射到一個(gè)node上時(shí)，Kubernetes管理員可以指定額外的映射選項(xiàng)?？梢酝ㄟ^(guò)使用標(biāo)注volume.beta.kubernetes.io/mount-options來(lái)指定PV的映射選項(xiàng)。
比如：
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
映射選項(xiàng)是當(dāng)映射PV到磁盤(pán)時(shí)，一個(gè)可以被遞增地添加和使用的字符串。
注意，并非所有的PV類(lèi)型都支持映射選項(xiàng)。在Kubernetes v1.6中，以下的PV類(lèi)型支持映射選項(xiàng)。
● GCEPersistentDisk
● AWSElasticBlockStore
● AzureFile
● AzureDisk
● NFS
● iSCSI
● RBD (Ceph Block Device)
● CephFS
● Cinder (OpenStack block storage)
● Glusterfs
● VsphereVolume
● Quobyte Volumes
● VMware Photon
每個(gè)PVC都包含一個(gè)spec和status，即該P(yáng)VC的規(guī)則說(shuō)明和狀態(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]}當(dāng)請(qǐng)求指定訪問(wèn)模式的存儲(chǔ)時(shí)，PVC使用的規(guī)則和PV相同。
PVC，就像pod一樣，可以請(qǐng)求指定數(shù)量的資源。請(qǐng)求資源時(shí)，PV和PVC都使用相同的資源樣式。
PVC可以指定標(biāo)簽選擇器進(jìn)行更深度的過(guò)濾PV，只有匹配了選擇器標(biāo)簽的PV才能綁定給PVC。選擇器包含兩個(gè)字段：
● matchLabels（匹配標(biāo)簽） - PV必須有一個(gè)包含該值得標(biāo)簽
● matchExpressions（匹配表達(dá)式） - 一個(gè)請(qǐng)求列表，包含指定的鍵、值的列表、關(guān)聯(lián)鍵和值的操作符。合法的操作符包含In，NotIn，Exists，和DoesNotExist。
所有來(lái)自matchLabels和matchExpressions的請(qǐng)求，都是邏輯與關(guān)系的，它們必須全部滿足才能匹配上。
PVC可以使用屬性storageClassName來(lái)指定StorageClass的名稱(chēng)，從而請(qǐng)求指定的等級(jí)。只有滿足請(qǐng)求等級(jí)的PV，即那些包含了和PVC相同storageClassName的PV，才能與PVC綁定。
PVC并非必須要請(qǐng)求一個(gè)等級(jí)。設(shè)置storageClassName為“”的PVC總是被理解為請(qǐng)求一個(gè)無(wú)等級(jí)的PV，因此它只能被綁定到無(wú)等級(jí)的PV（未設(shè)置對(duì)應(yīng)的標(biāo)注，或者設(shè)置為“”）。未設(shè)置storageClassName的PVC不太相同，DefaultStorageClass的權(quán)限插件打開(kāi)與否，集群也會(huì)區(qū)別處理PVC。
? 如果權(quán)限插件被打開(kāi)，管理員可能會(huì)指定一個(gè)默認(rèn)的StorageClass。所有沒(méi)有指定StorageClassName的PVC只能被綁定到默認(rèn)等級(jí)的PV。要指定默認(rèn)的StorageClass，需要在StorageClass對(duì)象中將標(biāo)注storageclass.kubernetes.io/is-default-class設(shè)置為“true”。如果管理員沒(méi)有指定這個(gè)默認(rèn)值，集群對(duì)PVC創(chuàng)建請(qǐng)求的回應(yīng)就和權(quán)限插件被關(guān)閉時(shí)一樣。如果指定了多個(gè)默認(rèn)等級(jí)，那么權(quán)限插件禁止PVC創(chuàng)建請(qǐng)求。
? 如果權(quán)限插件被關(guān)閉，那么久沒(méi)有默認(rèn)StorageClass的概念。所有沒(méi)有設(shè)置StorageClassName的PVC都只能綁定到?jīng)]有等級(jí)的PV。因此，沒(méi)有設(shè)置StorageClassName的PVC就如同設(shè)置StorageClassName為“”的PVC一樣被對(duì)待。
根據(jù)安裝方法的不同，默認(rèn)的StorageClass可能會(huì)在安裝過(guò)程中被插件管理默認(rèn)的部署在Kubernetes集群中。
當(dāng)PVC指定selector來(lái)請(qǐng)求StorageClass時(shí)，所有請(qǐng)求都是與操作的。只有滿足了指定等級(jí)和標(biāo)簽的PV才可能綁定給PVC。當(dāng)前，一個(gè)非空selector的PVC不能使用PV動(dòng)態(tài)供給。
過(guò)去，使用volume.beta.kubernetes.io/storage-class注解，而不是storageClassName屬性。該注解現(xiàn)在依然可以工作，但在Kubernetes的未來(lái)版本中已經(jīng)被完全棄用了。
Pod通過(guò)使用PVC（使用方式和volume一樣）來(lái)訪問(wèn)存儲(chǔ)。PVC必須和使用它的pod在同一個(gè)命名空間，集群發(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綁定是獨(dú)有的，因?yàn)镻VC是命名空間對(duì)象，映射PVC時(shí)只能在同一個(gè)命名空間中使用多種模式（ROX，RWX）。
每個(gè)StorageClass都包含字段provisioner和parameters，在所屬的PV需要?jiǎng)討B(tài)供給時(shí)使用這些字段。
StorageClass對(duì)象的命名是非常重要的，它是用戶請(qǐng)求指定等級(jí)的方式。當(dāng)創(chuàng)建StorageClass對(duì)象時(shí)，管理員設(shè)置等級(jí)的名稱(chēng)和其他參數(shù)，但對(duì)象不會(huì)在創(chuàng)建后馬上就被更新。
管理員可以指定一個(gè)默認(rèn)的StorageClass，用于綁定到那些未請(qǐng)求指定等級(jí)的PVC。詳細(xì)信息可參考PersistentVolumeClaim章節(jié)。
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: standard provisioner: kubernetes.io/aws-ebs parameters: type: gp2
StorageClass都有存儲(chǔ)供應(yīng)商provisioner，用來(lái)決定哪種volume插件提供給PV使用。必須制定該字段。
你不限于指定此處列出的“內(nèi)部”供應(yīng)商（其名稱(chēng)前綴為“kubernetes.io”并與Kubernetes一起分發(fā)）。你還可以運(yùn)行和指定外部供應(yīng)商，它們是遵循Kubernetes定義的規(guī)范的獨(dú)立程序。外部提供者的作者對(duì)代碼的生命周期，供應(yīng)商的分發(fā)方式，運(yùn)行狀況以及使用的卷插件（包括Flex）等都有充分的自主權(quán)。庫(kù)kubernetes-incubator/external-storage存放了一個(gè)庫(kù)， 用于編寫(xiě)外部存儲(chǔ)供應(yīng)商，而這些提供者實(shí)現(xiàn)了大量的規(guī)范，并且是各種社區(qū)維護(hù)的。
StorageClass有一些參數(shù)用于描述歸屬于該StorageClass的volume。不同的存儲(chǔ)提供商可能需要不同的參數(shù)。比如，參數(shù)type對(duì)應(yīng)的值io1，還有參數(shù)iopsPerGB，都是EBS專(zhuān)用的參數(shù)。當(dāng)參數(shù)省略時(shí)，就會(huì)使用它的默認(rèn)值。
...
...
...
...
...
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，逗號(hào)分隔。該參數(shù)是必須的。
● adminId：Ceph的客戶端ID，可在pool中創(chuàng)建鏡像。默認(rèn)的是“admin”。
● adminSecretNamespace：adminSecret的命名空間，默認(rèn)值是“default”。
● adminSecretName：adminId的Secret Name。改參數(shù)是必須的，提供的秘鑰必須有類(lèi)型“kubernetes.io/rbd”。
● pool：Ceph的RBD pool，默認(rèn)值是“rbd”。
● userId：Ceph的客戶ID，用于映射RBD鏡像的，默認(rèn)值和adminId參數(shù)相同。
● userSecretName：Ceph Secret的名稱(chēng)，userId用該參數(shù)來(lái)映射RBD鏡像。它必須和PVC在相同的命名空間。該參數(shù)也是必須的。提供的秘鑰必須有類(lèi)型“kubernetes.io/rbd”。比如，按照下面的方式來(lái)創(chuàng)建：
$ kubectl create secret generic ceph-secret --type="kubernetes.io/rbd" --from-literal=key='QVFEQ1pMdFhPUnQrSmhBQUFYaERWNHJsZ3BsMmNjcDR6RFZST0E9PQ==' --namespace=kube-system
...
...
...
...
如果你在寫(xiě)配置模板和示例，用于在需要持久化存儲(chǔ)的集群中使用，那么，我們建議你使用以下的一些模式：
● 在你的捆綁配置（如Deployment、ConfigMap胖）中包含PVC對(duì)象。
● 在配置中不要包含PersistentVolume對(duì)象，因?yàn)閷?shí)例化配置的用戶可能沒(méi)有創(chuàng)建PersistentVolumes的權(quán)限
● 當(dāng)用戶提供實(shí)例化模板時(shí)，給用戶提供存儲(chǔ)類(lèi)名稱(chēng)的選項(xiàng)。
? 如果用戶提供了一個(gè)StorageClass名稱(chēng)，并且Kubernetes版本是1.4及以上，那么將該值設(shè)置在PVC的volume.beta.kubernetes.io/storage-class標(biāo)注上。這會(huì)使得PVC匹配到正確的StorageClass。
? 如果用戶沒(méi)有提供StorageClass名稱(chēng)，或者集群版本是1.3，那么久需要在PVC配置中設(shè)置volume.alpha.kubernetes.io/storage-class: default標(biāo)注。
? 這會(huì)使得在一些默認(rèn)配置健全的集群中，PV可以動(dòng)態(tài)的提供給用戶。
? 盡管在名稱(chēng)中包含了alpha單詞，但是該標(biāo)注對(duì)應(yīng)的代碼有著beta級(jí)別的支持。
? 不要使用volume.beta.kubernetes.io/storage-class，無(wú)論設(shè)置什么值，甚至是空字符串。因?yàn)樗鼤?huì)阻止DefaultStorageClass許可控制器。
● 在你的工具中，要監(jiān)視那些一段時(shí)間后還沒(méi)有獲得綁定的PVC，并且展示給用戶。因?yàn)檫@可能表明集群沒(méi)有支持動(dòng)態(tài)存儲(chǔ)（此時(shí)我們應(yīng)該創(chuàng)建匹配的PV），或者集群沒(méi)有存儲(chǔ)系統(tǒng)（此時(shí)用戶不能部署需要PVC的情況）。
● 未來(lái)，我們期望大多數(shù)集群都可以使能DefaultStorageClass，并且能有一些可用的存儲(chǔ)形式。然而，可能沒(méi)有行在所有集群都能運(yùn)的StorageClass，所以默認(rèn)情況下不要只設(shè)置一種。在某些時(shí)候，alpha標(biāo)注將不再具有意義，但復(fù)位PVC的storageClass字段將具有所需的效果。
感謝各位的閱讀！關(guān)于“Kubernetes存儲(chǔ)中Persistent Volumes有什么用”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，讓大家可以學(xué)到更多知識(shí)，如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！
