理想情況下，在Kubernetes上部署應(yīng)用程序的開發(fā)人員不需要知道集群提供了什么存儲(chǔ)技術(shù)，就像他們不需要知道用于運(yùn)行pod的物理服務(wù)器的特征一樣?；A(chǔ)架構(gòu)的細(xì)節(jié)應(yīng)該由運(yùn)行集群的人員來處理。

由于這個(gè)原因，當(dāng)將應(yīng)用程序部署到Kubernetes時(shí)，通常不會(huì)像在上一章中所做的那樣，直接引用pod清單中的外部存儲(chǔ)。相反，將使用一種間接的方法，這在下一節(jié)中解釋。

前一章中的一個(gè)示例展示了如何在pod中使用NFS文件共享。pod清單中的卷定義包含NFS服務(wù)器的IP地址和該服務(wù)器文件路徑。這將pod定義綁定到特定的集群，導(dǎo)致無法在其他地方使用這個(gè)pod。

如下圖所示，如果要將這個(gè)pod部署到不同的集群，至少需要更改NFS服務(wù)器IP。這意味著pod定義不能跨集群移植。每次將其部署到新的Kubernetes集群時(shí)，都必須對(duì)其進(jìn)行修改。

圖8.1 包含特定于基礎(chǔ)設(shè)施的卷信息的pod清單不能移植到其他集群

8.1.1 持久卷和持久卷聲明簡(jiǎn)介

為了使pod清單在不同的集群環(huán)境中可移植，有關(guān)實(shí)際存儲(chǔ)卷的環(huán)境特定信息被移動(dòng)到PersistentVolume對(duì)象，如下圖所示。persistentvolumecclaim對(duì)象將pod連接到這個(gè)PersistentVolume對(duì)象。

圖8.2使用持久卷和持久卷聲明將網(wǎng)絡(luò)存儲(chǔ)附加到pod

下面將解釋這兩個(gè)對(duì)象。

持久卷簡(jiǎn)介

顧名思義，PersistentVolume對(duì)象表示用于持久存儲(chǔ)應(yīng)用程序數(shù)據(jù)的存儲(chǔ)卷。如上圖所示，PersistentVolume對(duì)象存儲(chǔ)關(guān)于底層存儲(chǔ)的信息，并將該信息與pod解耦。

如果pod清單中沒有此特定于基礎(chǔ)設(shè)施的信息，則可以使用相同的清單在不同的集群中部署pod。當(dāng)然，每個(gè)集群必須包含一個(gè)包含此信息的PersistentVolume對(duì)象。我同意這種方法似乎沒有解決任何問題，因?yàn)槲覀冎皇菍⑿畔⑥D(zhuǎn)移到不同的對(duì)象中，但稍后您將看到，這種新方法實(shí)現(xiàn)了以前不可能實(shí)現(xiàn)的事情。

持久卷聲明簡(jiǎn)介

pod并不直接引用PersistentVolume對(duì)象。相反，它指向一個(gè)persistentvolumecclaim對(duì)象，然后該對(duì)象指向PersistentVolume。

顧名思義，PersistentVolumeClaim對(duì)象表示用戶對(duì)持久卷的聲明。因?yàn)樗纳芷跊]有綁定到pod的生命周期，所以它允許持久卷的所有權(quán)與pod解耦。用戶在pod中使用持久卷之前，必須首先通過創(chuàng)建PersistentVolumeClaim對(duì)象來聲明該卷。在聲明了卷后，用戶擁有它的獨(dú)家權(quán)利，可以在他們的pod中使用它。他們可以隨時(shí)刪除pod，并且不會(huì)失去持久卷的所有權(quán)。當(dāng)不再需要該卷時(shí)，用戶通過刪除PersistentVolumeClaim對(duì)象來釋放它。

在Pod中使用持續(xù)卷聲明

要在pod中使用持久卷，只需在其清單中引用卷綁定到的持久卷聲明的名稱。

例如，如果您創(chuàng)建了一個(gè)持久卷聲明，它綁定到一個(gè)代表NFS文件共享的持久卷，那么可以通過添加指向PersistentVolumeClaim對(duì)象的卷定義，將NFS文件共享附加到pod。pod清單中的卷定義只需要包含持久卷聲明的名稱，不需要包含特定于基礎(chǔ)設(shè)施的信息，比如NFS服務(wù)器的IP地址。

