本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
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 在現代分散式系統設計中的作用。