Kubernetes 演進史（上）：Borg、編排之戰與 Docker

⭐️精選
Aa

2014 年 6 月 6 日，一份包含 250 個檔案、47,501 行程式碼的首筆 commit 被正式推上 GitHub。四天之後，Google 雲端副總裁 Eric Brewer 站在 DockerCon 2014 的主題演講舞台上，向全世界公開介紹了名為 Kubernetes 的開源專案。

十年之後，它成為公認的「雲端作業系統」。根據官方 DevStats 十週年統計，專案累積超過 88,000 名貢獻者、來自 8,000 多家企業，CNCF（雲端原生運算基金會）生態系更壯大至約兩百個專案與數百萬名雲原生工程師。

上篇聚焦於 Kubernetes 如何走到這個位置：Google 為何願意把 Borg 的經驗做成開源專案、它如何在三年內擊敗 Mesos 與 Swarm，以及它與 Docker 從互相拉抬到分道揚鑣的過程。

一、2013 年夏天：一個被內部拒絕的提案

故事從一位產品經理的焦慮開始。

2013 年夏天，時任 Google 產品經理、後來名列 Kubernetes 共同創辦人的 Craig McLuckie 在起源回顧中提到，他當時注意到一個棘手現象：Google Compute Engine（GCE）的客戶「租了大量 CPU，實際用到的卻很少」，主因在於他們在雲端上運作的是傳統虛擬機（VM）。

當時 Google 內部早已全面採用容器技術，深知容器具備「可擴充、高可攜性、極致利用硬體」的特性。但對外市場上，業界欠缺一套成熟的大規模容器管理平台。

這項焦慮的深層背景是雲端市場的嚴峻失衡。AWS 比 Google 早數年佈局，全球企業工作負載正加速湧入。Google 若僅靠價格戰或模仿功能難以翻盤；但若能將「容器比虛擬機更能榨乾硬體」建立為產業新標準，Google 就能以自身最擅長的大規模基礎設施營運能力，發動一場關鍵打擊。

換言之，Kubernetes 從誕生首日就是一件商業戰略武器。

然而，Google 內部那套歷經十年淬鍊的管理系統名叫 Borg，是公司內部最核心的技術資產。Borg 自 2000 年代中期起投入生產環境，在多個動輒上萬台機器的叢集上管理數十萬個工作任務，並透過長時間混合部署不同優先等級的任務，將資料中心資源使用率推升至業界罕見水準。

當 McLuckie 首次在內部提案將這套體系做成外部開源版本時，遭遇了極為直白的反對：

「所以讓我確認一下。你想把 Borg 排程器做成對外版本——我們最重要的競爭優勢之一，一個我們連對外都不談的東西。然後，你還想把它開源？」

這份提案在初期確實遭到否決。轉機最終發生在一次日常接駁車的通勤路上：McLuckie 成功說服了副總裁 Eric Brewer（CAP 定理的提出者），隨後獲技術基礎設施最高主管 Urs Hölzle 批准放行。

二、Project Seven of Nine：命名、致敬與架構傳承

專案最初的內部代號為 Project Seven of Nine，取自科幻影集《星際爭霸戰》（Star Trek）的角色「九之七」。劇中的博格（Borg）是會同化其他種族的集體意識，九之七原是被同化的人類，後來脫離集體、成為主角群的夥伴。

Google 的內部系統正好也叫 Borg，Kubernetes 就是那個走出 Google、對外界友善的 Borg。

這份致敬也體現在產品視覺上：Kubernetes 的 Logo 是一個七根輻條的舵輪，名稱則取自希臘文 κυβερνήτης（舵手），社群簡稱為 K8s。

 Heritage from Borg and Omega to Kubernetes

 +-------------------------+  +-------------------------+
 | Borg (2000s)            |  | Omega (Research)        |
 | Scale proof of concept  |  | Shared state store      |
 | Monolithic controller   |  | Decentralized control   |
 +-------------------------+  +-------------------------+
              |                            |
              v                            v
 +------------------------------------------------------+
 | Kubernetes (Clean-room rewrite in Go)                |
 | Declarative API + Independent reconciliation loops   |
 +------------------------------------------------------+

這裡必須釐清一項流傳甚廣的常見誤解：Kubernetes 並非 Borg 的 Go 語言重寫版本。

開源首日釋出的 47,501 行程式碼，來自一份全新撰寫的獨立程式碼庫，沒有任何一行 Borg 原始程式碼被直接搬移。正如 Google 團隊在 ACM 論文《Borg, Omega, and Kubernetes》中所總結，專案真正繼承的是十五年的架構經驗教訓：

這兩者的實踐總結，共同奠定了 Kubernetes「宣告式 API 與調和迴圈（Reconciliation Loop）」的核心基石：使用者只需宣告系統的「期望狀態（Desired State）」，後端多個獨立控制器便會持續監聽，自主將叢集的「實際狀態（Actual State）」調和至期望狀態。

