本文已發布超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
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 Container Engine，我們的商業容器產品) 和 GAE (Google App Engine，我們的平台即服務產品) 中唯一支援的運行時。
雖然我們可能會在未來根據客戶需求在 GKE 中引入 AppC 支援，但我們打算無限期地繼續支援 Docker 計畫和產品，以及 Docker 公司。 迄今為止，Docker 是市場上最成熟且使用最廣泛的容器產品，下載量超過 4 億次。 它已準備好用於生產環境將近一年，並在業界以及 Google 內部得到廣泛使用。
除了 Docker 在市場上顯而易見的吸引力之外，Docker 近期許多開放專案的舉措，以及支援「電池已包含，但堆疊中可更換選項」的做法，並認知到它為容器世界的新手工程師提供了絕佳的開發人員體驗，都令我們感到振奮。 例如，Docker Machine 和 Swarm 專案從核心運行時分離出來，以及看到 Docker Machine 對 Google Compute Engine 的支援正在興起，都讓我們感到欣慰。
我們宣布支援 AppC 和 RKT 的目的是將 Kubernetes（我們的開源專案）確立為容器世界中的中立地帶。 客戶應該能夠完全根據其技術優點選擇容器運行時和格式，並且我們確實認為隨著技術的成熟，AppC 具有一些合理的潛在優點。 不知何故，這被誤解為「a vs b」的選擇，這完全是不實的。 世界幾乎總是因擁有選擇而變得更好，並且不同的工具應該可用於不同的目的，這是非常自然的。
退後一步來看，人們必須認識到 Docker 在普及容器技術並使其人人可存取方面做出了卓越的貢獻。 我們相信 Docker 將繼續為希望使用容器的開發人員帶來絕佳的體驗，並計劃無限期地支持這項技術及其蓬勃發展的社群。 我們，就我們而言， 期待即將到來的 Dockercon，屆時 Brendan Burns（Kubernetes 共同創辦人）將談論 Docker 在現代分散式系統設計中的作用。