本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
Docker、Kubernetes 和 AppC
最近我们宣布了 Kubernetes（我们的开源集群管理器）支持 AppC 和 RKT 的意图，AppC 和 RKT 是 CoreOS 在许多公司（包括 Google）的投入下推出的一种替代容器格式。这项声明引起了令人惊讶的关注，并被解读为 Google 优先支持 Appc 而非 Docker 的举动。许多人将其视为 Google 正在放弃支持 Docker 的信号。我想花点时间澄清 Google 在此方面的立场。
Google 一直支持 Docker 倡议，并对 Docker 投入了大量资金。在容器早期，我们决定弱化我们自己的开源产品 (LMCTFY)，转而专注于 Docker。因此，我们有两名工程师是 LibContainer 的活跃维护者，LibContainer 是 Docker 生态系统中的关键组成部分，我们正与 Docker 密切合作，以增加许多额外的特性和功能。Docker 目前是 GKE (Google Container Engine)（我们的商业容器产品）和 GAE (Google App Engine)（我们的平台即服务产品）中唯一支持的运行时。
虽然我们将来可能会根据客户需求在 GKE 中引入 AppC 支持，但我们打算无限期地继续支持 Docker 项目和产品，以及 Docker 公司。迄今为止，Docker 是市场上最成熟、使用最广泛的容器产品，下载量超过 4 亿次。它已经投入生产近一年，并在行业中（包括 Google 内部）得到广泛使用。
除了 Docker 在市场上明显的吸引力之外，我们还对 Docker 最近的许多举措感到鼓舞，这些举措旨在开放项目并支持“自带电池但可在整个堆栈中互换选项”，并认识到它为容器世界的新工程师提供了出色的开发体验。例如，我们对 Docker Machine 和 Swarm 项目从核心运行时中分离感到鼓舞，并且很高兴看到 Google Compute Engine 开始支持 Docker Machine。
我们宣布支持 AppC 和 RKT 的目的是将 Kubernetes（我们的开源项目）确立为容器世界中的中立地带。客户应该能够纯粹根据其技术优点来选择他们的容器运行时和格式，我们确实认为 AppC 在技术成熟后会提供一些合法的潜在优点。不知何故，这被错误地解读为“A 与 B”的选择，这根本不正确。拥有选择通常会使世界变得更好，不同的工具可用于不同的目的，这是非常自然的。
退一步讲，我们必须认识到 Docker 在使容器技术民主化并使其人人可用方面做出了卓越的贡献。我们相信 Docker 将继续为希望使用容器的开发人员带来出色的体验，并计划无限期地支持这项技术及其蓬勃发展的社区。例如，我们期待即将举行的 Dockercon 大会，届时 Brendan Burns（Kubernetes 的联合创始人之一）将谈论 Docker 在现代分布式系统设计中的作用。