Kubernetes 演進史（下）：中立王國的治理、雲廠商的收編與 AI 時代

2015 年 7 月 21 日，Kubernetes 1.0 在波特蘭 OSCON 大會正式發布。就在同一天，Google 做出關鍵宣告：將 Kubernetes 的商標與專案資產完整捐給 Linux Foundation 旗下新成立的 Cloud Native Computing Foundation（CNCF）。

這一步在當時常被解讀為開源情懷或行銷姿態；但回顧十年歷程，這項決定是歷史上最關鍵的戰略棋步，將「誰的編排器」這場零和爭奪，轉化為「大家的編排器」。

上篇探討了 Kubernetes 如何在三年編排戰爭中勝出；下篇聚焦於「贏了之後」的演進史：一個沒有老闆的社群如何治理全球雲端標準、雲端巨頭如何從抵抗轉為收編、十年間未曾中斷的複雜性批判與退場辯證，以及 2023 年後 AI 工作負載帶來的新變局。

一、捐贈的政治學：CNCF 與中立化的智慧

要看清這場捐贈的戰略意圖，關鍵在於搞清楚：Google 究竟放棄了什麼，又換取了什麼？

表面上看，Google 放棄了專案的實質所有權——商標、智慧財產權與治理路徑全數移交基金會；但實際上，Google 藉此買到了整個軟體產業的無保留參與。

在編排戰爭的白熱化階段，中立性正是定海神針。AWS 決定推出 EKS、微軟決定將核心工程團隊全面投入、Docker 最終選擇將 K8s 整合進自家桌面端，其核心前提都在於：他們投資的專案不再屬於任何直接競爭對手。

Google 用一個開源專案的所有權，換取了整個容器生態對其架構體系的路徑依賴；而這份依賴最終歸屬於中立基金會，連 Google 自己都不再享有特權。

CNCF 隨後發展為 Linux Foundation 旗下擴張速度最迅猛的組織。Kubernetes 作為創始專案，於 2018 年 3 月 6 日成為首個通過審查正式宣布畢業的專案，標誌其生產就緒度、治理成熟度與採納規模皆達業界標竿。

根據官方 DevStats 十週年統計，CNCF 生態系已擴充至約兩百個專案，觸及超過 24 萬名貢獻者與 700 萬名以上開發者。

中立化的代價與機制深深銘刻於細節之中。商標移交後，連 Google 自身的 GKE 都必須嚴格遵從社群發布節奏，無法單方面定義技術規格。

取而代之的是 CNCF 技術監督委員會（TOC）與一致性認證計畫（Certified Kubernetes Conformance）。任何雲廠商若想使用 Kubernetes 商標，就必須通過同一套端對端相容性測試。

這套認證成為開源史上的經典設計：它將「相容」轉化為必備的品質標章，同時將「分裂分叉」（forking）轉化為商業上無利可圖的選項。

二、沒有老闆的治理實驗：SIG、KEP 與發布文化

將專案捐給基金會解決了法律所有權問題，但內部協作隨即面臨核心考驗：當主要貢獻者來自彼此激烈競爭的跨國企業時，日常決策該如何運轉？

Kubernetes 的解答是一套三層組織架構：

 Kubernetes Three-Tier Governance Structure

 +--------------------------------------------------------+
 | Steering Committee (7 Members, Annual Community Vote)  |
 | Governs charter, conflicts, and SIG leadership         |
 +--------------------------------------------------------+
                            |
                            v
 +--------------------------------------------------------+
 | SIGs (Special Interest Groups: Network, Node, etc.)    |
 | Domain-driven collaboration, public meetings & notes   |
 +--------------------------------------------------------+
                            |
                            v
 +--------------------------------------------------------+
 | KEP Process (Kubernetes Enhancement Proposals)         |
 | Motivation -> Risk Analysis -> Test Plan -> GA         |
 +--------------------------------------------------------+

第一層是 Steering Committee：治理提案於 2017 年定案，在 Sarah Novotny、Brendan Burns 等跨企業領袖組成的創始治理委員會推動下，於 2017 年 10 月完成首次社群選舉，正式確立了社群民選制度。

