这篇文章已经一年多了，较旧的文章可能包含过时的内容。请检查从发表以来，页面中的信息是否变得不正确。
作者: Tim Allclair (Google)
Kubernetes 最初是为了支持在 Linux 主机上运行本机应用程序的 Docker 容器而创建的。 从 Kubernetes 1.3 中的 rkt 开始，更多的运行时间开始涌现， 这导致了容器运行时接口（Container Runtime Interface）（CRI）的开发。 从那时起，备用运行时集合越来越大： 为了加强工作负载隔离，Kata Containers 和 gVisor 等项目被发起， 并且 Kubernetes 对 Windows 的支持正在稳步发展。
由于存在诸多针对不同用例的运行时，集群对混合运行时的需求变得明晰起来。 但是，所有这些不同的容器运行方式都带来了一系列新问题要处理：
RuntimeClass 旨在解决这些问题。
最近，RuntimeClass 在 Kubernetes 1.12 中作为 alpha 功能引入。 最初的实现侧重于提供运行时选择 API，并为解决其他未解决的问题铺平道路。
RuntimeClass 资源代表 Kubernetes 集群中支持的容器运行时。 集群制备组件安装、配置和定义支持 RuntimeClass 的具体运行时。 在 RuntimeClassSpec 的当前形式中，只有一个字段，即 RuntimeHandler。 RuntimeHandler 由在节点上运行的 CRI 实现解释，并映射到实际的运行时配置。 同时，PodSpec 被扩展添加了一个新字段 RuntimeClassName，命名应该用于运行 Pod 的 RuntimeClass。
为什么 RuntimeClass 是 Pod 级别的概念？ Kubernetes 资源模型期望 Pod 中的容器之间可以共享某些资源。 如果 Pod 由具有不同资源模型的不同容器组成，支持必要水平的资源共享变得非常具有挑战性。 例如，要跨 VM 边界支持本地回路（localhost）接口非常困难，但这是 Pod 中两个容器之间通信的通用模型。
RuntimeClass 资源是将运行时属性显示到控制平面的重要基础。 例如，要对具有支持不同运行时间的异构节点的集群实施调度程序支持，我们可以在 RuntimeClass 定义中添加 NodeAffinity 条件。 另一个需要解决的领域是管理可变资源需求以运行不同运行时的 Pod。 Pod Overhead 提案是一项较早的尝试，与 RuntimeClass 设计非常吻合，并且可能会进一步推广。
人们还提出了许多其他 RuntimeClass 扩展，随着功能的不断发展和成熟，我们会重新讨论这些提议。 正在考虑的其他扩展包括：
至少要到 2019 年，RuntimeClass 才会得到积极的开发，我们很高兴看到从 Kubernetes 1.12 中的 RuntimeClass alpha 开始，此功能得以形成。