Kubernetes CKA課程筆記 52
考量到開發者在K8s Cluster中建立了一個DB Pod
並且儲存資料在其中
經過幾天後該Pod掛掉了:
雖然可能只是測試環境的測試的Data
但如果是在正式環境,大概就完蛋了
所以必須要求DB Pod儲存的Data必須為Persistence
最簡單的想法就是儲存空間是K8s Pod以外的地方
也可以是K8s Cluster之外(如下圖)
此時如上的my-db Pod掛了,Data仍然沒事
等待my-db Pod重建後就完好無事!
所以接下來要瞭解K8s如何處理Data Persistence?
並且K8s提供哪些元件來做這件事?
實體storage:
要完成以上Data不遺失的儲存空間(Storage)會有幾項要求:
- Storage與Pod的生命週期不掛勾
- Storage必須是所有Nodes可以取用的(因為DB Pod隨機長在某個Node)
- Storage就算整個Cluster掛掉,也要能保證沒事
其他Storage使用場景可能只是一般應用程式的Pod在做read/write檔案
要建構這樣的Storage,就需要使用到K8s元件 — Persistent Volume
Persistent Volume(PV):
- 如同Cluster的Resource,但是是用來儲存Data
- 可以透過YAML檔建立:
- 1. kind : PersistentVolume
- 2. spec : 多少storage
- 但是其必須連接到實體(actual physical)的storage,可能有以下幾個選擇:
- 但是在K8s本身角度或觀點來說,其實並不care使用哪一種Storage
- K8s本身僅僅只是提供一個介面去做實體storage去串接
- 但是身為K8s Cluster管理者則必須要慎重選擇實體storage:
- 1. 需要什麼樣的storage
- 2. 甚至自行建立與管理(backup,no corrupt…etc)這些storage
- 把這些實體storage當作Cluster的外部plugin
- 甚至Cluster也能把不同的實體storage同時使用
- 更甚者是一個Pod連接兩種不同的實體storage
- (如一個nfs Server,一個cloud)
- 連接實體storage的部分寫在如下Configuration的spec區塊:
- 如上大致設置使用的空間大小,額外參數如ReadWriteOnce,nfs參數等
- 但是不同實體storage在上述的Configuration的spec區塊內有不同寫法:
依據不同實體storage,spec區塊的屬性會不一樣!
各範例實體storage連結如下:
- 並且要注意 →Persistent Volume(PV)不是限定在特定nameSpace的元件
- 所以可以允許整個Cluster取用
Local vs Remote Volume Types:
- 兩個類型有各自的使用場景(後面會再提到,也可能寫在下一篇)
- 但是Local類型的違反了前面的Data Persistent的2 & 3項要求(如下圖):
- 2. 也就是綁定特定Node,但是我們Pod又不一定都長在那一台上
- 3. 另外就是Cluster掛了,儲存的內容也就遺失了
- 宗上結論只能使用reomte storage
誰? 且 何時? 建立Persistent Volumes?
- PV(Persistent Volumes)如同其他的Resources(像是CPU,RAM…等等)
- 這些Resources是在Pod要調用前就已經存在了!
- 這邊講師額外筆記,一般K8s主要分兩個使用角色:
1. K8s Admin(建置與維護Cluster的人):
- 通常同時也負責管理Resources是否充足
- 一般是公司內系統Administrator/DevOps工程師擔任
2.K8s User:
- 通常是在做開發應用程式系統
- 並佈署直接或透過CI pipeline工具
- 將這些應用程式系統佈署到K8s Cluster內的人
- 可能是公司內的開發者/DevOps工程師擔任
在上述兩種K8s Cluster使用角色定義下
負責設定實體storage就是 — K8s Admin
例如串接nfs server,或是建立並串接Cloud storage提供給K8s Cluster調用
接著在K8s Cluster內建立Persistent Volumes元件來調用上述的實體storage
依據開發者團隊資訊判斷要使用哪一種實體storage,因為開發者才比較清楚
他們的應用程式比較適合使用哪一類的實體storage
在開發者(K8s User)觀點來說
開發者就要知道管理者(K8s Admin)提供了哪些Persistent Volumes元件
並且開發者要設計應用程式YAML來調用這些PV(Persistent Volumes)
換句話說這些應用程式
則需要去Claim這些Volume Storage(或稱Persistent Volumes)
而要做到這事需要另一個K8s Component — Persistent Volume Claim(PVC)
Persistent Volume Claim(PVC):
- 同樣需要透過YAML Configuration來建立
- 滿足PVC的PV就會被連接調用(如下圖)
- 但是設置好PV及PVC還不夠,還要設定Pod的Configuration
Levels of Volume abstractions:
來釐清整個請求Persistent Volume的邏輯順序:
- 1. Pod請求Volume是透過PVC(Persistent Volume Claim)
- 2. PVC則會嘗試找到Cluster中合適(滿足條件)的PV(Persistent Volume)
- 3. PV(Persistent Volume)背後則串接著實體storage提供Pod調用
- 並且注意Pod必須與PVC存在於同一個nameSpace內!
- 但是PV(Persistent Volume)則不綁定nameSpace,而是屬於Cluster元件
- 緊接著如下圖:
- 如上圖,其實若有多個Containers共用同一個Volume
- 若之後Pod掛了,重新建立新的Pod起來後,實體storage仍不受影響
- 新的Pod看到實體storage內儲存的Data
- 仍會是前一個Pod掛掉前看到(或寫入)的狀態或資料
為何如此多abstractions(抽象層)?
為啥會搞一堆實體storage ← →Pod內的Container之間
搞那麼多層(PV & PVC)
一般就是K8s Admin建立PV(Persistent Volume)
再來K8s User claim(求取)PV
有分拆這樣的抽象層(PV <->PVC)實際的好處,以K8s User觀點來說:
- K8s User或說開發者把應用程式系統佈署到K8s Cluster
- 開發者其實可以一點也不用關心實體storage具體在哪裡!
- 例如是要提供給DB的Persisten Volume
- 到底實際DB的資料是在Glusterfs(一種儲存空間)還是Cloud的儲存空間
- 抑或是local的實體storage,對開發者來說根本一點也沒差
- 開發者只要知道資料是很安全的儲存,並且不用自己建置實體storage
- 開發者只要知道自己的應用程式系統總共需要多大空間
- 然後建立PVC(Persistent Volume Claim)
- 且假定Cluster有足夠的儲存實體storage
- 對於開發者來說佈署其應用程式系統也就比較單純
