运行时类

本页面描述 RuntimeClass 资源和运行时选择机制。

RuntimeClass 是一个用于选择容器运行时配置的特性。容器运行时配置用于运行 Pod 中的容器。

动机

你可以在不同的 Pod 之间设置不同的 RuntimeClass，以在性能和安全性之间取得平衡。例如，如果你的部分工作负载需要高度的信息安全保证，你可以选择调度这些 Pod，使其运行在使用硬件虚拟化的容器运行时中。这样你就可以从替代运行时的额外隔离中获益，尽管会付出一些额外的开销。

你也可以使用 RuntimeClass 在同一个容器运行时中运行不同的 Pod，但使用不同的设置。

安装设置

1. 在节点上配置 CRI 实现（取决于运行时）
2. 创建对应的 RuntimeClass 资源

1. 在节点上配置 CRI 实现

通过 RuntimeClass 可用的配置取决于 Container Runtime Interface (CRI) 实现。请参阅你的 CRI 实现对应的文档（下方）了解如何配置。

配置有一个对应的 handler 名称，RuntimeClass 会引用它。该 handler 必须是有效的DNS 标签名称。

2. 创建对应的 RuntimeClass 资源

步骤 1 中设置的每个配置都应该有一个关联的 handler 名称，用于标识该配置。对于每个 handler，创建一个对应的 RuntimeClass 对象。

RuntimeClass 资源当前只有两个重要的字段：RuntimeClass 名称（metadata.name）和 handler（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 子域名。

使用方法

在集群配置好 RuntimeClass 之后，你可以在 Pod 的规约中指定 runtimeClassName 来使用它。例如：

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

这将指示 kubelet 使用指定的 RuntimeClass 来运行此 Pod。如果指定的 RuntimeClass 不存在，或者 CRI 无法运行相应的 handler，则 Pod 将进入 Failed 终止阶段。请查找相应的事件以获取错误消息。

如果未指定 runtimeClassName，将使用默认的 RuntimeHandler，这相当于禁用 RuntimeClass 特性时的行为。

CRI 配置

有关设置 CRI 运行时的更多详细信息，请参阅CRI 安装。

containerd

Runtime handler 通过位于 /etc/containerd/config.toml 的 containerd 配置文件进行配置。有效的 handler 配置在 runtimes 部分下：

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

有关更多详细信息，请参阅 containerd 的配置文档。

CRI-O

Runtime handler 通过位于 /etc/crio/crio.conf 的 CRI-O 配置文件进行配置。有效的 handler 配置在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 将被拒绝。

如果支持的节点被设置了污点（taint），以阻止其他 RuntimeClass Pod 运行在该节点上，你可以向 RuntimeClass 添加 tolerations。与 nodeSelector 一样，tolerations 在准入时与 Pod 的 tolerations 合并，实际上是取两者容忍的节点集合的并集。

要了解有关配置节点选择器和容忍度的更多信息，请参阅将 Pod 分配给节点。

Pod 开销

你可以指定与运行 Pod 相关联的 overhead 资源。声明 overhead 允许集群（包括调度器）在决定 Pod 和资源时将其考虑在内。

Pod overhead 通过 RuntimeClass 中的 overhead 字段定义。通过使用此字段，你可以指定利用此 RuntimeClass 运行 Pod 的开销，并确保这些开销在 Kubernetes 中得到计算。

接下来

• RuntimeClass 设计
• RuntimeClass 调度设计
• 阅读有关Pod Overhead 概念的信息
• PodOverhead 特性设计