您好,登錄后才能下訂單哦!
本篇內容介紹了“hostPath volume存在的問題有哪些”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠學有所成!
過去我們經常會通過hostPath volume
讓Pod能夠使用本地存儲,將Node文件系統中的文件或者目錄掛載到容器內,但是hostPath volume
的使用是很難受的,并不適合在生產環境中使用。
我們先看看hostPath Type有哪些類型:
Value | Behavior |
---|---|
Empty string (default) is for backward compatibility, which means that no checks will be performed before mounting the hostPath volume. | |
DirectoryOrCreate | If nothing exists at the given path, an empty directory will be created there as needed with permission set to 0755, having the same group and ownership with Kubelet. |
Directory | A directory must exist at the given path |
FileOrCreate | If nothing exists at the given path, an empty file will be created there as needed with permission set to 0644, having the same group and ownership with Kubelet. |
File | A file must exist at the given path |
Socket | A UNIX socket must exist at the given path |
CharDevice | A character device must exist at the given path |
BlockDevice | A block device must exist at the given path |
看起來支持這么多type還是挺好的,但為什么說不適合在生產環境中使用呢?
由于集群內每個節點的差異化,要使用hostPath Volume,我們需要通過NodeSelector等方式進行精確調度,這種事情多了,你就會不耐煩了。
注意DirectoryOrCreate和FileOrCreate兩種類型的hostPath,當Node上沒有對應的File/Directory時,你需要保證kubelet有在Node上Create File/Directory的權限。
另外,如果Node上的文件或目錄是由root創建的,掛載到容器內之后,你通常還要保證容器內進程有權限對該文件或者目錄進行寫入,比如你需要以root用戶啟動進程并運行于privileged容器,或者你需要事先修改好Node上的文件權限配置。
Scheduler并不會考慮hostPath volume的大小,hostPath也不能申明需要的storage size,這樣調度時存儲的考慮,就需要人為檢查并保證。
StatefulSet無法使用hostPath volume,已經寫好的使用共享存儲的Helm Chart不能兼容hostPath volume,需要修改的地方還不少,這也挺難受的。
FEATURE STATE: Kubernetes v1.11 Beta
Local persistent volume就是用來解決hostPath volume面臨的**portability, disk accounting, and scheduling
**的缺陷。PV Controller和Scheduler會對local PV做特殊的邏輯處理,以實現Pod使用本地存儲時發生Pod re-schedule的情況下能再次調度到local volume所在的Node。
local pv在生產中使用,也是需要謹慎的,畢竟它本質上還是使用的是節點上的本地存儲,如果沒有相應的存儲副本機制,那意味著一旦節點或者磁盤異常,使用該volume的Pod也會異常,甚至出現數據丟失,除非你明確知道這個風險不會對你的應用造成很大影響或者允許數據丟失。
那么通常什么情況會使用Local PV呢?
比如節點上的目錄數據是從遠程的網絡存儲上掛載或者預先讀取到本地的,為了能加速Pod讀取這些數據的速度,相當于起Cache作用,這種情況下因為只讀,不存在懼怕數據丟失。這種AI訓練中存在需要重復利用并且訓練數據巨大的時候可能會采取的方式。
如果本地節點上目錄/磁盤實際是具有副本/分片機制的分布式存儲(比如gluster, ceph等)掛載過來的,這種情況也可以使用local pv。
Local volume允許掛載本地的disk, partition, directory到容器內某個掛載點。在Kuberentes 1.11仍然僅支持local pv的static provision,不支持dynamic provision。
Kubernetes使用PersistentVolume的.spec.nodeAffinity
field來描述local volume與Node的綁定關系。
使用volumeBindingMode: WaitForFirstConsumer
的local-storage StorageClass來實現PVC的延遲綁定,使得PV Controller并不會立刻為PVC做Bound,而是等待某個需要使用該local pv的Pod完成調度后,才去做Bound。
下面是定義local pv的Sample:
apiVersion: v1 kind: PersistentVolume metadata: name: example-pv spec: capacity: storage: 100Gi # volumeMode field requires BlockVolume Alpha feature gate to be enabled. volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: local-storage local: path: /mnt/disks/ssd1 nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - example-node
對應的local-storage storageClass定義如下:
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: local-storage provisioner: kubernetes.io/no-provisioner volumeBindingMode: WaitForFirstConsumer
使用local pv時必須定義nodeAffinity,Kubernetes Scheduler需要使用PV的nodeAffinity描述信息來保證Pod能夠調度到有對應local volume的Node上。
volumeMode可以是FileSystem(Default)和Block,并且需要enable BlockVolume Alpha feature gate。
創建local PV之前,你需要先保證有對應的storageClass已經創建。并且該storageClass的volumeBindingMode必須是WaitForFirstConsumer以標識延遲Volume Binding。WaitForFirstConsumer可以保證正常的Pod調度要求(resource requirements, node selectors, Pod affinity, and Pod anti-affinity等),又能保證Pod需要的Local PV的nodeAffinity得到滿足,實際上,一共有以下兩種volumeBindingMode:
// VolumeBindingImmediate indicates that PersistentVolumeClaims should be // immediately provisioned and bound. VolumeBindingImmediate VolumeBindingMode = "Immediate" // VolumeBindingWaitForFirstConsumer indicates that PersistentVolumeClaims // should not be provisioned and bound until the first Pod is created that // references the PeristentVolumeClaim. The volume provisioning and // binding will occur during Pod scheduing. VolumeBindingWaitForFirstConsumer VolumeBindingMode = "WaitForFirstConsumer"
節點上local volume的初始化需要我們人為去完成(比如local disk需要pre-partitioned, formatted, and mounted. 共享存儲對應的Directories也需要pre-created),并且人工創建這個local PV,當Pod結束,我們還需要手動的清理local volume,然后手動刪除該local PV對象。因此,persistentVolumeReclaimPolicy只能是Retain。
上面這么多事情需要人為的去做預處理的工作,我們必須要有解決方案幫我們自動完成local volume的create和cleanup的工作。官方給出了一個簡單的local volume manager,注意它仍然只是一個static provisioner,目前主要幫我們做兩件事:
local volume manager 監控配置好的discovery directory
的新的掛載點,并為每個掛載點根據對應的storageClassName, path, nodeAffinity, and capacity創建PersistentVolume object。
當Pod結束并刪除了使用local volume的PVC,local volume manager將自動清理該local mount上的所有文件, 然后刪除對應的PersistentVolume object.
因此,除了需要人為的完成local volume的mount操作,local PV的生命周期管理就全部交給local volume manager了。下面我們專門介紹下這個Static Local Volume Provisioner。
“hostPath volume存在的問題有哪些”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站,小編將為大家輸出更多高質量的實用文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。