Docker和rkt快别争了，k8s才是容器生态的中心

开源项目 CRI-O ，其前身为 OCID ，官方简介是“ OCI-based implementation of Kubernetes Container Runtime Interface ”。做为接口，它使得 Kubernetes 不依赖于传统的容器引擎（好比 Docker ），也可以管理容器化工做负载。

该项目经过与 Kubernetes （或其商业版 CoreOS Tectonic ）协做，能够帮助 DevOps 人员来管理容器的整个“生命周期”。

开发人员须要使用容器引擎构建镜像，一般状况下更喜欢用本身的 staging 环境作本地测试。可是管理和运营人员会发现，相对于标准容器引擎， Kubernetes 技术栈（好比编排系统、 CRI 和 CRI-O ）更适合用来管理复杂的生产环境。

该项目将编排工具放在容器技术栈的重要位置，同时下降了容器引擎的重要性。 CRI 的一个 Contributor 说，让 Kubernetes 支持任意容器引擎，在理念上与 Open Container Initiative 一脉相承。容器引擎能够是 docker 或 CoreOS 的 rkt ，或 OCI 的 runc （它能够作不少如 Docker 或 CoreOS rkt 这类容器能够作的事情，好比从 registry 拉镜像，但它不会从 makefile 构建镜像）。

CRI-O 是什么？

「 尽管 Open Container Initiative 相似的部分已经与 CRI-O 的职责区别愈来愈大，两个项目的成员、贡献者和厂商也有很大重合，但 CRI-O 仍然是 OCI 的天然延伸，它为容器引擎和镜像提供了一套标准接口。」， Kubernetes 工程师 Kelsey Hightower 在 The New Stack 的采访中说道。

CRI-O 项目的设想是用户不该该依赖任何特定的容器引擎去完成工做负载。按照最初的设想，该项目将为 Kubernetes 提供一个工具集，使其可以管理容器的整个生命周期，而不须要 Docker 、 rkt 、 OpenShift 、 Photon 或任何其余容器引擎。

「 咱们对容器引擎的功能要求不多，不论是 Docker 仍是 rkt ，它们要作的工做都不多 」， Hightower 说，「 咱们须要的是访问内核的 API ，不只仅针对 Linux ，也能够是 Windows 。若是这是社区想要去的方向， Kubernetes 就要支持这些想法-由于在这一点上它比 Docker 公司更大 」。

在这一假设之下，是一个新奇的观点：编排才是容器生态的中心，而“引擎”就咱们所知，只是一个开发工具。

另外一方面， CRI （通用容器接口 API 和 Kubernetes ）将给容器引擎厂商一个机会，以便接入 Kubernetes 系统。运行容器的环境中，只要暴露出适当的链接，不须要容器引擎进行代码重构就能够兼容 Kubernetes 。

其中一个方式是，在容器引擎和编排工具中间实现一个抽象层，容器厂商如何实现这一层彻底取决于他们本身。

容器引擎中间层实现之后， CRI API （与 Kubernetes 链接的部分）将把更多的容器生命周期控制权交给 kubelet —— pod 的管理者。 Pod 是 Kubernetes 特有的概念，但容器生态系统必须采用这个概念。

对于 Kubernetes ，下一个版本的目标是 1.5 版本，包括 CRI 的最终版，容许 kubelet 与 Docker ， rkt 、 Hyper.sh （中国团队开发）以及 CRI-O （ RedHat 领导开发）进行通讯。

“关于如何与 Kubernetes 通讯，不少不一样的容器引擎都很是感兴趣”， Philips 说，“与其在 kubelet 中为每个容器引擎构建一个接口，咱们创造了一个更抽象的接口，容许容器引擎去接入而不用直接参与 Kubernetes 的工做。”

谁须要重构，重构什么？

Hightower 将 CRI （“ CRI ”在“ CRI-O ”以前）描述为一个抽象的概念，表明容器引擎应该支持的基本特性，而 Kubernetes 能够用来验证这些特性。一旦 CRI 完成，将重构 Kubernetes 代码以实现 CRI 。

若是 CRI-O 成功，容器引擎厂商不须要对引擎代码库进行修改，就能够简单地与 Kubernetes 交互。

“如今，若是你想很 happy 地玩耍 Kubernetes ，必须构建一堆东西，并且可能修改你目前的作事方式”， Hightower 说，“你查看现有的代码库，看看为 Docker 作了哪些东西。在某种程度上，你须要付出相似的努力，去修改适合你的运行时引擎，从而与 Kubernetes 很好的配合。”

就像 CoreOS 的 Philips 解释的同样，每一个容器引擎将利用一个中间层—— 它可以将容器引擎的 API 请求，转化成 Kubernetes 能够处理的形式。

“考虑到 CRI 的运行机制，你须要一个 GRPC daemon 去监听请求”， Philips 说，“它能与 kubelet 通讯；反过来， kubelet 能够经过 socket 对实现 CRI 的引擎发送一个远程调用”。

Philips 说，“目前对 Docker 和 rkt 的支持将被合并到 CRI 接口”。 CoreOS rkt 对 CRI 的实现目前已经在 Github 上开源，项目名称为 rktlet 。不论是 rktlet ，仍是 Docker 对 CRI 的实现（无论未来叫什么名字），他预计都被重构为 CRI 。

