为了符合 OCI 标准，Docker 推动自身的架构继续向前演进。首先，它是将 libcontainer 独立出来，封装重构成runC 项目，并捐献给了 Linux 基金会管理
2016 年，Kubernetes 1.5 版本开始引入“容器运行时接口”（Container Runtime Interface，CRI）
Kubernetes Master → kubelet → DockerManager → Docker Engine → containerd → runC
2008年Linux Kernel 2.6.24发布LXC系统级虚拟化功能
从此 Kubernetes 内部的 DockerManager，就被更为通用的 KubeGenericRuntimeManager 所替代了（实际上在 1.6.6 之前都仍然可以看到 DockerManager）
Docker
CRI 是在 Docker 之后才发布的规范，Docker 是肯定不支持 CRI 的，所以 Kubernetes 又提供了 DockerShim 服务作为 Docker 与 CRI 的适配层
Kubernetes Master → kubelet → KubeGenericRuntimeManager → containerd → runC
2016 年，Docker 把 containerd 捐献给了 CNCF 管理
2015 年7 月，Kubernetes 发布了第一个商用版本（1.0）
Kubernetes
2013 年，Pivotal（持有着 Spring Framework 和 Cloud Foundry 的公司）就提出了“云原生”的概念
直到 Kubernetes 1.5 之前，Kubernetes 管理容器的方式都是通过内部的 DockerManager，向 Docker Engine 以 HTTP 方式发送指令，通过 Docker 来操作镜像的增删改查的
2018 年 containerd，在 CNCF 的精心孵化下发布了 1.1 版，1.1 版与 1.0 版的最大区别是此时它已经完美地支持了 CRI 标准，这意味着原本用作 CRI 适配器的 cri-containerd 从此不再被需要
Kubernetes 从 1.10 版本宣布开始支持 containerd 1.1，在调用链中就已经能够完全抹去 Docker Engine 的存在了：
为了能够兼容所有符合标准的 OCI Runtime 实现，Docker 进一步重构了 Docker Daemon 子系统，把其中与运行时交互的部分抽象为了containerd 项目
Kubernetes Master → kubelet → KubeGenericRuntimeManager → DockerShim → Docker Engine → containerd → runC
Kubernetes Master → kubelet → KubeGenericRuntimeManager → CRI-O→ runC
2013 年Docker宣布开源
2015 年，在 Docker 的主导和倡议下，多家公司联合制定了“开放容器交互标准”（Open Container Initiative，OCI）
2017 年，由 Google、RedHat、Intel、SUSE、IBM 联合发起的CRI-O（Container Runtime Interface Orchestrator）项目发布了首个正式版本
