執行期類別

本頁面說明 RuntimeClass 資源和執行期選取機制。

RuntimeClass 是一項用於選取容器執行期組態的功能。容器執行期組態用於執行 Pod 的容器。

動機

您可以在不同的 Pod 之間設定不同的 RuntimeClass，以在效能與安全性之間取得平衡。例如，如果您的部分工作負載需要高層級的資訊安全保證，您可以選擇排程這些 Pod，使其在使用硬體虛擬化的容器執行期中執行。然後，您將受益於替代執行期的額外隔離，但會犧牲一些額外負擔。

您也可以使用 RuntimeClass，以相同的容器執行期但不同的設定來執行不同的 Pods。

設定

1. 在節點上設定 CRI 實作 (取決於執行期)
2. 建立對應的 RuntimeClass 資源

1. 在節點上設定 CRI 實作

可透過 RuntimeClass 取得的組態取決於容器執行期介面 (CRI) 實作。請參閱您的 CRI 實作的對應文件 (下方)，以了解如何設定。

組態具有對應的 handler 名稱，由 RuntimeClass 參考。處理常式必須是有效的 DNS 標籤名稱。

2. 建立對應的 RuntimeClass 資源

步驟 1 中設定的組態應各自具有相關聯的 handler 名稱，以識別組態。針對每個處理常式，建立對應的 RuntimeClass 物件。

RuntimeClass 資源目前僅有 2 個重要欄位：RuntimeClass 名稱 (metadata.name) 和處理常式 (handler)。物件定義如下

# RuntimeClass is defined in the node.k8s.io API group
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  # The name the RuntimeClass will be referenced by.
  # RuntimeClass is a non-namespaced resource.
  name: myclass 
# The name of the corresponding CRI configuration
handler: myconfiguration 

RuntimeClass 物件的名稱必須是有效的 DNS 子網域名稱。

用法

一旦為叢集設定 RuntimeClasses，您可以在 Pod 規格中指定 runtimeClassName 以使用它。例如

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  runtimeClassName: myclass
  # ...

這將指示 kubelet 使用指定的 RuntimeClass 來執行此 pod。如果指定的 RuntimeClass 不存在，或 CRI 無法執行對應的處理常式，則 pod 將進入 Failed 終端 階段。尋找對應的 事件 以取得錯誤訊息。

如果未指定 runtimeClassName，則將使用預設 RuntimeHandler，這相當於停用 RuntimeClass 功能時的行為。

CRI 組態

如需有關設定 CRI 執行期的更多詳細資訊，請參閱 CRI 安裝。

containerd

執行期處理常式是透過 containerd 在 /etc/containerd/config.toml 的組態設定。有效的處理常式是在 runtimes 區段下設定

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]

如需更多詳細資訊，請參閱 containerd 的 組態文件

CRI-O

執行期處理常式是透過 CRI-O 在 /etc/crio/crio.conf 的組態設定。有效的處理常式是在 crio.runtime 表格下設定

[crio.runtime.runtimes.${HANDLER_NAME}]
  runtime_path = "${PATH_TO_BINARY}"

如需更多詳細資訊，請參閱 CRI-O 的 組態文件。

排程

透過為 RuntimeClass 指定 scheduling 欄位，您可以設定約束，以確保使用此 RuntimeClass 執行的 Pod 排程到支援它的節點。如果未設定 scheduling，則假定所有節點都支援此 RuntimeClass。

為了確保 Pod 落在支援特定 RuntimeClass 的節點上，該組節點應具有一個通用標籤，然後由 runtimeclass.scheduling.nodeSelector 欄位選取。RuntimeClass 的 nodeSelector 在准入時會與 Pod 的 nodeSelector 合併，有效地取得每個節點所選取節點集合的交集。如果發生衝突，Pod 將被拒絕。

如果支援的節點被染污 (tainted) 以防止其他 RuntimeClass Pod 在該節點上執行，您可以將 tolerations 新增到 RuntimeClass。與 nodeSelector 相同，容忍度 (tolerations) 在准入時會與 Pod 的容忍度合併，有效地取得每個節點容忍的節點集合的聯集。

若要瞭解更多關於設定節點選取器 (node selector) 和容忍度 (tolerations) 的資訊，請參閱將 Pod 指派給節點。

Pod 額外負擔

您可以指定與執行 Pod 相關聯的額外負荷資源。宣告額外負荷允許叢集（包括排程器）在制定關於 Pod 和資源的決策時將其納入考量。

Pod 額外負荷在 RuntimeClass 中透過 overhead 欄位定義。透過使用此欄位，您可以指定使用此 RuntimeClass 執行 Pod 的額外負荷，並確保 Kubernetes 中會考量這些額外負荷。

下一步

• RuntimeClass 設計
• RuntimeClass 排程設計
• 閱讀關於 Pod 額外負荷 概念
• PodOverhead 功能設計