运行时类

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

RuntimeClass 是用于选择容器运行时配置的功能。容器运行时配置用于运行 Pod 的容器。

动机

你可以在不同的 Pod 之间设置不同的 RuntimeClass，以提供性能与安全性之间的平衡。例如，如果你的工作负载的某些部分需要高水平的信息安全保证，你可能会选择调度这些 Pod，以便它们在使用硬件虚拟化的容器运行时中运行。然后，你将从替代运行时的额外隔离中受益，但会牺牲一些额外的开销。

你还可以使用 RuntimeClass 来使用相同的容器运行时但使用不同的设置来运行不同的 Pod。

设置

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 子域名称。

用法

为集群配置 RuntimeClass 后，你可以在 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

运行时处理程序在 /etc/containerd/config.toml 的 containerd 配置中进行配置。有效的处理程序在 runtimes 部分下配置

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

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

CRI-O

运行时处理程序在 /etc/crio/crio.conf 的 CRI-O 配置中进行配置。有效的处理程序在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。

如果支持的节点被污染以防止其他 RuntimeClass Pod 在该节点上运行，则可以向 RuntimeClass 添加 tolerations。与 nodeSelector 一样，tolerations 在准入中与 Pod 的 tolerations 合并，从而有效地取每个节点容忍的节点集的并集。

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

Pod 开销

你可以指定与运行 Pod 相关的开销资源。声明开销允许集群（包括调度器）在对 Pod 和资源做出决策时考虑它。

Pod 开销在 RuntimeClass 中通过 overhead 字段定义。通过使用此字段，你可以指定使用此 RuntimeClass 运行 Pod 的开销，并确保 Kubernetes 中考虑了这些开销。

下一步是什么

• RuntimeClass 设计
• RuntimeClass 调度设计
• 阅读有关Pod 开销概念的信息
• PodOverhead 功能设计