這套架構由共同創辦人 Joe Beda、Brendan Burns、Craig McLuckie 與 Google 核心工程團隊合力催生，為後續的開源擴充奠定了標準。

⭐️三、把 Borg 的經驗送出去，Google 能得到什麼？

一開始的反對意見很合理：Borg 是 Google 最重要的競爭優勢之一，為什麼要把它的設計思想交給所有人，包括對手？

答案取決於 Google 想在哪個戰場競爭。

原本的戰場，Google 只能追著跑。 2013 年的雲端競爭停在「租虛擬機」這一層。AWS 已領先多年，客戶的系統建立在 EC2、ELB 等 AWS 專屬服務上，搬家成本極高。在這一層比價格、比功能，客戶綁得越深，領先者就越穩。

Kubernetes 在雲端上方加了一層不屬於任何雲的抽象。 應用改跑在 K8s 上之後，客戶面對的是 K8s API，底下是哪一家雲變得次要：

新的這一層，由最懂它的人定義。 K8s 的設計繼承自 Borg 與 Omega，最知道怎麼把它跑好的正是 Google。容器能把機器塞得更滿，而大規模基礎設施的營運效率本來就是 Google 的本業；戰場移到這裡，前面提到的「榨乾硬體」優勢才發揮得出來。

時間上 Google 也搶先一步：GKE（Google 的 Kubernetes 託管服務）在 2015 年正式上線，AWS 的 EKS 要到 2017 年底才發表。

開源則是這套策略成立的前提。 如果 K8s 是 Google 專屬產品，客戶只是從 AWS 鎖定換成 Google 鎖定，沒有人會買單；唯有開源，AWS 以外的廠商才願意一起推動。

時機也不等人。2013 至 2014 年間，Docker 以現象級的速度席捲開發者社群；Brendan Burns 事後回顧，Docker 的爆紅讓團隊堅信「一套開源的容器編排系統必然會在市場上出現」。

這個標準若不由 Google 定義，就會由 Docker 公司或 Apache Mesos 陣營建立。Google 樂見 Docker 定義單機容器格式，但多機編排與叢集管理的定義權必須握在自己手上。

事後來看，這一招確實改寫了遊戲規則：K8s 成為業界標準，AWS 最終也推出 EKS 全面接納。但 Google Cloud 並未因此翻身，AWS 至今仍居雲端市場龍頭。Google 換到的，是擺脫結構性劣勢，以及標準制定者的影響力。

四、編排之戰（2014–2017）：陣營對決與勝負關鍵

Kubernetes 開源之際，分散式系統領域已有強勁的競爭陣營。

 Orchestration War: Competing Paradigms (2014–2017)

 +------------------------------------------------------+
 | Apache Mesos + DC/OS (Mesosphere)                    |
 | Veteran enterprise player; massive scale at Twitter  |
 +------------------------------------------------------+

 +------------------------------------------------------+
 | Docker Swarm (Docker Inc.)                           |
 | Zero-config developer UX built into Docker engine    |
 +------------------------------------------------------+

 +------------------------------------------------------+
 | HashiCorp Nomad (HashiCorp)                          |
 | Pragmatic single binary; supports VMs and batch jobs |
 +------------------------------------------------------+

當時的競爭對手各具鮮明優勢：

然而，這場原本預期漫長的比拚，卻在短短三年內分出勝負。Kubernetes 的勝出，繫於三個關鍵優勢：

1. 中立治理打破競爭防線

2015 年 7 月 21 日，Kubernetes 1.0 正式發布，Google 同步宣布將專案捐贈給 Linux 基金會旗下新成立的 CNCF。

Red Hat、IBM、Intel、VMware、Docker 與 CoreOS 均列名創始會員。這一步化解了業界疑慮——專案歸基金會所有，企業投入 K8s 等於建設業界共有的資產，Google 無法獨佔。相較之下，Swarm 與 Mesos 始終無法擺脫單一商業公司的利益綁定。

2. 宣告式 API 與極致擴充能力

Kubernetes 將宣告式模型與自癒控制器作為核心。2017 年（Kubernetes 1.7）引入 CRD（自訂資源定義），徹底打開了擴充大門。第三方開發者不僅能使用平台，更能直接在 K8s 上擴充功能。

早期容器被視為只適合無狀態應用，在容器中管理資料庫需要複雜的人工作業。Helm 成為標準套件管理工具；CoreOS 提出的 Operator 模式，更將資料庫容錯轉移等維運知識寫成程式碼，補齊了企業核心應用的關鍵拼圖。

 API Extensibility: Turning Users into Builders

 +-------------------------------------------------+
 | Kubernetes Declarative Control Plane            |
 +-------------------------------------------------+
              |                         |
              v                         v
 +------------------------+  +---------------------+
 | Helm (Package Manager) |  | Operator SDK & CRDs |
 | Standard app packaging |  | Standard automation |
 +------------------------+  +---------------------+

3. 生態聯盟對決單兵作戰

2017 年成為整個產業的轉折年：

