运行时类
Kubernetes v1.20 [稳定]
此页面描述了 RuntimeClass 资源和运行时选择机制。
RuntimeClass 是一种用于选择容器运行时配置的特性。容器运行时配置用于运行 Pod 的容器。
动机
您可以在不同的 Pod 之间设置不同的 RuntimeClass,以在性能和安全之间取得平衡。例如,如果您的工作负载的一部分需要高度的信息安全保障,您可能选择调度这些 Pod 以便它们在使用硬件虚拟化的容器运行时中运行。这样,您将受益于替代运行时的额外隔离,但会以一些额外的开销为代价。
您还可以使用 RuntimeClass 以相同的容器运行时但不同的设置来运行不同的 Pod。
设置
- 配置节点上的 CRI 实现(依赖于运行时)
- 创建相应的 RuntimeClass 资源
1. 配置节点上的 CRI 实现
通过 RuntimeClass 可用的配置依赖于 Container Runtime Interface (CRI) 实现。请参阅您 CRI 实现的相应文档(下方),了解如何进行配置。
注意
默认情况下,RuntimeClass 假设集群中的节点配置一致(这意味着所有节点在容器运行时方面都以相同的方式配置)。要支持异构节点配置,请参阅下方 调度。配置具有相应的 handler
名称,该名称由 RuntimeClass 引用。处理程序必须是有效的 DNS 标签名称。
2. 创建相应的 RuntimeClass 资源
步骤 1 中设置的配置应该都具有关联的 handler
名称,该名称标识配置。对于每个处理程序,创建一个相应的 RuntimeClass 对象。
RuntimeClass 资源目前只有两个重要的字段: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 写入操作(创建/更新/修补/删除)限制为集群管理员。这通常是默认设置。请参阅 授权概述,了解更多详细信息。用法
为集群配置 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
运行时处理程序通过 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 的 配置文档。
调度
Kubernetes v1.16 [测试版]
通过为 RuntimeClass 指定 scheduling
字段,您可以设置约束以确保使用此 RuntimeClass 运行的 Pod 被调度到支持它的节点上。如果未设置 scheduling
,则假定所有节点都支持此 RuntimeClass。
为了确保 Pod 落在支持特定 RuntimeClass 的节点上,该组节点应该具有一个公共标签,然后由 runtimeclass.scheduling.nodeSelector
字段选择。RuntimeClass 的 nodeSelector 在准入时与 Pod 的 nodeSelector 合并,实际上是取两者选择的节点集的交集。如果存在冲突,则该 Pod 将被拒绝。
如果支持的节点被污染以防止其他 RuntimeClass Pod 在该节点上运行,则可以向 RuntimeClass 添加 tolerations
。与 nodeSelector
一样,容忍度在准入时与 Pod 的容忍度合并,实际上是取两者容忍的节点集的并集。
要了解有关配置节点选择器和容忍度的更多信息,请参阅 将 Pod 分配到节点。
Pod 开销
Kubernetes v1.24 [稳定]
您可以指定与运行 Pod 相关的 _开销_ 资源。声明开销允许集群(包括调度器)在做出有关 Pod 和资源的决策时考虑它。
Pod 开销在 RuntimeClass 中通过 overhead
字段定义。通过使用此字段,您可以指定使用此 RuntimeClass 运行 Pod 的开销,并确保 Kubernetes 在资源分配中考虑到这些开销。