委員會專注於制定社群規範、協調衝突與監督選舉，恪守「治理者也要被治理」的原則，絕不干預具體技術架構。

第二層是 SIG（Special Interest Group）：將專案拆分為網路、儲存、排程、節點、發布等數十個專業領域。所有 SIG 會議全程公開、紀錄公開，工程師的協作歸屬於領域專業，而非受僱的企業。

第三層則是 KEP（Kubernetes Enhancement Proposal）：於 2018 年初正式制度化。專案中的任何重大功能或架構異動，皆必須撰寫包含動機、替代方案、風險評估與漸進測試計畫的提案文件，經 SIG 嚴格審查後方能進入程式碼庫。

發布工程則體現了這套制度的另一面。早年每季一版的節奏令全球維護者與使用者疲於奔命；自 2020 年 1.19 版將支援週期延長至一年後，2021 年 4 月起正式改採一年三版的發布週期。

每個版本由數十位志工透過嚴格的 Shadow（影子）實習制度接力輪值，確保治理與工程經驗代代傳承。

這套去中心化治理推動了數次極具挑戰性的核心架構重構與標準化：

• 1.13 版（2018 年 12 月）：將 kubeadm 與 CSI 儲存介面推向 GA，並將 CoreDNS 設為預設 DNS。
• 1.22 版（2021 年 8 月）：全面廢止大量長期使用的 beta API，重塑 API 生命週期規範。
• 1.24 版（2022 年 5 月）：將內建的 Docker 相容層 dockershim 自 kubelet 徹底移除。
• 1.31 版（2024 年 8 月）：完成歷時多年的 in-tree（內建於核心程式碼庫）雲端供應商程式碼剝離——移除了約 150 萬行專屬整合程式碼，使核心二進位檔縮小近 40%。

這場龐大的架構大掃除，正是將「中立性」從口號落實為乾淨程式碼的具體見證。

三、雲廠商的收編：從抵抗到「Kubernetes 即服務」

商業戰線上，隨之迎來一場科技史上罕見的「大收編運動」。

Google 率先起跑：2015 年推出 Google Container Engine，2017 年更名為 Google Kubernetes Engine（GKE），使 K8s 正式成為雲端產品名稱。

Red Hat 則採取了最徹底的轉向：早在 2015 年 6 月，Red Hat 就將原本採傳統 PaaS 架構的 OpenShift 3 推倒重來，完全重構於 Kubernetes 與 Docker 之上；隨後在 2019 年推出的 OpenShift 4，更使其成為完整的企業級 K8s 平台。

微軟於 2017 年 10 月推出 Azure Kubernetes Service（AKS）；AWS 則在經歷社群質疑後，於 2017 年 11 月 re:Invent 大會宣布 Amazon EKS，並於 2018 年 6 月 5 日正式 GA。至此，三大公有雲巨頭全數完成託管平台的佈局。

緊接著是一波橫掃基礎設施領域的併購潮：Kubernetes 共同創辦人 Joe Beda 與 Craig McLuckie 於 2016 年創立的 Heptio，在 2018 年底由 VMware 閃電收購，隨後整合 Pivotal 推出 Tanzu 產品線；而多叢集管理先驅 Rancher Labs 則在 2020 年併入 SUSE。

大廠之間形成明確的商業共識：不再耗費心力另起爐灶自研編排標準，而是轉為收購能在 Kubernetes 之上創造價值的創新生態。

至此，Kubernetes 演變成雲端世界的「PCI 匯流排」——沒有任何單一廠商能藉由掌控它獲取壟斷暴利，但所有巨頭皆依賴它相互制衡。

社群活動的擴張印證了這股浪潮：2015 年 11 月舊金山首屆 KubeCon 僅有數百人與會；到了 2019 年北美聖地牙哥大會已湧入近 12,000 人，2023 年歐洲阿姆斯特丹大會亦突破 10,500 人。從內部討論到萬人級產業嘉年華，Kubernetes 坐穩了雲端基礎設施的主流地位。

