建站
咨詢
售后
建站咨詢
新聞中心
臨時卷
本文檔描述 Kubernetes 中的 臨時卷（Ephemeral Volume）。 建議先了解卷，特別是 PersistentVolumeClaim 和 PersistentVolume。
有些應(yīng)用程序需要額外的存儲，但并不關(guān)心數(shù)據(jù)在重啟后仍然可用。 例如，緩存服務(wù)經(jīng)常受限于內(nèi)存大小，將不常用的數(shù)據(jù)轉(zhuǎn)移到比內(nèi)存慢、但對總體性能的影響很小的存儲中。
另有些應(yīng)用程序需要以文件形式注入的只讀數(shù)據(jù)，比如配置數(shù)據(jù)或密鑰。
臨時卷 就是為此類用例設(shè)計的。因為卷會遵從 Pod 的生命周期，與 Pod 一起創(chuàng)建和刪除， 所以停止和重新啟動 Pod 時，不會受持久卷在何處可用的限制。
臨時卷在 Pod 規(guī)范中以 內(nèi)聯(lián) 方式定義，這簡化了應(yīng)用程序的部署和管理。
臨時卷的類型
Kubernetes 為了不同的目的，支持幾種不同類型的臨時卷：
- emptyDir： Pod 啟動時為空，存儲空間來自本地的 kubelet 根目錄（通常是根磁盤）或內(nèi)存
- configMap、 downwardAPI、 secret： 將不同類型的 Kubernetes 數(shù)據(jù)注入到 Pod 中
- CSI 臨時卷： 類似于前面的卷類型，但由專門支持此特性 的指定 CSI 驅(qū)動程序提供
- 通用臨時卷： 它可以由所有支持持久卷的存儲驅(qū)動程序提供
?emptyDir?、?configMap?、?downwardAPI?、?secret ?是作為 本地臨時存儲 提供的。它們由各個節(jié)點上的 kubelet 管理。
CSI 臨時卷 必須 由第三方 CSI 存儲驅(qū)動程序提供。
通用臨時卷 可以 由第三方 CSI 存儲驅(qū)動程序提供，也可以由支持動態(tài)配置的任何其他存儲驅(qū)動程序提供。 一些專門為 CSI 臨時卷編寫的 CSI 驅(qū)動程序，不支持動態(tài)供應(yīng)：因此這些驅(qū)動程序不能用于通用臨時卷。
使用第三方驅(qū)動程序的優(yōu)勢在于，它們可以提供 Kubernetes 本身不支持的功能， 例如，與 kubelet 管理的磁盤具有不同運行特征的存儲，或者用來注入不同的數(shù)據(jù)
CSI 臨時卷
FEATURE STATE: Kubernetes v1.16 [beta]
該特性需要啟用參數(shù) ?CSIInlineVolume ?特性門控（feature gate）。 該參數(shù)從 Kubernetes 1.16 開始默認(rèn)啟用。
只有一部分 CSI 驅(qū)動程序支持 CSI 臨時卷。Kubernetes CSI 驅(qū)動程序列表 顯示了支持臨時卷的驅(qū)動程序。
從概念上講，CSI 臨時卷類似于 ?configMap?、?downwardAPI ?和 ?secret ?類型的卷： 其存儲在每個節(jié)點本地管理，并在將 Pod 調(diào)度到節(jié)點后與其他本地資源一起創(chuàng)建。 在這個階段，Kubernetes 沒有重新調(diào)度 Pods 的概念。卷創(chuàng)建不太可能失敗，否則 Pod 啟動將會受阻。 特別是，這些卷 不 支持感知存儲容量的 Pod 調(diào)度。 它們目前也沒包括在 Pod 的存儲資源使用限制中，因為 kubelet 只能對它自己管理的存儲強制執(zhí)行。
下面是使用 CSI 臨時存儲的 Pod 的示例清單：
kind: Pod
apiVersion: v1
metadata:
name: my-csi-app
spec:
containers:
- name: my-frontend
image: busybox:1.28
volumeMounts:
- mountPath: "/data"
name: my-csi-inline-vol
command: [ "sleep", "1000000" ]
volumes:
- name: my-csi-inline-vol
csi:
driver: inline.storage.kubernetes.io
volumeAttributes:
foo: bar?volumeAttributes ?決定驅(qū)動程序準(zhǔn)備什么樣的卷。這些屬性特定于每個驅(qū)動程序，且沒有實現(xiàn)標(biāo)準(zhǔn)化。 有關(guān)進一步的說明，請參閱每個 CSI 驅(qū)動程序的文檔。
CSI 驅(qū)動程序限制
FEATURE STATE: Kubernetes v1.21 [deprecated]
作為一個集群管理員，你可以使用 PodSecurityPolicy 來控制在 Pod 中可以使用哪些 CSI 驅(qū)動程序， 具體則是通過 ?allowedCSIDrivers 字段? 指定。
PodSecurityPolicy 已棄用，并將在 Kubernetes v1.25 版本中移除。
CSI 臨時卷僅有 CSI 驅(qū)動程序的一個子集支持。 Kubernetes CSI 驅(qū)動列表顯示了哪些驅(qū)動程序支持臨時卷。
通用臨時卷
FEATURE STATE: Kubernetes v1.23 [stable]
通用臨時卷類似于 ?emptyDir ?卷，因為它為每個 Pod 提供臨時數(shù)據(jù)存放目錄， 在最初制備完畢時一般為空。不過通用臨時卷也有一些額外的功能特性：
- 存儲可以是本地的，也可以是網(wǎng)絡(luò)連接的。
- 卷可以有固定的大小，pod不能超量使用。
- 卷可能有一些初始數(shù)據(jù)，這取決于驅(qū)動程序和參數(shù)。
- 當(dāng)驅(qū)動程序支持，卷上的典型操作將被支持，包括 （快照、 克隆、 調(diào)整大小和 存儲容量跟蹤）。
示例：
kind: Pod
apiVersion: v1
metadata:
name: my-app
spec:
containers:
- name: my-frontend
image: busybox:1.28
volumeMounts:
- mountPath: "/scratch"
name: scratch-volume
command: [ "sleep", "1000000" ]
volumes:
- name: scratch-volume
ephemeral:
volumeClaimTemplate:
metadata:
labels:
type: my-frontend-volume
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "scratch-storage-class"
resources:
requests:
storage: 1Gi生命周期和 PersistentVolumeClaim
關(guān)鍵的設(shè)計思想是在 Pod 的卷來源中允許使用 卷申領(lǐng)的參數(shù)。 PersistentVolumeClaim 的標(biāo)簽、注解和整套字段集均被支持。 創(chuàng)建這樣一個 Pod 后， 臨時卷控制器在 Pod 所屬的命名空間中創(chuàng)建一個實際的 PersistentVolumeClaim 對象， 并確保刪除 Pod 時，同步刪除 PersistentVolumeClaim。
如上設(shè)置將觸發(fā)卷的綁定與/或準(zhǔn)備操作，相應(yīng)動作或者在 StorageClass 使用即時卷綁定時立即執(zhí)行， 或者當(dāng) Pod 被暫時性調(diào)度到某節(jié)點時執(zhí)行 (?WaitForFirstConsumer ?卷綁定模式)。 對于常見的臨時卷，建議采用后者，這樣調(diào)度器就可以自由地為 Pod 選擇合適的節(jié)點。 對于即時綁定，調(diào)度器則必須選出一個節(jié)點，使得在卷可用時，能立即訪問該卷。
就資源所有權(quán)而言， 擁有通用臨時存儲的 Pod 是提供臨時存儲 (ephemeral storage) 的 PersistentVolumeClaim 的所有者。 當(dāng) Pod 被刪除時，Kubernetes 垃圾收集器會刪除 PVC， 然后 PVC 通常會觸發(fā)卷的刪除，因為存儲類的默認(rèn)回收策略是刪除卷。 你可以使用帶有 ?retain ?回收策略的 StorageClass 創(chuàng)建準(zhǔn)臨時 (quasi-ephemeral) 本地存儲： 該存儲比 Pod 壽命長，在這種情況下，你需要確保單獨進行卷清理。
當(dāng)這些 PVC 存在時，它們可以像其他 PVC 一樣使用。 特別是，它們可以被引用作為批量克隆或快照的數(shù)據(jù)源。 PVC對象還保持著卷的當(dāng)前狀態(tài)。
PersistentVolumeClaim 的命名
自動創(chuàng)建的 PVCs 的命名是確定的：此名稱是 Pod 名稱和卷名稱的組合，中間由連字符(?-?)連接。 在上面的示例中，PVC 將命名為 ?my-app-scratch-volume? 。 這種確定性命名方式使得與 PVC 交互變得更容易，因為一旦知道 Pod 名稱和卷名，就不必搜索它。
這種確定性命名方式也引入了潛在的沖突， 比如在不同的 Pod 之間（名為 “Pod-a” 的 Pod 掛載名為 "scratch" 的卷， 和名為 "pod" 的 Pod 掛載名為 “a-scratch” 的卷，這兩者均會生成名為 "pod-a-scratch" 的PVC），或者在 Pod 和手工創(chuàng)建的 PVC 之間。
以下沖突會被檢測到：如果 PVC 是為 Pod 創(chuàng)建的，那么它只用于臨時卷。 此檢測基于所有權(quán)關(guān)系?，F(xiàn)有的 PVC 不會被覆蓋或修改。 但這并不能解決沖突，因為如果沒有正確的 PVC，Pod 就無法啟動。
當(dāng)命名 Pods 和卷出現(xiàn)在同一個命名空間中時，要小心，以防止發(fā)生此類沖突。
安全
啟用 GenericEphemeralVolume 特性會導(dǎo)致那些沒有 PVCs 創(chuàng)建權(quán)限的用戶， 在創(chuàng)建 Pods 時，被允許間接的創(chuàng)建 PVCs。 集群管理員必須意識到這一點。 如果這不符合他們的安全模型，他們有如下選擇：
- 通過特性門控顯式禁用該特性。
- 使用一個準(zhǔn)入 Webhook 拒絕包含通用臨時卷的 Pods。
- 當(dāng) ?
volumes?列表不包含 ?ephemeral?卷類型時，使用 Pod 安全策略。 （這一方式在 Kubernetes 1.21 版本已經(jīng)棄用）
為 PVC 卷所設(shè)置的逐名字空間的配額 仍然有效，因此即使允許用戶使用這種新機制，他們也不能使用它來規(guī)避其他策略。
文章標(biāo)題：創(chuàng)新互聯(lián)kubernetes教程：Kubernetes臨時卷
標(biāo)題URL：http://m.5511xx.com/article/dhhpcij.html
