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

Tenxcloud · · 1348 次点击 · 开始浏览    置顶
这是一个创建于 的主题,其中的信息可能已经有所发展或是发生改变。

![alt 文本]( http://blog.tenxcloud.com/wp-content/uploads/2016/10/1918-steam-engine.jpg) 开源项目 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 ”将以不同的方式被支持。 未来在编排领域,我们会看到一个激烈竞争的市场,而不是容器引擎领域。 本文由[时速云][1]翻译,如若转载,需注明转载自“[时速云][1]” 原文链接: http://thenewstack.io/cri-o-make-kubernetes-center-container-ecosystem/ [1]:https://www.tenxcloud.com/ —————————————————————————————————————————————————— ◆◆◆ **对文章内容有什么建议的小伙伴,欢迎留言~** ◆◆◆

有疑问加站长微信联系(非本文作者)

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

1348 次点击  
加入收藏 微博
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传