四、採用的現實：數字裡的真相與口徑

解讀技術採用資料時必須格外謹慎，因為統計口徑往往決定了截然不同的結論。

在 CNCF 2023 年度的全球調查中，有 84% 的受訪組織表示「正在使用或評估」Kubernetes，而明確表示「已在生產環境運作」的比例則為 66%；到了 2024 年調查，生產環境採納比例進一步攀升至約 80%。

許多媒體報導常將「84%」直接簡化為「84% 企業在生產中運作 K8s」，這顯然混淆了「評估中」與「實際上線」之間將近 20 個百分點的差距。

 CNCF Survey Adoption Metrics (Disambiguation)

 2023 Survey:
 [======================== 84% Total ===================]
 [============== 66% Production ==============] [18% Eval]

 2024 Survey:
 [======================== ~80% Production =============]

然而，即便是採用 66% 至 80% 的嚴格窄口徑，也說明了一件產業現狀：Kubernetes 已不再是一項需要反覆評估的技術選項，而是現代基礎設施的預設背景。

2024 年 DORA 報告亦指出，高達 89% 的受訪組織已導入某種內部開發平台（Internal Developer Platform, IDP），而這些平台絕大多數正是架構在 Kubernetes 之上；同份報告也提醒，平台化與組織績效之間的關係遠比想像中複雜。

當一項技術成為公用事業般的底層協定，批評它就像批評 TCP/IP 一樣無濟於事：聽者往往深有同感地點頭，然後轉身繼續把工作負載部署上去。

五、批評之聲與退場敘事：帝國的裂縫

十年統治之下，對 Kubernetes 的批評與反思從未停歇。梳理這些聲音，主要集中於三個層面：

1. 本質複雜性與抽象代價

學習曲線陡峭、YAML 設定檔過度膨脹、除錯鏈條漫長——這些質疑自 1.0 時代延續至今，且多數切中要害。

連 CNCF 官方部落格都在 2023 年直言「儲存系統極為複雜」。

最典型的案例是 Ingress 資源：1.0 時代僅定義了陽春的 L7 HTTP 路由規格。當系統需要 Header 匹配、權重分流或金絲雀發布等進階能力時，各家控制器只能塞入大量自訂註解（annotations）方言，破壞了跨雲可攜性。

社群最終耗費數年重新設計出 Gateway API（2023 年正式發布 1.0 GA），才將流量管理標準逐步收斂。

然而複雜度的另一面是：這大半是為了兌現「在所有基礎設施上行為一致」所支付的工程代價。

2. 「K8s 是起點，不是終局」

前 Google 知名開發者布道師 Kelsey Hightower 於 2017 年 11 月 27 日留下一段廣為引用的名言：

Kubernetes is a platform for building platforms. It’s a better place to start; not the endgame.

意思是：Kubernetes 是用來建構平台的平台——它是更好的起點，而不是終局。

這句論斷深刻啟發了後來的「平台工程」思潮：企業不應強迫應用開發者直接暴露在 Pod、CRD 與複雜網路規則中，而應在 K8s 之上包裝出符合內部工作流程的抽象層。

這段話表面上指出了原生的不足，實質上卻進一步鞏固了 Kubernetes 作為雲端地基的不可替代性。

3. 退場敘事與雲端回遷辨析

近年最受矚目的反叛案例，莫過於 37signals（Basecamp 與 HEY 母公司）於 2022 年底宣布並於 2023 年完成的「退雲運動」。

由 DHH 主導的這場遷移，將全部負載自公有雲遷回自建裸機伺服器，使每年的雲端支出從約 320 萬美元大幅縮減至 130 萬美元。37signals 在裸機上並未採用 Kubernetes，而是自研輕量級開源部署工具 Kamal 直接管理容器。

然而必須釐清技術邊界：37signals 退出的對象是公有雲高昂租賃與溢價體系，而非否定容器編排的價值。

業界確實存在的「退出 Kubernetes」案例，多集中於規模尚未大到需要 Kubernetes、卻導入複雜叢集的團隊；這是早期技術選擇錯配後的務實修正，而非基礎設施標準的動搖。

