本篇文章已超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
CSI 臨時內聯卷
通常,Kubernetes 中外部儲存驅動程式提供的磁碟區是持久性的,其生命週期完全獨立於 Pod,或(作為特例)與使用磁碟區的第一個 Pod 鬆散耦合(延遲綁定模式)。在 Kubernetes 中請求和定義此類磁碟區的機制是 Persistent Volume Claim (PVC) 和 Persistent Volume (PV) 物件。最初,由容器儲存介面 (CSI) 驅動程式支援的磁碟區只能透過此 PVC/PV 機制使用。
但也存在資料磁碟區的使用案例,其內容和生命週期與 Pod 綁定。例如,驅動程式可能會使用特定於在 Pod 中運行的應用程式的動態建立的密鑰來填充磁碟區。此類磁碟區需要與 Pod 一起建立,並且可以作為 Pod 終止的一部分刪除(臨時性)。它們在 Pod 規格中定義(內聯)。
自 Kubernetes 1.15 起,CSI 驅動程式也可以用於此類臨時內聯磁碟區。CSIInlineVolume 功能閘道 必須設定才能在 1.15 中啟用它,因為當時支援仍處於 Alpha 狀態。在 1.16 中,該功能達到 Beta 狀態,這通常表示它在叢集中預設啟用。
CSI 驅動程式必須進行調整以支援此功能,因為儘管使用了兩個現有的 CSI gRPC 呼叫 (NodePublishVolume
和 NodeUnpublishVolume
),但它們的使用方式不同,並且 CSI 規範未涵蓋:對於臨時磁碟區,只有 NodePublishVolume
在 kubelet
要求 CSI 驅動程式提供磁碟區時調用。所有其他呼叫(例如 CreateVolume
、NodeStageVolume
等)都會被跳過。磁碟區參數在 Pod 規格中提供,並從那裡複製到 NodePublishVolumeRequest.volume_context
欄位。目前沒有標準化的參數;即使是像大小這樣的常見參數也必須以 CSI 驅動程式定義的格式提供。同樣地,只有在 Pod 終止且需要移除磁碟區後,才會調用 NodeUnpublishVolume
。
最初,假設 CSI 驅動程式將專門編寫為提供持久性或臨時磁碟區。但也有些驅動程式提供的儲存既可用於持久性模式也可用於臨時模式:例如,PMEM-CSI 管理持久性記憶體 (PMEM),這是一種由 Intel® Optane™ DC Persistent Memory 提供的新型本地儲存。這種記憶體既可用作持久性資料儲存(比普通 SSD 快),也可用作臨時暫存空間(容量比 DRAM 更高)。
因此,Kubernetes 1.16 中的支援得到了擴展
- Kubernetes 和使用者可以透過
CSIDriver
物件 中的volumeLifecycleModes
欄位來確定驅動程式支援哪種類型的磁碟區。 - 驅動程式可以透過啟用 「掛載時的 Pod 資訊」 功能來取得有關磁碟區模式的資訊,然後這將把新的
csi.storage.k8s.io/ephemeral
條目新增到NodePublishRequest.volume_context
。
有關在 CSI 驅動程式中實作臨時內聯磁碟區支援的更多資訊,請參閱 Kubernetes-CSI 文件 和 原始設計文件。
此部落格文章接下來是基於真實驅動程式的使用範例,以及最後的摘要。
範例
PMEM-CSI
在 v0.6.0 版本 中新增了對臨時內聯磁碟區的支援。該驅動程式可用於具有真實 Intel® Optane™ DC Persistent Memory 的主機、GCE 中的特殊機器 或由 QEMU 模擬的硬體。後者已完全 整合到 makefile 中,並且只需要 Go、Docker 和 KVM,因此此範例使用了這種方法
git clone --branch release-0.6 https://github.com/intel/pmem-csi
cd pmem-csi
TEST_DISTRO=clear TEST_DISTRO_VERSION=32080 TEST_PMEM_REGISTRY=intel make start
啟動四節點叢集可能需要一段時間,但最終應以以下內容結束
The test cluster is ready. Log in with /work/pmem-csi/_work/pmem-govm/ssh-pmem-govm, run kubectl once logged in.
Alternatively, KUBECONFIG=/work/pmem-csi/_work/pmem-govm/kube.config can also be used directly.
To try out the pmem-csi driver persistent volumes:
...
To try out the pmem-csi driver ephemeral volumes:
cat deploy/kubernetes-1.17/pmem-app-ephemeral.yaml | /work/pmem-csi/_work/pmem-govm/ssh-pmem-govm kubectl create -f -
deploy/kubernetes-1.17/pmem-app-ephemeral.yaml
指定一個磁碟區
kind: Pod
apiVersion: v1
metadata:
name: my-csi-app-inline-volume
spec:
containers:
- name: my-frontend
image: busybox
command: [ "sleep", "100000" ]
volumeMounts:
- mountPath: "/data"
name: my-csi-volume
volumes:
- name: my-csi-volume
csi:
driver: pmem-csi.intel.com
fsType: "xfs"
volumeAttributes:
size: "2Gi"
nsmode: "fsdax"
一旦我們建立了該 Pod,我們就可以檢查結果
kubectl describe pods/my-csi-app-inline-volume
Name: my-csi-app-inline-volume
...
Volumes:
my-csi-volume:
Type: CSI (a Container Storage Interface (CSI) volume source)
Driver: pmem-csi.intel.com
FSType: xfs
ReadOnly: false
VolumeAttributes: nsmode=fsdax
size=2Gi
kubectl exec my-csi-app-inline-volume -- df -h /data
Filesystem Size Used Available Use% Mounted on
/dev/ndbus0region0fsdax/d7eb073f2ab1937b88531fce28e19aa385e93696
1.9G 34.2M 1.8G 2% /data
映像檔填充器
映像檔填充器會自動解壓縮容器映像檔,並使其內容可用作臨時磁碟區。它仍在開發中,但 Canary 映像檔已可用,可以使用以下命令安裝
kubectl create -f https://github.com/kubernetes-csi/csi-driver-image-populator/raw/master/deploy/kubernetes-1.16/csi-image-csidriverinfo.yaml
kubectl create -f https://github.com/kubernetes-csi/csi-driver-image-populator/raw/master/deploy/kubernetes-1.16/csi-image-daemonset.yaml
此範例 Pod 將運行 Nginx,並使其提供來自 kfox1111/misc:test
映像檔的資料
kubectl create -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx:1.16-alpine
ports:
- containerPort: 80
volumeMounts:
- name: data
mountPath: /usr/share/nginx/html
volumes:
- name: data
csi:
driver: image.csi.k8s.io
volumeAttributes:
image: kfox1111/misc:test
EOF
kubectl exec nginx -- cat /usr/share/nginx/html/test
該 test
檔案僅包含一個單字
testing
可以使用 Dockerfile 建立此類資料容器,例如
FROM scratch
COPY index.html /index.html
cert-manager-csi
cert-manager-csi 與 cert-manager 協同工作。此驅動程式的目標是促進無縫地請求和掛載憑證金鑰對到 Pod。這對於促進 mTLS 或以其他方式保護具有保證存在的憑證的 Pod 連接非常有用,同時具有 cert-manager 提供的所有功能。此專案是實驗性的。
後續步驟
臨時內聯磁碟區的問題之一是 Pod 由 Kubernetes 調度到節點上,而不知道該節點上目前可用的儲存空間。一旦 Pod 被調度,CSI 驅動程式必須使該節點上的磁碟區可用。如果目前不可能,則 Pod 無法啟動。這將不斷重試,直到最終磁碟區準備就緒。儲存容量追蹤 KEP 旨在解決此問題。
相關的 KEP 引入了 標準化的大小參數。
目前,CSI 臨時內聯磁碟區仍處於 Beta 階段,同時正在討論這些問題。需要您的回饋來決定如何繼續此功能。對於 KEP,上面連結的兩個 PR 是發表評論的好地方。SIG Storage 也 定期舉行會議,並且可以透過 Slack 和郵件列表 聯繫。