理想情況下，在Kubernetes上部署應用程序的開發(fā)人員不需要知道集群提供了什么存儲技術圃验，就像他們不需要知道用于運行pod的物理服務器的特征一樣掉伏。基礎架構的細節(jié)應該由運行集群的人員來處理。
由于這個原因斧散，當將應用程序部署到Kubernetes時供常，通常不會像在上一章中所做的那樣，直接引用pod清單中的外部存儲鸡捐。相反栈暇，將使用一種間接的方法，這在下一節(jié)中解釋箍镜。
前一章中的一個示例展示了如何在pod中使用NFS文件共享源祈。pod清單中的卷定義包含NFS服務器的IP地址和該服務器文件路徑。這將pod定義綁定到特定的集群鹿寨，導致無法在其他地方使用這個pod新博。
如下圖所示薪夕，如果要將這個pod部署到不同的集群脚草，至少需要更改NFS服務器IP。這意味著pod定義不能跨集群移植原献。每次將其部署到新的Kubernetes集群時馏慨，都必須對其進行修改。
圖8.1 包含特定于基礎設施的卷信息的pod清單不能移植到其他集群
8.1.1 持久卷和持久卷聲明簡介
為了使pod清單在不同的集群環(huán)境中可移植姑隅，有關實際存儲卷的環(huán)境特定信息被移動到PersistentVolume對象写隶，如下圖所示。persistentvolumecclaim對象將pod連接到這個PersistentVolume對象讲仰。
圖8.2使用持久卷和持久卷聲明將網(wǎng)絡存儲附加到pod
下面將解釋這兩個對象慕趴。
持久卷簡介
顧名思義，PersistentVolume對象表示用于持久存儲應用程序數(shù)據(jù)的存儲卷鄙陡。如上圖所示冕房，PersistentVolume對象存儲關于底層存儲的信息，并將該信息與pod解耦趁矾。
如果pod清單中沒有此特定于基礎設施的信息耙册，則可以使用相同的清單在不同的集群中部署pod。當然毫捣，每個集群必須包含一個包含此信息的PersistentVolume對象详拙。我同意這種方法似乎沒有解決任何問題，因為我們只是將信息轉移到不同的對象中蔓同，但稍后您將看到饶辙，這種新方法實現(xiàn)了以前不可能實現(xiàn)的事情。
持久卷聲明簡介
pod并不直接引用PersistentVolume對象斑粱。相反弃揽，它指向一個persistentvolumecclaim對象，然后該對象指向PersistentVolume。
顧名思義蹋宦，PersistentVolumeClaim對象表示用戶對持久卷的聲明披粟。因為它的生命周期沒有綁定到pod的生命周期，所以它允許持久卷的所有權與pod解耦冷冗。用戶在pod中使用持久卷之前守屉，必須首先通過創(chuàng)建PersistentVolumeClaim對象來聲明該卷。在聲明了卷后蒿辙，用戶擁有它的獨家權利拇泛，可以在他們的pod中使用它。他們可以隨時刪除pod思灌，并且不會失去持久卷的所有權俺叭。當不再需要該卷時，用戶通過刪除PersistentVolumeClaim對象來釋放它泰偿。
在Pod中使用持續(xù)卷聲明
要在pod中使用持久卷熄守，只需在其清單中引用卷綁定到的持久卷聲明的名稱。
例如耗跛，如果您創(chuàng)建了一個持久卷聲明裕照，它綁定到一個代表NFS文件共享的持久卷，那么可以通過添加指向PersistentVolumeClaim對象的卷定義调塌，將NFS文件共享附加到pod晋南。pod清單中的卷定義只需要包含持久卷聲明的名稱，不需要包含特定于基礎設施的信息羔砾，比如NFS服務器的IP地址负间。
如下圖所示，當這個pod被調(diào)度到一個工作節(jié)點時姜凄，Kubernetes找到與pod中引用的聲明綁定的持久卷政溃，并使用PersistentVolume對象中的信息將網(wǎng)絡存儲卷掛載到pod的容器中。
圖8.3 將持久卷掛載到容器中
在多個pod中使用一個聲明
多個pod可以使用相同的存儲卷檀葛，如果它們引用相同的持久卷聲明玩祟，從而傳遞到相同的持久卷，如下圖所示屿聋。
圖8.4 在多個pod中使用相同的持久卷聲明
這些pod是否必須運行在相同的集群節(jié)點上空扎，還是可以從不同的節(jié)點訪問底層存儲，取決于提供這種存儲的技術润讥。如果底層存儲技術支持將存儲并發(fā)連接到多個節(jié)點转锈，那么不同節(jié)點上的pod可以使用它。如果不是楚殿，則必須首先將pod調(diào)度到附加存儲卷的節(jié)點撮慨。
8.1.2 理解使用持久卷和持久卷聲明的好處
在一個系統(tǒng)中，必須使用兩個額外的對象才能讓pod使用存儲卷，這比前一章中解釋的簡單方法要復雜得多砌溺，在前一章中影涉，pod只是直接引用存儲卷。為什么這種新方法更好?
使用持久卷和聲明的最大好處是规伐，特定于基礎設施的細節(jié)現(xiàn)在與pod所代表的應用程序解耦了蟹倾。集群管理員比任何人都更了解數(shù)據(jù)中心，可以創(chuàng)建包含所有與基礎設施相關的底層細節(jié)的PersistentVolume對象猖闪，而軟件開發(fā)人員只關注通過Pod和PersistentVolumeClaim對象描述應用程序及其需求鲜棠。
下圖顯示了兩個用戶角色及其創(chuàng)建的對象是如何配合在一起的。
圖8.5 持久卷由集群管理員提供培慌，pod通過持久卷聲明使用豁陆。
不是由開發(fā)人員向pod中添加特定于技術的卷，而是由集群管理員設置底層存儲吵护，然后通過Kubernetes API創(chuàng)建一個PersistentVolume對象將其注冊到Kubernetes中盒音。
當集群用戶需要在其中一個pod中進行持久存儲時，它們首先創(chuàng)建一個PersistentVolumeClaim對象何址，在該對象中里逆，它們可以通過名稱引用特定的持久卷进胯，或者指定應用程序所需的最小卷大小和訪問模式用爪，然后讓Kubernetes找到滿足這些需求的持久卷。在這兩種情況下胁镐，持久性卷都被綁定到聲明偎血，并被授予獨占訪問權。然后盯漂，可以在一個或多個pod的卷定義中引用該聲明颇玷。當pod運行時，在PersistentVolume對象中配置的存儲卷被附加到工作節(jié)點并掛載到pod的容器中就缆。
應用程序開發(fā)人員可以為Pod和PersistentVolumeClaim對象創(chuàng)建清單帖渠，而不需要了解應用程序?qū)⒃谄渖线\行的基礎設施，理解這一點很重要竭宰。類似地空郊，集群管理員可以提前提供一組大小不同的存儲卷，而不需要了解將使用它們的應用程序切揭。
此外狞甚，通過使用持久卷的dynamic provisioning(本章后面將討論)，管理員根本不需要預先提供卷廓旬。如果集群中安裝了自動卷發(fā)放器(automated volume provisioner)哼审，則物理存儲卷和PersistentVolume對象將根據(jù)用戶創(chuàng)建的每個PersistentVolumeClaim對象的需要創(chuàng)建。
注：以上內(nèi)容譯自 《Kubernetes In Action,Second Edition》8.1節(jié)。閱讀完整版請關注gzh 登峰大數(shù)據(jù)涩盾。
