起初,Kubernetes 只支持运行于 Docker 容器中的 Linux 本地应用。Kubernetes 1.3 中,rtk 为首的其他运行时支持开始逐步浮现,促成了容器运行时(CRI)的诞生,更多的项目也因此加入了这一行列 :Kata Container 和 gVisor 实现了更好的工作负载隔离;Kubernetes 的 Windows 支持也一直在稳步发展。
不同的容器运行时面向不同的使用场景,也就产生了在同一集群中使用混合运行时的需要。但是这所有不同的运行容器的方式都带来了一些亟待处理的问题:
RuntimeClass
为此而来。
RuntimeClass
在 Kubernetes 1.12 中实现,目前为 Alpha 阶段。初始阶段的焦点是提供一个对运行时进行选择的 API,并且为解决其它多运行时方面的问题进行了一些尝试。
RuntimeClass
资源对 Kubernetes 集群上的容器运行时进行了描述。集群安装程序用 RuntimeClass
对运行时进行安装、设置和定义。目前 RuntimeClassSpec
包含一个字段 RuntimeHandler
。运行于节点上的 CRI 会对 RuntimeHandler
进行解释,将其映射为实际的运行时配置。PodSpec
也随之进行了扩展,加入了一个 RuntimeClassName
字段,这个字段的值代表运行该 Pod 所需的 RuntimeClass
的名称。
为什么 RuntimeClass
是个 Pod 级的概念?Kubernetes 资源模型能够在 Pod 中的不同容器之间共享某些资源。如果组成 Pod 的不同容器具有不同的资源模型,会对资源共享造成很大的挑战。例如在不同虚拟机之间共享 loopback
适配器是极其困难的,但是在同一 Pod 中的两个容器之间进行通信时,这是个非常普遍的需要。
要向控制面呈现运行时属性,RuntimeClass
资源是个很重要的基础。例如要在多种不同运行时 Node 组成的集群中实现调度支持,我们可能需要在 RuntimeClass
定义中实现 NodeAffinity。Pod Overhead proposal 在这方面做出了一些早期尝试,和 RuntimeClass
非常匹配,未来会逐步进行跟进。
目前还提出了很多其它的 RuntimeClass
扩展,会逐步进行进一步的研究和开发。正在考虑的扩展包括:
RuntimeClass
。例如指定运行时属性,让系统自行对 RuntimeClass
进行匹配,从而避免显式指定 RuntimeClass
。至少到 2019 年。RuntimeClass
的开发工作都会保持活跃,我们很高兴,从 Kubernetes 1.12 开始,这一功能以 Alpha 的形态成功面世。
作为一个 Alpha 功能,还需要一些额外的设置步骤才能够使用 RuntimeClass
。详情请参考 RuntimeClass 文档。
RuntimeClass Kubernetes ENhancement Proposal 之中包含了更多的设计细节。
Sandbox Isolation Level Decision 一文介绍了将此方案落地到 Pod 级的思考过程。