RuntimeClass

RuntimeClass是一个让Pod选择容器运行时的一个特性，用于多运行时环境。

可以在不同的 Pod 设置不同的 RuntimeClass，以提供性能与安全性之间的平衡。 例如，如果你的部分工作负载需要高级别的信息安全保证，你可以决定在调度这些 Pod 时尽量使它们在使用硬件虚拟化的容器运行时中运行。 这样，你将从这些不同运行时所提供的额外隔离中获益，代价是一些额外的开销。

RuntimeClass 需求来源

容器运行时的演进过程，整个过程大致分为三个阶段：

  • 第一个阶段：2014 年 6 月，Kubernetes 正式开源，Docker 是当时唯一的、也是默认的容器运行时；
  • 第二个阶段：Kubernetes v1.3，rkt 合入 Kubernetes 主干，成为了第二个容器运行时。
  • 第三个阶段：Kubernetes v1.5，Kubernetes 推出 CRI 出现了 kata、gVisor等实现了 CRI 的容器运行时

此同时，越来越多的容器运行时也想接入到 Kubernetes 中。如果还是按 rkt 和 Docker 一样内置支持的话，会给 Kubernetes 的代码维护和质量保障带来严重挑战。

1.5 版本时推出了 CRI，它的全称是 Container Runtime Interface。这样做的好处是：实现了运行时和 Kubernetes 的解耦，社区不必再为各种运行时做适配工作，也不用担心运行时和 Kubernetes 迭代周期不一致所带来的版本维护问题。比较典型的，比如 containerd 中的 cri-plugin 就实现了 CRI、kata-containers、gVisor 这样的容器运行时只需要对接 containerd 就可以了。

随着越来越多的容器运行时的出现，不同的容器运行时也有不同的需求场景，于是就有了多容器运行时的需求。