本文发表已超过一年。较旧的文章可能包含过时内容。请检查页面信息自发布以来是否已不正确。
Docker、Kubernetes 和 AppC
最近我们在 Kubernetes 这个开源集群管理器中宣布了支持 AppC 和 RKT 的意图，这是一种由 CoreOS 推动、并得到包括 Google 在内的许多公司参与的另一种容器格式。 这一公告引起了惊人的关注，并被解读为 Google 放弃 Docker 转而支持 Appc 的举动。 许多人认为这是 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 在现代分布式系统设计中的作用。