Kubernetes 1.12 中的 RuntimeClass
原文：Kubernetes v1.12: Introducing RuntimeClass
起初，Kubernetes 只支持运行于 Docker 容器中的 Linux 本地应用。Kubernetes 1.3 中，rtk 为首的其他运行时支持开始逐步浮现，促成了容器运行时（CRI）的诞生，更多的项目也因此加入了这一行列 ：Kata Container 和 gVisor 实现了更好的工作负载隔离；Kubernetes 的 Windows 支持也一直在稳步发展。
不同的容器运行时面向不同的使用场景，也就产生了在同一集群中使用混合运行时的需要。但是这所有不同的运行容器的方式都带来了一些亟待处理的问题：
- 用户如何列出、并为工作负载选定合适的运行时？
- 如何保证让 Pod 被调度到支持指定运行时的节点上？
- 各种运行时都支持什么样的特性？如何让用户了解到这其中的兼容问题？
- 多种运行时的不同资源开销如何应对？
RuntimeClass 为此而来。
Kubernetes 1.12 中的 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 扩展，会逐步进行进一步的研究和开发。正在考虑的扩展包括：
- 呈现容器运行时所支持的可选特性，并为不兼容功能引发的错误提供更好的展示。
- 将运行时的功能发现过程进行自动化，从而为自动的调度决策提供支持。
- 提供运行时的自动注册功能，这样用户就可以在不停机的情况下为现有集群中安装新的运行时。
- 为 Pod 的需求提供合适的
RuntimeClass。例如指定运行时属性，让系统自行对RuntimeClass进行匹配，从而避免显式指定RuntimeClass。
至少到 2019 年。RuntimeClass 的开发工作都会保持活跃，我们很高兴，从 Kubernetes 1.12 开始，这一功能以 Alpha 的形态成功面世。
还有更多
作为一个 Alpha 功能，还需要一些额外的设置步骤才能够使用 RuntimeClass。详情请参考 RuntimeClass 文档。
RuntimeClass Kubernetes ENhancement Proposal 之中包含了更多的设计细节。
Sandbox Isolation Level Decision 一文介绍了将此方案落地到 Pod 级的思考过程。