rktlet初长成,rkt CRI带你飞


【编者的话】本文将和大家一起来看看Docker的老对手rkt推出的新武器(看来是想和Docker在容器生态圈一争高下)。

我们很高兴地宣布rktlet的最初版本——rkt实现了Kubernetes容器运行时接口。这是一个预览版本,不适用于生产工作环境。
rktlet-logo.png

当使用rktlet时,所有的容器工作环境都在rkt容器运行时运行。

关于rkt

rkt容器运行时在容器运行时间中是唯一的,一旦rkt完成设置Pod容器并启动应用程序,就不再有rkt代码运行了。rkt也采取安全第一的方法,除非用户明确禁用安全功能,否则rkt不允许使用不安全的功能。rkt是原生的Pod,能够完美的与Kubernetes的Pods概念相匹配。此外,rkt倾向于将改进集成到现有工具中,而不是重塑事物。最后,rkt允许在各种隔离环境(容器,虚拟机或物理机)中运行应用程序。

rkt在Kubernetes的支持

rktlet的这个最初版本目前有两个Kubernetes实现。在Kubernetes 1.3版本中引入了对Kubernetes的原生rkt支持。这个实现——美其名曰rktnetes——其实就像Kubernetes核心的高仿版。正如rkt自己开始尝试容器标准一样,这个原始的rkt集成也促使Kubernetes引入了一个标准的接口来为其他容器运行时添加支持。这个接口被称为Kubernetes容器运行时接口(CRI)。

通过Kubernetes CRI,容器运行时有一种简单高效的方式与Kubernetes集成。而rktlet是该接口的rkt实现。

项目目标

目标是使rktlet成为在Kubernetes中运行工作环境的首选方法。但是像Blablacar这样的公司依靠Kubernetes内部的rkt实现来运行他们的基础架构。因此,我们不能仅仅在没有可行的替代方案的情况下移除这个实现。

rktlet目前通过了145个Kubernetes端到端一致性测试中的129个测试。我们的目标是完全合规。在本文的后面,我们将看看还有什么需要去实现。

一旦rktlet准备好了,我们将计划弃用Kubernetes核心中的rkt实现。

rktlet如何工作

rktlet是一个通过gRPCkubelet通信的守护进程。CRI是kubelet和rktlet通信的接口。CRI主要的方法:
  • RunPodSandbox()
  • PodSandboxStatus()
  • CreateContainer()
  • StartContainer()
  • StopPodSandbox()
  • ListContainers()
  • 等等


这些方法可以帮助我们管理生命周期和收集状态。

要创建Pod,rktlet使用systemd-run + rkt命令行调用创建一个临时systemd服务。随后的操作,例如分别向容器添加和移除容器,都是通过调用rkt命令行工具完成的。

以下组件图提供了我们所描述的内容的可视化流程。
rktlet-interaction.png

想试用rktlet,请按照入门指南

推动rkt发展

rktlet的工作推动了rkt内部的一些新功能开发,我们将花点时间来强调一下。

Pod操作

rkt一直是原生的,但pods本身是不可改变的。原始设计不允许进行诸如启动、停止或向应用程序添加应用程序的操作。而为了符合CRI,这些功能才被添加到rkt。这项工作在应用程序级API文档中进行了详细的描述。

日志和附件

从历史上看,rkt的应用程序已经将日志记录转移到了轻量服务——默认情况下是systemd-journald——将其输出复用到外部世界。轻量服务处理日志记录和交互式应用程序重用父TTY。

但是,CRI定义了明文记录格式,而systemd-journald的输出格式是二进制格式。而且,Kubernetes还有一个附件功能,在旧设计中是无法做到的。

为了解决这些问题,实现了一个叫做iottymux的组件。启用时,它将完全替换systemd-journald;提供格式化为CRI兼容的应用程序日志以及附件功能所需的逻辑。

有关此设计的更详细说明,请查看日志附件设计文档

未来的工作

在准备正式进入生产工作环境之前,rktlet仍然还有很多任务要做,并且需要100%符合CRI标准。一些仍然需要完成的工作是:


原文链接:Announcing the Initial Release of rktlet, the rkt CRI Implementation(翻译:ds_sky2008)

0 个评论

要回复文章请先登录注册