本文发布时间超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。

Kubernetes v1.12：引入 RuntimeClass

作者：Tim Allclair (Google) |

Kubernetes 最初发布时支持在 Linux 主机上运行本地应用程序的 Docker 容器。从 Kubernetes 1.3 中的 rkt 开始，出现了更多的运行时，这导致了 容器运行时接口 (CRI) 的开发。自那时以来，替代运行时的集合不断扩大：诸如 Kata Containers 和 gVisor 之类的项目被发布，以实现更强大的工作负载隔离，并且 Kubernetes 的 Windows 支持一直在 稳步发展。

由于运行时针对如此多的不同用例，集群中出现了对混合运行时的明确需求。但是，所有这些不同的运行容器的方式都带来了一系列新的问题需要处理

  • 用户如何知道哪些运行时可用，并为其工作负载选择运行时？
  • 我们如何确保将 Pod 调度到支持所需运行时的节点？
  • 哪些运行时支持哪些功能，我们如何向用户展示不兼容性？
  • 我们如何考虑运行时不同的资源开销？

RuntimeClass 旨在解决这些问题。

Kubernetes 1.12 中的 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 资源是将运行时属性呈现给控制平面的重要基础。例如，为了实现对支持不同运行时的异构节点的集群的调度器支持，我们可能会将 NodeAffinity 术语添加到 RuntimeClass 定义中。另一个需要解决的领域是管理运行不同运行时 Pod 的可变资源需求。Pod Overhead 提案 是对此的早期尝试，它与 RuntimeClass 设计非常一致，并且可能会进一步推进。

还提出了许多其他 RuntimeClass 扩展，并且将随着该功能的不断开发和成熟而重新审视。正在考虑的一些其他扩展包括

  • 呈现运行时支持的可选功能，并更好地了解由不兼容的功能引起的错误。
  • 自动运行时或功能发现，以支持无需手动配置的调度决策。
  • 标准或一致的 RuntimeClass 名称，这些名称定义了一组属性，这些属性应在具有相同名称 RuntimeClass 的集群中得到支持。
  • 动态注册其他运行时，以便用户可以在现有集群上安装新的运行时，而不会停机。
  • 将 RuntimeClass “适配” 到 Pod 的需求。例如，指定运行时属性，并让系统匹配适当的 RuntimeClass，而不是按名称显式分配 RuntimeClass。

RuntimeClass 至少将在 2019 年持续活跃开发，我们很高兴看到该功能成形，从 Kubernetes 1.12 中的 RuntimeClass alpha 开始。

了解更多信息