在过去的几个月里，Kubernetes传统的连接到Docker和rkt作为容器运行时间发生了变化。 Kubernetes已经发布了其容器运行时接口(CRI)API，并且有一个并行的正在进行的实现称为CRI-O，它试图在Kubernetes和符合OCI的运行时之间创建一个桥梁。 这为Kubernetes以标准方式使用任何符合OCI的容器运行时铺平了道路。

Kubernetes依赖底层容器运行时进行容器生命周期控制操作，如拉动、创建、删除等。 运行时是管理操作系统级别的命名空间隔离和资源分配的实际容器实现。 早些时候，Docker和rkt都通过非公共API紧密地集成到Kubernetes源代码中。 添加另一个运行时很麻烦，需要修改源代码，而不能保证稳定性。 在Kubernetes1.5中引入了作为alpha特性的容器运行时接口(CRI旨在改变这一点。 该CRI公开了一个公共接口，允许容器运行时插入Kubernetes系统，允许用户运行Kubernetes来编排和扩展他们的非Docker和非rkt基础设施。 运行时也可以是基于容器的管理程序，如runv。

开放容器倡议(O CI)是一个为规范容器格式和运行时间而形成的行业论坛，它发布了运行时规范作为容器运行时间的标准。 目前的实现包括RUNC，Hyper HQ的RUNV和一个基于英特尔的透明容器。 由Project Atomic/Red Hat和来自该行业的其他贡献者启动的CRI-O项目使用符合OCI的运行时间实现Kubernetes CRIAPI。 这意味着任何符合OCI的运行时都可以通过后者的CRIAPI插入Kubernetes，而不是必须为它们中的每一个实现CRI适配器。

Kubernetes的CRI目前有以下实现：

形象礼貌：http://blog.kubernetes.io/2016/12/container-runtime-interface-cri-in-kubernetes.html 在Kubernetes部署中，Kubelet是与容器运行时对话的每个主机(或Kubernetes中的minion)的本地代理。 使用CRI，Kubelet将通过gRPC(开源RPC框架)与CRI-Shim通信，后者前端调用实际运行时。 在Kubernetes中，Pod是最小的部署单位，它的概念已经扩展到一个名为Pod Sandbox的概念，保持了相似的语义。 这可能会转换为基于hypvis or的运行时的虚拟机，以及像Docker这样的运行时的Linux命名空间。