运行时类

此页面介绍了 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 配置进行配置。有效的处理程序在运行时部分下进行配置

[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 在节点上运行，则可以将 tolerations 添加到 RuntimeClass。与 nodeSelector 一样，tolerations 会在准入时与 Pod 的 tolerations 合并，实际上取每个容忍的节点集的并集。

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

Pod 开销

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

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

接下来

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