Google 的 Hightower 说：“尽管 Docker 已经要求与 Kubernetes 一块儿实现中间层，最终仍然是 Google 的工程师去实现，而不是 Docker 的。 Philips 也表示，无论谁去实现中间层， Docker 和其它容器引擎厂商遵循一样的规则，都不能搞特权。

“为了与 CRI 集成， Docker Engine 和 rkt Engine 都处在不断变化中”， Brandon Philips 如是说。

OCI 镜像格式的最终标准尚未肯定， OCI 发言人也代表 OCI 镜像格式 1.0 发布以前还有两个迭代版本。

同时， Docker 在不断加强其容器引擎的特性，而且捆绑了 Swarm 编排工具和服务发现。

“我认为这一切进展都不错，” Philips 说，“人们可能不喜欢这样——这很正常，每一个人均可以有本身的观点。对于 Kubernetes ，咱们仍然会提供一包东西。但咱们在创造和改进它时，不认为它仅仅是一件商品（还有情怀）。

超越 Kubernetes

“前面咱们谈到 Pod ，为了正确地实现它，你还须要了解不少东西”， Hightower 说，“把负担推给容器引擎，让它们去写一拖代码才能与 kubernetes 愉快地玩耍，这一点对于每一个容器引擎都很不公平。想一想看：他们还要为 Mesos 和 Swarm 去实现相似功能的代码，想一想均可怕。为了简化这部分功能，咱们将把 Kubernetes 专属的逻辑放到 kubelet 中；对于外部而言，经过一种友好的方式使用容器引擎原本就具有的特性。

假设这已是事实，现有容器引擎特性被隐藏在一个接口后面，该接口可以将 pod 为中心基于 kubelet 的逻辑从 kubernetes 隔离出来，与 Kubernetes 以外但有一样 API 的编排工具交互，这个编排工具对 API 可能有一套彻底不一样的实现方式（饼愈来愈大）。

咱们和 Mesosphere 创始人 Ben Hindman 也探讨了这种可能性。

“我认为这个行业须要的是可拼凑的组件”， Hindman 对 The New Stack 解释说。“在 Kubernetes 案例中，我认为这很关键。 Kubernetes 依靠 Docker 作容器管理，而且他们尝试构建编排。当 Docker 整合 Swarm 时，他们不只有一个容器管理器，也在作编排。仅仅从架构的角度来看，这是很是合理的。我想说的是：若是咱们只作一个容器管理的组件，让不少人能够利用，岂不是很更好？”

对于 Docker 公司有意向将 runc 做为开放标准， Hindman 很是认同，但他也不忘吐槽：完整的编排不只仅是与与容器引擎交互。

“还有不少，好比下载镜像、镜像打包、镜像解包 —— 还有更多的事情必须去作。

对我来讲，我认为行业中还在就一个问题争论：这些东西应不该该被分解和模块化？它不只仅是 fork the repo 那么简单，还须要在架构上解释得通。”[ Ben Hindman ]。

Mesosphere 的 DC/OS 环境中也有这些组件作铺垫， Hindman 解释说，已经无需依赖 runc 或任何 Docker 组件。容器社区的真正目标，正如他所说的，是在组件之间指定架构层面上的边界，并创建它们之间创建适当的接口。

这是否意味着 Mesosphere 支持 CRI-O ， CRI-O 的目标也如 Kelsey Hightower 向咱们解释的同样，与 Hindman 预计的彻底兼容吗？

然而 Hindman 并非为 OCI 呐喊，须要注意的是， Mesosphere 是 OCI 的创始成员之一。 OCI 的最初的目的是开发一种通用的运行时格式，让 runc 可以以容器的方式启动它。容器社区也关心镜像格式，包括容器在非运行状态下的文件系统和元数据。因此 OCI 也接受这套理念。

“对于咱们而言，镜像格式比运行时格式更有趣，也有意义” ， Hindman 说，“ Mesosphere 之因此拥抱 universal containerizer ，缘由是但愿支持全部开放格式的容器，包括 OCI 。”

但在这样一个最佳架构中，可能没有方法去规范工做负载的调度器。不一样调度器的特性可能千差万别。所以，若是以这种方式，努力经过一个文件描述工做负载（多是配置文件、元数据文件或 manifest 文件），而且试图对全部调度器通用，最终制定出来的标准可能知足不了任何调度器的需求，进而妨碍调度器自己特性的扩展。

可是，肯定一个通用镜像格式则简单不少，最终取决于 Linux 是否支持该格式。“若是支持它，咱们能够公开它。在镜像格式上，我认为没有太大的争论，所以，把它做为一个标准就 OK 。”

Hindman 总结说， Mesosphere 将继续支持 OCI ，未来会以一样的粒度支持 CRI-O 。但跟 CRI-O 相比， Mesosphere 的“ universal container runtime ”将以不一样的方式被支持。

将来在编排领域，咱们会看到一个激烈竞争的市场，而不是容器引擎领域。

本文由时速云翻译，如若转载，需注明转载自“时速云”

原文连接： http://thenewstack.io/cri-o-m...

——————————————————————————————————————————————————

◆◆◆ 对文章内容有什么建议的小伙伴，欢迎留言~ ◆◆◆