CoreOS和Docker分别要将rkt和containerd捐赠给CNCF

今天（3月15日）CoreOS和Docker联合提议将rkt和containerd作为新项目纳入CNCF（云原生计算基金会）。在今天CNCF的技术监管协会（Technical Oversight Commitee，或TOC）会议上，Jonathan Boulle，一名rkt的项目领导人兼共同发起人，提议了rkt；Michael Crosby，一名containerd项目领导人兼共同发起人，提议了contanerd。这些提议是让这些项目和其他关键项目共同发展的第一步，这些项目包括gRPC、Kubernetes、Prometheus和很多其他项目。通过将这些项目捐献给CNCF，我们保证容器社区继续在一个中立的归属下齐心协力。

容器执行是云原生的一个至关重要的支柱，并且我们相信rkt将会持续在CNCF社区的帮助下进步并壮大。rkt有180多名来自多元化的背景的贡献者，已经帮助建立并且推进很多关于容器安全，组合性和协作性的对话。现在，行业中已经有一部分致力于容器安全，而像CNCF这样的机构能促进对话，并最终让更多的公司吸收、推动并受益于云原生基础设施。

我们期待在接下来的数天和数周里，和rkt和CNCF社区一起完成接下来的步骤。如果你有兴趣了解最新进展，可以订阅这个邮件列表（https://groups.google.com/forum/#!forum/rkt-dev）。

rkt为什么加入CNCF

云原生计算的一个支柱是将应用打包成容器镜像，然后把这些镜像分发到服务器。在服务器上，容器引擎会下载镜像，验证镜像的完整性，然后执行容器进程。理想的状态是，容器引擎使用最简单的方式来实现这个过程，同事满足生产环境中云原生用户的需求。rkt工具就像一束激光，集中于解决这些问题，其成果已经受到了市场的欢迎，并促进了它和一些云原生编排系统如Kubernetes、Mesos、Nomad和很多机构的内部定制系统集成。

自从它被CoreOS在2014年12月发布以来，rkt项目已经高度成熟并被广泛使用。在绝大多数的主流Linux发行版中都能找到，并且每一个rkt的发布版都会构建用户可以直接安装的自包含rpm/deb安装包。这些软件包也能在Kubernetes仓库中找到，作为该仓库的一部分，便于测试rkt和Kubernetes的集成。同时，在Google Container Image和CoreOS Container Linux运行Kubernetes中，rkt也扮演了中心的作用。

同时，rkt项目也间接推进了容器生态系统中很多新的重要API，规范和讨论。CNI，被Mesos、Kubernetes、rkt和其他项目使用的容器网络插件系统，就直接来源于最初的rkt插件系统并且已经汇聚了来自多家机构和整个行业的努力。rkt的团队也创建了appc，即App Container Spec，发起了一场行业内的关于容器标准的讨论，并且最终产生了OCI，即Open Container Initiative。正在进行的将Kubernetes打造成一个支持多容器运行时的系统起源于早期在”rktnetes”方面的工作，其已经促使了Container Runtime Interface API在Kubernetes内诞生。在所有的这些场景中，rkt项目都扮演共享生态环境中协作的催化剂。

总得说来，容器执行是云原生的一个核心部分。通过将rkt放到CNCF下的提议，我们能得到如下的益处：

• 为项目找到一个中立的、受尊敬的归属
• 伴随来自社区的努力和投入，能得到更多的帮助
• 加速和Kubernetes、OCI和containerd的合作

rkt现状和未来

感谢社区让rkt走到今天这一步。很多公司，如BlaBlaCar，一家欧洲有名的汽车共享服务商，他们正在生产环境中使用rkt并且正向Kubernetes迁移，并分享了他们在生产坏境中使用rkt的经验。社区中的其他成员也说：

来自@coreoslinux的rkt是真正值得关注的东西，https://t.co/UYeOVX0CUz

不得不说，CoreOS的rkt有着很好的设计

请继续使用rkt并且提出反馈，分享你们使用rkt的故事。你可以在我们的rkt的users和integration文档页面添加你的pull request。

FAQ

Q：今天这意味着什么？

现在rkt和containerd的提议已经提交后，下一步是等待CNCF TOC成员来支持并提议项目的加入。到了这一步后，项目会向上推进，进入一个正式的提议阶段，然后继续往上在接下来几周里接受投票。

而对于专门负责rkt的项目组来说，并没有什么大的不同。所有rkt的其他maintainer会一如往常的继续项目上的工作。同时，我们希望在CNCF的帮助下，能催生新的用户和维护者，一起推动并且依赖rkt。

Q：containerd和rkt的不同之处是什么？

rkt能下载、验证并且配置好容器镜像；而containerd也能完成同样的事情。同时，两个项目都支持OCI镜像和Docker镜像。

一个主要的不同之处是，rkt作为一个无守护进程的工具（daemonless tool），可以用来在生产环境中，集成和执行那些特别的有关键用途的容器。举个例子，CoreOS Container Linux使用rkt来以一个容器镜像的方式执行Kubernetes的agent，即kublet。更多的例子包括在Kubernetes生态环境中，使用rkt来用一种容器化的方式挂载volume。这也意味着rkt能被集成进并和Linux的init系统一起使用，因为rkt自己并不是一个init系统。

Q：对于构建容器的开发者来说意味着什么？

对于需要构建容器的开发者来说，一切照常，因为containerd和rkt的目标都是要让用户能够执行他们已有的OCI镜像和Docker镜像。

对于在生产环境中部署容器的基础设施专家群体来说，这意味着rkt团队和项目会以CNCF的一部分，在一个中立的机构下，继续它的使命，即创建一个简单、可组合、生产环境可用的容器化系统。

我们同时也迫切想看到在rkt项目中和其他CNCF生态环境项目，如Kubernetes，gRPC和Prometheus的协作。

Q：所有的这些容器引擎都可以通过Kubernetes CRI使用吗？

CoreOS帮助建立了一个标准的接口，叫做Kubernetes Runtime Interface（Kubernetes运行时接口，CRI），能让Kubernetes使用一些可插拔的容器运行时引擎。rkt已经可以通过CRI使用（一个调用实例请参考minikube项目的使用说明，https://github.com/kubernetes/minikube#using-rkt-container-engine）。