Kubernetes CKA課程筆記 53
ConfigMap & Secret:
- 這兩個是特殊的Volume類型
- 一定是local Volume
- 不透過PV也不透過PVC建立
- 這兩個元件完全由K8s本身管理
ConfigMap & Secret使用場景:
- 考量到一些應用程式Pod需要額外的設定檔案
- 或是運行時需要憑證檔案
- 這時候需要有機制將這類檔案Mount到Pod/Container,就如同PVC那樣:
Pod內可同時存在多個不同的Volume類型:
- 比如考量到elastic-app的Pod
- 1.可以需要額外一些Configuration File透過ConfigMap來mount
- 2.需要client憑證透過Secret方式來mount
- 3.並且需要DataBase Storage(背後實體Storage可能是awsElasticBlockStore)
- 如下圖一個elastic-app的範例,其deployment Configuration yaml內
- 總共引入了三種不同種類的Volume!
Storage Class:
- 考量到一種情況,K8s Admin設計storage並建立許多PV
- 來供給開發者建立PVC來取用
- 但是K8s Cluster隨著發展,有上百個Pod在運行
- 與上述的Pod數量成正比關係,所要求的PV數量也增加非常多
- 其背後實體Storage可能源自各種Source(本地/雲..都可能)
- 並且實體Storage的設計以及PV的建立管理都是手動的
- 這類工作會過於繁鎖,並且費時
- 所以K8s為了這一狀況延伸出一個K8s Component — Storage Class(SC)
Storage Class(SC):
- 當PVC來請求PV時,SV動態提供PV
- Storage Class同樣也能由Configuration File建立(如下圖)
- 也就是每一種實體Storage Backend都有對應K8s提供的provisioner
- 並且provisioner有分internal(K8s提供)與external(K8s不提供)
- 上圖中的provisioner開頭"kubernetes.io"就表示internal
- 若provisioner開頭不是”kubernetes.io”就表示external
- 詳細internal列表如下:
- 至於如何定義請求的Persistent Volume就是要由parameters區塊決定:
- 所以Storage Class(SC)亦是另一個抽象層(abstraction level)
- 專門抽象化底層實體Storage提供者
- 參數化Storage(ex:disk type…etc)
- 使用上仍是被PVC請求:
至此就有完整的理解K8s 如何建立Persistent Volume來儲存Data
及過程中需要的三大K8s元件:
