传统上，Kubernetes容器运行时是绑定到Docker和rkt的。但是在过去数月中，这一情况发生了变化。Kubernetes发布了自己的容器运行时接口（CRI，Container Runtime Interface）API，同时正在完成一个称为CRI-O的实现，力图构建Kubernetes和OCI兼容运行时之间的桥梁。这为Kubernetes以标准方式使用任何OCI兼容容器运行时铺平了道路。
Kubernetes依赖于底层的容器运行时实现生命周期控制，例如Pull、创建、删除等操作。运行时实现为实际的容器，从操作系统层面管理命名空间隔离和资源分配。早期，Docker和rkt是通过非公开的API紧密集成到Kubernetes源代码中的。要添加其它的运行时需要修补源代码，这是非常繁琐的，并且稳定性没有保证。为改进这一问题，在Kubernetes 1.5中以公开发表测试特性的形式引入了CRI。CRI提供了将容器运行时插入Kubernetes系统的通用接口，使用户可以运行kubernetes去编排并扩展他们的非Docker和非rkt架构。运行时也可以是runv这样的基于容器的Hypervisor。

开放容器联盟（OCI，Open Container Initiative）是一个为标准化容器格式和运行时而组建的工业界联盟，它发布了容器运行时标准“runtime-spec”。当前该标准的实现包括runc、HyperHQ的runv 以及一种基于Intel Clear Containers的实现。CRI-O项目是由Project Atomic/RedHat所启动的，还包括其它来自工业界的贡献者。它使用OCI兼容的运行时实现Kubernetes CRI API，这意味着任何OCI兼容的运行时都可以通过Kubernetes的CRI API插入到Kubernetes中，而不必对每个运行时分别实现一个CRI适配器。

当前，Kubernetes的CRI具有如下实现：

CRI-O：符合OCI的运行时； rktlet：rkt容器运行时； Frakti：一种基于Hypervisor的容器运行时； Docker CRI shim：支持Docker直接充当CRI适配器。

在Kubernetes部署中，Kubelet（在Kubernetes中称为Minion）是在每台主机上的本地代理，与容器运行时进行通信。使用CRI后，Kubelet可以通过gRPC（一种开源的RPC框架）与CRI垫片（Shim）通信，其前端调用实际的运行时。Pod是Kubernetes中的最小部署单元，其概念已经扩展为一个具有类似语义的概念，称为PodSandbox。对于基于Hypervisor的运行时，PodSandbox可理解成一个虚拟机。对于Docker等运行时，PodSandbox可理解为Linux命名空间。

本文转自d1net（转载）