功能状态: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 特性设计