Kubernetes 1.31：基於 OCI Artifacts 的唯讀 Volume (alpha)

作者：Sascha Grunert | 週五，2024 年 8 月 16 日

Kubernetes 社群正朝著在未來實現更多人工智慧 (AI) 和機器學習 (ML) 用例的方向發展。雖然該專案過去的設計宗旨是滿足微服務架構，但現在是時候傾聽終端使用者的聲音，並引入更著重於 AI/ML 的功能。

這些需求之一是直接將相容於開放容器倡議組織 (OCI) 的映像檔和成品 (稱為 OCI 物件) 作為原生 Volume 來源來支援。這讓使用者可以專注於 OCI 標準，並讓他們能夠使用 OCI 登錄檔來儲存和散布任何內容。像這樣的功能讓 Kubernetes 專案有機會發展到超越執行特定映像檔的用例。

有鑑於此，Kubernetes 社群很榮幸地推出 v1.31 中引入的新 Alpha 功能：映像檔 Volume 來源 (KEP-4639)。此功能允許使用者在 Pod 中指定映像檔參考作為 Volume，同時在容器中重複使用它作為 Volume 掛載點

…
kind: Pod
spec:
  containers:
    - …
      volumeMounts:
        - name: my-volume
          mountPath: /path/to/directory
  volumes:
    - name: my-volume
      image:
        reference: my-image:tag

上述範例會導致將 my-image:tag 掛載到 Pod 容器中的 /path/to/directory。

用例

此增強功能的目標是盡可能貼近 kubelet 內現有的容器映像檔實作，同時引入新的 API 介面以允許更廣泛的用例。

例如，使用者可以在 Pod 中多個容器之間共用組態檔，而無需將該檔案包含在主要映像檔中，以便他們可以最大限度地降低安全風險和整體映像檔大小。他們也可以使用 OCI 映像檔封裝和散布二進位成品，並將它們直接掛載到 Kubernetes Pod 中，以便他們可以簡化他們的 CI/CD 管道作為範例。

資料科學家、MLOps 工程師或 AI 開發人員，可以在 Pod 中與模型伺服器一起掛載大型語言模型權重或機器學習模型權重，以便他們可以有效地為它們提供服務，而無需將它們包含在模型伺服器容器映像檔中。他們可以將這些封裝在 OCI 物件中，以利用 OCI 散布並確保高效的模型部署。這讓他們能夠將模型規格/內容與處理它們的可執行檔分開。

另一個用例是，安全工程師可以使用公共映像檔作為惡意軟體掃描器，並掛載私人 (商業) 惡意軟體簽名的 Volume，以便他們可以載入這些簽名，而無需建立自己的組合映像檔 (公共映像檔的版權可能不允許這樣做)。這些檔案適用於掃描器軟體的作業系統或版本。

但在長期而言，由身為此專案終端使用者的您來概述新功能的更多重要用例。 SIG Node 很高興取得任何關於進一步增強功能的意見反應或建議，以允許更進階的使用情境。歡迎隨時透過 Kubernetes Slack (#sig-node) 頻道或 SIG Node mailinglist 提供意見反應。

詳細範例

Kubernetes Alpha 功能閘道 ImageVolume 需要在 API Server 以及 kubelet 上啟用，使其能夠運作。如果情況如此，且容器執行期支援此功能 (例如 CRI-O ≥ v1.31)，則可以建立像這樣的範例 pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod
spec:
  containers:
    - name: test
      image: registry.k8s.io/e2e-test-images/echoserver:2.3
      volumeMounts:
        - name: volume
          mountPath: /volume
  volumes:
    - name: volume
      image:
        reference: quay.io/crio/artifact:v1
        pullPolicy: IfNotPresent

Pod 使用 quay.io/crio/artifact:v1 的 image.reference 宣告新的 Volume，這指的是包含兩個檔案的 OCI 物件。 pullPolicy 的行為與容器映像檔相同，並允許下列值

Always：kubelet 始終嘗試提取參考，如果提取失敗，容器建立將會失敗。
Never：kubelet 永遠不會提取參考，而僅使用本機映像檔或成品。如果參考不存在，容器建立將會失敗。
IfNotPresent：如果磁碟上還沒有參考，kubelet 會提取參考。如果參考不存在且提取失敗，容器建立將會失敗。

volumeMounts 欄位指示名稱為 test 的容器應將 Volume 掛載在路徑 /volume 下。

如果您現在建立 Pod

kubectl apply -f pod.yaml

然後 exec 進入它

kubectl exec -it pod -- sh

那麼您就能夠調查已掛載的內容

/ # ls /volume
dir   file
/ # cat /volume/file
2
/ # ls /volume/dir
file
/ # cat /volume/dir/file
1

您已成功使用 Kubernetes 取用 OCI 成品！

容器執行期會提取映像檔 (或成品)、將其掛載到容器，並使其最終可直接使用。實作中有許多細節，這些細節與 kubelet 現有的映像檔提取行為密切相關。例如

如果提供 :latest 標籤作為 reference，則 pullPolicy 將預設為 Always，而在任何其他情況下，如果未設定，則預設為 IfNotPresent。
如果 Pod 被刪除並重新建立，則 Volume 會重新解析，這表示新的遠端內容將在 Pod 重新建立時可用。在 Pod 啟動期間解析或提取映像檔失敗將會阻止容器啟動，並可能增加顯著的延遲。失敗將使用正常的 Volume 退避重試，並將在 Pod 原因和訊息中報告。
提取密碼將以與容器映像檔相同的方式組裝，方法是查找節點憑證、服務帳戶映像檔提取密碼和 Pod Spec 映像檔提取密碼。
OCI 物件會透過合併資訊清單層的方式掛載在單一目錄中，這與容器映像檔相同。
Volume 以唯讀 (ro) 和不可執行檔案 (noexec) 的方式掛載。
不支援容器的子路徑掛載 (spec.containers[*].volumeMounts.subpath)。
欄位 spec.securityContext.fsGroupChangePolicy 對於此 Volume 類型沒有影響。
如果啟用 AlwaysPullImages 准入外掛程式，此功能也將適用。

感謝您閱讀到這篇部落格文章的結尾！SIG Node 很榮幸也很高興能夠交付此功能作為 Kubernetes v1.31 的一部分。

作為這篇部落格文章的作者，我要特別感謝所有參與其中的人士！你們都很棒，讓我們繼續努力！

Kubernetes 部落格

Kubernetes 1.31：基於 OCI Artifacts 的唯讀 Volume (alpha)

用例

詳細範例

延伸閱讀