六、AI 時代：新的王冠與新的戰場

進入 2023 年後，生成式 AI 的爆發為這個專案翻開了全新篇章：Kubernetes 正迅速成為大型 AI 運算基礎設施的事實底座。

背後的架構契機十分清晰：現代 AI 訓練與推論叢集的核心需求——異質硬體排程（GPU、TPU）、複雜批次工作生命週期與彈性資源拓撲——本就是 Kubernetes 控制平面的拿手好戲。

開源社群與巨頭在極短時間內組建了完整的 AI 原生排程矩陣：

 Kubernetes Modern AI Workload Ecosystem

 +------------------------------------------------------+
 | Workload Layer: PyTorch, Ray, vLLM, Training & LLMs  |
 +------------------------------------------------------+
                            |
                            v
 +------------------------------------------------------+
 | Orchestration & Serving: Kueue, Volcano, KServe      |
 +------------------------------------------------------+
                            |
                            v
 +------------------------------------------------------+
 | Kubernetes Core: Job API, DRA (Dynamic Resources)    |
 +------------------------------------------------------+
                            |
                            v
 +------------------------------------------------------+
 | Driver & Hardware Layer: NVIDIA GPU Operator, ASICs  |
 +------------------------------------------------------+

• Kueue：提供進階階層式佇列、彈性配額與公平共享機制，成為多團隊共享昂貴 GPU 叢集的主流方案。
• Volcano：針對分散式 AI 訓練補足關鍵的 All-or-Nothing（Gang Scheduling）排程能力，確保多節點同時就位才啟動，避免個別節點卡住部分 GPU 造成死結與昂貴算力閒置。
• KubeRay：將 Ray 分散式運算框架深度整合至 K8s 生態。
• KServe：提供高度標準化的模型推論服務介面（於 2025 年正式加入 CNCF 成為 Incubating 專案）。
• NVIDIA GPU Operator：直接將底層 GPU 驅動程式、Container Toolkit 與監控指標封裝為 Kubernetes 原生自訂資源（CRD）。

歷史在 2025 年迎來呼應：2025 年 11 月 11 日的 KubeCon Atlanta 大會上，CNCF 正式發表 Certified Kubernetes AI Conformance 認證計畫。

如同 2015 年藉由一致性認證化解容器分裂危機，AI 運算生態再次透過九項社群基準，讓「AI 工作負載跨雲跨硬體的可攜性」成為認證標準。首批通過認證的平台包括 Gardener、OpenShift 與 RKE2 等。

十年前，Kubernetes 排程的單位是輕量 Web Pod；十年後，排程對象已變成造價數十萬美元的高效能 GPU 運算節點。

排程資源的價值翻了數個數量級，而底層核心的宣告式哲學，一字未改。

七、流傳敘事核查清單

為釐清社群多年流傳的歷史細節，本系列將關鍵查核結論集中整理如下：

八、結語：一連串非必然的決策

回望十年軌跡，後人常為 Kubernetes 的成功冠上「技術必然性」光環——彷彿它只是因為架構優越而理所當然地贏下一切。

但歷史的真實切面，卻是由一連串充滿風險、甚至違反商業直覺的非必然抉擇所造就：

• 一位 Google 產品經理在接駁車上促成專案誕生的冒險遊說；
• 一場看似自斷壟斷優勢的慷慨開源捐贈；
• 一套看似繁瑣厚重、卻極致公平透明的跨企業治理架構；
• 一種將競爭對手全數拉進同一個牌局的收編智慧。

技術架構固然重要，但決定 Kubernetes 能夠統治十年的核心力量，始終是開放治理與商業結構的深層平衡。

對於每天編寫 YAML、除錯調和迴圈（Reconciliation Loop）與部署 Operator 的當代工程師而言，理解這段歷史的價值在於明白：我們指尖呼叫的每一個 API 與宣告式語法，都不只是純粹的程式碼，也是整個開源社群歷經十年角力、妥協與演進累積下來的制度結晶。