这篇文章已经超过一年了。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。
Docker 和 Kubernetes 以及 AppC
最近，我们宣布了在 Kubernetes（我们的开源集群管理器）中支持 AppC 和 RKT 的意图，这是一种由 CoreOS 在多家公司（包括 Google）的投入下推动的替代容器格式。 此公告引起了令人惊讶的轰动，并被解读为 Google 支持 Appc 而非 Docker 的举动。 许多人认为这是 Google 正在放弃支持 Docker 的信号。 我想花点时间澄清 Google 在这方面的立场。
Google 一直支持 Docker 计划，并在 Docker 上投入了大量资金。 在容器的早期阶段，我们决定弱化我们自己的开源产品 (LMCTFY)，而是专注于 Docker。 因此，我们有两名工程师是 LibContainer（Docker 生态系统的关键部分）的活跃维护者，并与 Docker 密切合作，以添加许多其他特性和功能。 Docker 目前是 GKE（Google 容器引擎）我们的商业容器产品和 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 在现代分布式系统设计中的作用。