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

20170318101753

今天(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的经验。社区中的其他成员也说:

20170318101734

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

20170318101743

不得不说,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)。

K8S中文社区微信公众号
分享到:更多 ()

评论 抢沙发

评论前必须登录!