至 2017 年底，容器編排戰爭已無懸念。早期安裝繁瑣的門檻，隨官方安裝工具 kubeadm 的普及大幅降低，大規模節點排程的成熟度也贏得跨廠商信任。

五、輸家的黃昏：三種截然不同的退場軌跡

戰局落幕後，三位競爭對手走向了完全不同的結局：

陣營初始核心優勢應對策略最終格局
Mesosphere (Mesos)早期超大規模驗證、學院派架構改名 D2iQ，轉型 K8s 發行商轉型過慢，2023 年資產出售予 Nutanix
Docker Swarm極致單機體驗、內建零設定官方轉為支援 K8s，Swarm 退居備用仍在維護，但遭 Compose 與輕量 K8s 上下擠壓
HashiCorp Nomad單一執行檔、極簡維運負擔避開正面衝突，專注工具鏈利基保持精簡，2025 年隨母公司併入 IBM

Mesosphere：轉身過慢的產業先驅

曾估值逼近十億美元的 Mesosphere，於 2019 年更名為 D2iQ，試圖轉型為 Kubernetes 發行商。然而市場先行優勢已失，2023 年平台資產出售予 Nutanix。

Docker Swarm：被邊緣化的內建工具

Swarm 至今仍在，只是退居幕後。它的賣點是「比 K8s 簡單」，但這個優勢遭到上下兩端擠壓：單機與本地開發，Docker Compose 一個 YAML 檔就夠用；需要叢集時，k3s、kind 等輕量版 K8s，甚至 Docker Desktop 內建的 K8s 也已經夠簡單，學到的技能還能直接帶進正式環境。

對已經會 K8s 的工程師來說，再學一套 Swarm 略顯多餘。

HashiCorp Nomad：堅守利基的倖存者

Nomad 把自己定位成「免除 K8s 龐大複雜度」的務實方案，並與 Terraform、Vault 等生態工具鏈緊密綁定。Nomad 證明了在標準化戰場落敗後，主動維持精準利基亦能長久生存。

六、Kubernetes 與 Docker：從互相拉抬到分道揚鑣

2013 年 3 月，Docker 在 PyCon 的閃電演講震撼了整個軟體界。接下來兩年是 Docker 的全盛時期：2015 年估值突破十億美元，「Docker」幾乎成了容器的代名詞。

沒有 Docker 點燃的容器革命，就沒有 Kubernetes 誕生的市場土壤。雙方在初期互為放大器：Docker 打造了絕佳的開發者打包體驗，Kubernetes 則提供規模化維運的管理方案。

 The Architectural Decoupling Timeline

 2015-07: Kubernetes 1.0 released with CNCF donation
    |
 2016-12: CRI in K8s 1.5; containerd donation announced
    |
 2020-12: Dockershim deprecation announced in K8s 1.20
    |
 2022-05: Dockershim completely removed in K8s 1.24
    v
 +------------------------------------------------------+
 | Kubelet -> CRI -> containerd / CRI-O -> OCI Runtime  |
 +------------------------------------------------------+

Kubernetes 確立主導地位後，兩者開始解耦。早期 Kubelet 直接呼叫 Docker 常駐程式，靠內建的轉接層 dockershim 維持相容。

2016 年 Kubernetes 1.5 引入 CRI（容器執行時期介面），同月 Docker 宣布把核心元件 containerd 拆出、捐給 CNCF；2020 年 1.20 宣布棄用 dockershim，2022 年 1.24 正式移除。從此 Kubernetes 節點透過 CRI 直接與 containerd 或 CRI-O 通訊，不再需要 Docker 引擎。

NOTE

延伸閱讀：Kubernetes 為什麼移除 Docker？

Docker 公司的核心困境在於商業模式的錯配：它最擅長的開發者體驗極難變現，打算收費的企業級平台層，又被 Kubernetes 這個開源公共財取代。

2019 年 11 月，Docker 將企業業務出售給 Mirantis，重新聚焦於 Docker Hub 與 Docker Desktop。

但若斷言「Docker 徹底落敗」亦非全貌。Docker 輸掉的是成為雲端作業系統的野心，卻牢牢佔據了全世界開發者的日常工作起點。由 Docker 早期主導並捐出的 OCI（開放容器標準） 映像檔格式沿用至今，終端機裡的 docker build 依舊是業界日常。

七、上篇小結

回頭看，Kubernetes 勝出的前提是 Google 願意放手：把專案交給中立基金會，換來整個產業一起推動。

但放手也意味著失去絕對控制權。一個由全球企業共同組成、沒有單一老闆的基金會，究竟該如何治理這套即將承載全世界運算的基礎設施？各大公有雲廠商又將如何展開收編？

這些關於中立王國的治理試驗、複雜度引發的批評聲浪，以及在 AI 浪潮下的全新角色，將在下篇深入探討。

  1. Kubernetes 為什麼移除 Docker？
  2. etcd 入門：Kubernetes 叢集的記憶
  3. Ansible 演進史（上）：Agentless、YAML 與 Red Hat 收購