功能狀態：Kubernetes v1.14 beta
該部分描述 RuntimeClass 資源和運行時選擇機制。
RuntimeClass 是用於選擇容器運行時配置的功能。容器運行時配置用於運行 Pod 的容器。
動機
我們可以在不同的 Pod 之間設置不同的 RuntimeClass，以實現性能與安全性之間的平衡。例如，如果我們的部分工作負載應得到高級別的信息安全保證，則可以選擇調度這些 Pod，以便它們在使用硬件虛擬化的容器運行時中運行。然後，我們將受益於備用運行時的額外隔離，但要一些額外的開銷。
我們還可以使用 RuntimeClass 在相同的容器運行時但不同的設置來運行不同的 Pod
搭建
確保啓用了 RuntimeClass 特性門控（敬請期待～～）（默認情況下是的）。有關啓用特性門控的說明，請參見特性門控。必須在 apiserver 和 kubelet 上啓用 RuntimeClass 特性門控。
1. 節點上配置 CRI 實現
通過 RuntimeClass 可用的配置取決於容器運行時接口（CRI）實現。有關如何配置的信息，請參見 CRI 實現的響應文檔（如下（敬請期待～～））。
注意：默認情況下，RuntimeClass 假設整個集羣上的節點配置均勻（這意味着所有節點在容器運行時方面的配置方式均相同）。要支持異構節點配置，請參閱下面的調度。
這些配置具有一個相應的 handler 名稱，由 RuntimeClass 引用。句柄必須是有效的 DNS 1123 標籤（字母數字 + - 字符）。
2. 創建相應的 RuntimeClass 資源
步驟 1 中的配置設置應分別具有一個關聯的 handler 名稱，該名稱標識配置。對於每個句柄，創建一個相應的 RuntimeClass 對象。
當前，RuntimeClass 資源只有兩個重要字段：RuntimeClass 名稱（metadata.name）和句柄（handler）。對象定義如下所示：
apiVersion: node.k8s.io/v1beta1 # RuntimeClass is defined in the node.k8s.io API group
kind: RuntimeClass
metadata:
name: myclass # The name the RuntimeClass will be referenced by
# RuntimeClass is a non-namespaced resource
handler: myconfiguration # The name of the corresponding CRI configuration
RuntimeClass 對象的名稱必須是有效的 DNS 子域名（敬請期待～～）。
注意：建議將 RuntimeClass 寫入操作（創建/更新/布丁/刪除）限制爲集羣管理員。這通常是默認設置。有關更多詳細信息，請參見授權概述（敬請期待～～）。
用法
一旦爲集羣配置了 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 安裝（敬請期待～～）。
dockershim
Kubernetes 內置的 dockershim CRI 不支持運行時句柄。
containerd
通過 /etc/containerd/config.toml 中容器的配置來配置運行時句柄。有效的句柄配置在運行時部分下：
[plugins.cri.containerd.runtimes.${HANDLER_NAME}]
有關更多詳細信息，請參見容器的配置文檔：https://github.com/containerd/cri/blob/master/docs/config.md
CRI-O
運行時句柄是通過 CRI-O 的配置在 /etc/crio/crio.conf 中進行配置的。有效的句柄在 crio.runtime 表下配置：
[crio.runtime.runtimes.${HANDLER_NAME}]
runtime_path = "${PATH_TO_BINARY}"
有關更多詳細信息，請參見 CRI-O 的配置文檔。
調度
特性狀態：Kubernetes v1.16 beta
從 Kubernetes v1.16 開始，RuntimeClass 通過其 scheduling 字段包括對異構集羣的支持。通過使用這些字段，可以確保將與該 RuntimeClass 一起運行的 Pod 調度到支持它的節點上。要使用計劃支持，我們必須啓用 RuntimeClass 准入控制器（敬請期待～～）（默認值爲 1.16）。
爲確保 Pod 落在支持特定 RuntimeClass 的節點上，該節點集羣應具有一個公共標籤，然後由 runtimeclass.scheduling.nodeSelector 字段選擇該標籤。允許時將 RuntimeClass 的 nodeSelector 與 pod 的 nodeSelector 合併，有效地獲取每個節點選擇的節點集的交集。如果有衝突，則將拒絕該 pod。
如果對受支持的節點進行了污染以防止其它 RuntimeClass 容器在該節點上運行，則可以向 RuntimeClass 添加容錯。與 nodeSelector 一樣，容錯在接納時與 pod 的容錯合併，從而有效地吸收了每個節點可容忍的節點集的並集。
要了解有關配置節點選擇器和容錯的更多信息，請參閱將 Pod 分配給節點（敬請期待～～）。
特性狀態：Kubernetes v1.18 beta
我們可以指定與運行 Pod 相關的開銷資源。聲明開銷允許集羣（包括調度）在做出有關 Pod 和資源的決策時對其進行說明。要使用 Pod 開銷，必須啓用 PodOverhead 特性門控（敬請期待～～）（默認情況下處於啓用狀態）。
Pod 的開銷是在 RuntimeClass 中通過 overhead 字段定義的。通過使用這些字段，我們可以使用該 RuntimeClass 指定運行的 Pod 的開銷，並確保在 Kubernetes 中考慮了這些開銷。
下一步怎麼做
- RuntimeClass 設計
- RuntimeClass 調度設計
- 閱讀有關 Pod Overhead 的概念
- PodOverhead 特性設計