如下圖所示，當(dāng)這個(gè)pod被調(diào)度到一個(gè)工作節(jié)點(diǎn)時(shí)，Kubernetes找到與pod中引用的聲明綁定的持久卷，并使用PersistentVolume對(duì)象中的信息將網(wǎng)絡(luò)存儲(chǔ)卷掛載到pod的容器中。

圖8.3 將持久卷掛載到容器中

在多個(gè)pod中使用一個(gè)聲明

多個(gè)pod可以使用相同的存儲(chǔ)卷，如果它們引用相同的持久卷聲明，從而傳遞到相同的持久卷，如下圖所示。

圖8.4 在多個(gè)pod中使用相同的持久卷聲明

這些pod是否必須運(yùn)行在相同的集群節(jié)點(diǎn)上，還是可以從不同的節(jié)點(diǎn)訪問底層存儲(chǔ)，取決于提供這種存儲(chǔ)的技術(shù)。如果底層存儲(chǔ)技術(shù)支持將存儲(chǔ)并發(fā)連接到多個(gè)節(jié)點(diǎn)，那么不同節(jié)點(diǎn)上的pod可以使用它。如果不是，則必須首先將pod調(diào)度到附加存儲(chǔ)卷的節(jié)點(diǎn)。

8.1.2 理解使用持久卷和持久卷聲明的好處

在一個(gè)系統(tǒng)中，必須使用兩個(gè)額外的對(duì)象才能讓pod使用存儲(chǔ)卷，這比前一章中解釋的簡(jiǎn)單方法要復(fù)雜得多，在前一章中，pod只是直接引用存儲(chǔ)卷。為什么這種新方法更好?

使用持久卷和聲明的最大好處是，特定于基礎(chǔ)設(shè)施的細(xì)節(jié)現(xiàn)在與pod所代表的應(yīng)用程序解耦了。集群管理員比任何人都更了解數(shù)據(jù)中心，可以創(chuàng)建包含所有與基礎(chǔ)設(shè)施相關(guān)的底層細(xì)節(jié)的PersistentVolume對(duì)象，而軟件開發(fā)人員只關(guān)注通過Pod和PersistentVolumeClaim對(duì)象描述應(yīng)用程序及其需求。

下圖顯示了兩個(gè)用戶角色及其創(chuàng)建的對(duì)象是如何配合在一起的。

圖8.5 持久卷由集群管理員提供，pod通過持久卷聲明使用。

不是由開發(fā)人員向pod中添加特定于技術(shù)的卷，而是由集群管理員設(shè)置底層存儲(chǔ)，然后通過Kubernetes API創(chuàng)建一個(gè)PersistentVolume對(duì)象將其注冊(cè)到Kubernetes中。

當(dāng)集群用戶需要在其中一個(gè)pod中進(jìn)行持久存儲(chǔ)時(shí)，它們首先創(chuàng)建一個(gè)PersistentVolumeClaim對(duì)象，在該對(duì)象中，它們可以通過名稱引用特定的持久卷，或者指定應(yīng)用程序所需的最小卷大小和訪問模式，然后讓Kubernetes找到滿足這些需求的持久卷。在這兩種情況下，持久性卷都被綁定到聲明，并被授予獨(dú)占訪問權(quán)。然后，可以在一個(gè)或多個(gè)pod的卷定義中引用該聲明。當(dāng)pod運(yùn)行時(shí)，在PersistentVolume對(duì)象中配置的存儲(chǔ)卷被附加到工作節(jié)點(diǎn)并掛載到pod的容器中。

應(yīng)用程序開發(fā)人員可以為Pod和PersistentVolumeClaim對(duì)象創(chuàng)建清單，而不需要了解應(yīng)用程序?qū)⒃谄渖线\(yùn)行的基礎(chǔ)設(shè)施，理解這一點(diǎn)很重要。類似地，集群管理員可以提前提供一組大小不同的存儲(chǔ)卷，而不需要了解將使用它們的應(yīng)用程序。

此外，通過使用持久卷的dynamic provisioning(本章后面將討論)，管理員根本不需要預(yù)先提供卷。如果集群中安裝了自動(dòng)卷發(fā)放器(automated volume provisioner)，則物理存儲(chǔ)卷和PersistentVolume對(duì)象將根據(jù)用戶創(chuàng)建的每個(gè)PersistentVolumeClaim對(duì)象的需要?jiǎng)?chuàng)建。

注：以上內(nèi)容譯自 《Kubernetes In Action,Second Edition》8.1節(jié)。閱讀完整版請(qǐng)關(guān)注gzh 登峰大數(shù)據(jù)。