rktlet初长成，rkt CRI带你飞

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

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

当使用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是一个通过gRPC与kubelet通信的守护进程。CRI是kubelet和rktlet通信的接口。CRI主要的方法：
- RunPodSandbox()
- PodSandboxStatus()
- CreateContainer()
- StartContainer()
- StopPodSandbox()
- ListContainers()
- 等等

这些方法可以帮助我们管理生命周期和收集状态。
要创建pod，rktlet使用systemd-run + rkt 命令行调用创建一个临时systemd服务。随后的操作，例如分别向容器添加和移除容器，都是通过调用rkt命令行工具完成的。
以下组件图提供了我们所描述的内容的可视化流程。

想试用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标准。一些仍然需要完成的工作是…
- kubectl附件，
- CRI容器统计，
- 性能改进，
- 更多的与kubernetes v1.8.x相关的测试
- 文档改进

原文链接：Announcing the Initial Release of rktlet, the rkt CRI Implementation（翻译：ds_sky2008）