CoreOS的rkt和Docker的containerd一起贡献给了CNCF

blacklion 发布于2月前 阅读900次
0 条评论

今天(三月十五日)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社区一起完成接下来的步骤。如果你有兴趣了解最新进展,可以订阅 这个邮件列表

rkt为什么加入CNCF?

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

自从它被CoreOS在2014年12月发布以来,rkt项目已经高度成熟并被广泛使用。在绝大多数的主流Linux发行版中都能找到,并且每一个rkt的发布版都会构建用户可以直接安装的自包含rpm/deb安装包。这些软件包也能在Kubernetes仓库中找到,作为该仓库的一部分,便于测试rkt和Kubernetes的集成。同时,在 Google Container ImageCoreOS 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的经验。社区中的其他成员也说:

rkt from @coreoslinux is really something to behold. https://t.co/UYeOVX0CUz

— Ben Campbell (@benjic) October 14, 2016

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

I have to say, @coreos' #rkt is very well designed

— Stefano Stabellini (@stabellinist) January 19, 2017

(不得不说,coreos的rkt有着很好的设计)

请继续使用rkt并且提出反馈,分享你们使用rkt的故事。你可以在我们的rkt的 usersintegration 文档页面添加你的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项目的使用说明 )。

(原文链接: CoreOS's rkt and Docker's containerd jointly donated to CNCF ,翻译:钟最龙)

查看原文: CoreOS的rkt和Docker的containerd一起贡献给了CNCF

共收到0条回复

需要 登录 后回复方可回复, 如果你还没有账号你可以 注册 一个帐号。