Kubernetes 工程師必讀的分散式系統閱讀清單

Kubernetes 工程師必讀的分散式系統閱讀清單

分散式系統對我來說是一門很有趣的學科,也為前人所奠基的基礎創造出來的科學方法驚艷:它把複雜問題拆解成有條理、可驗證的步驟,讓我們能打造在大規模下仍然穩定且高效能的系統。

如果你正在使用 Kubernetes、想從 Google 的 Borg 經驗學習,或在面對 SRE 的維運挑戰,我認為這些奠基論文能提供你需要的理論根基與實務洞見。它們塑造了我們如何在規模下建構與營運分散式系統的思維。這些資源不只適用於軟體開發者、系統工程師或站台可靠性工程師(SRE),任何在分散式系統領域工作的人都能受益。

1. “The Google File System” (2003)

摘要: 本文介紹 GFS,Google 的分散式檔案系統,設計目標是在一般商用硬體上運行,同時為大量用戶端提供高總體效能。它提出把故障視為常態而非例外的設計思維與處理方式。

核心概念: 元件故障是常態、大檔案最佳化、原子性記錄附加操作、寬鬆的一致性模型、Master-Chunk Server 架構。

為什麼要讀: 理解 GFS 能幫助你掌握 Kubernetes 持久化卷等系統背後的儲存基礎。它在一致性與可用性之間的設計取捨,直接對應到容器平台的儲存編排。

2. “MapReduce: Simplified Data Processing on Large Clusters” (2004)

摘要: MapReduce 提出一種程式設計模型,讓你在叢集中以平行、分散式演算法處理大型資料集。它把平行化、容錯與負載平衡的複雜度隱藏起來。

核心概念: Map/Reduce 函式、自動平行化、透過重新執行達到容錯、資料就地性最佳化、主從架構。

為什麼要讀: 雖然 Kubernetes 不直接跑 MapReduce 工作,但了解這種計算模型有助於你設計批次工作負載與任務調度。資源排程與故障復原的原則正是 Kubernetes 管理工作負載的基礎。

3. “Bigtable: A Distributed Storage System for Structured Data” (2006)

摘要: Bigtable 是 Google 用於大規模管理結構化資料的分散式儲存系統。它提供稀疏、分散、持久化的多維排序映射,可擴展到跨數千台機器的 PB 級規模。

核心概念: Column-family 儲存模型、Tablet Server、分散式鎖服務(Chubby)、Bloom filter、Compaction 策略、SSTable 檔案格式。

為什麼要讀: Bigtable 的架構影響了 Kubernetes 上的現代有狀態應用。理解它如何處理資料分佈、複寫與一致性,有助於你以 StatefulSet 運行資料庫,或管理 etcd(儲存 Kubernetes 叢集狀態)。

4. “The Chubby Lock Service for Loosely-Coupled Distributed Systems” (2006)

摘要: Chubby 是 Google 的分散式鎖服務,提供粗粒度鎖與少量資料的可靠儲存。它的設計目標是在可靠且高可用的前提下提供分散式共識。

核心概念: 透過 Paxos 的分散式共識(consensus)、鎖服務與共識函式庫的取捨、建議性鎖(advisory locks)、事件通知、Leader-election。

為什麼要讀: Kubernetes 使用 etcd(基於 Raft,與 Paxos 類似)來做協調與共識。理解 Chubby 的設計決策,有助於你看懂 Kubernetes 如何實作 Leader election、服務發現與分散式設定管理。

5. “Large-scale cluster management at Google with Borg” (2015)

摘要: 這篇是 Borg 的權威論文。Borg 是 Google 的叢集管理系統,可在多個叢集上運行數十萬個工作。Borg 是 Kubernetes 的前身,兩者共享許多架構概念。

核心概念: Job/Task 模型、Borgmaster 與 Borglet 架構、資源分配(CPU、記憶體)、優先級與配額系統、bin packing、任務搶占、命名與服務發現。

為什麼要讀: 這是所有 Kubernetes 相關工作者的必讀。你會在 Pod、ReplicaSet、Namespace 與控制平面架構等概念上看見直接脈絡。理解 Borg 的經驗教訓(成功與遺憾)能為 Kubernetes 的設計決策提供極重要的脈絡。

6. “Borg, Omega, and Kubernetes” (2016)

摘要: 這篇論文追溯了 Borg 到 Omega(實驗性叢集排程器)再到 Kubernetes 的演進,並說明學到的教訓如何影響 Kubernetes 的開源設計。

核心概念: 以容器為中心的基礎設施、宣告式設定、調和(reconciliation)迴圈、共享狀態架構演進、API 驅動設計、重視生態系勝於單體。

為什麼要讀: 這篇文章連結了 Google 內部系統與你今天使用的開源 Kubernetes。它解釋 Kubernetes 為何如此運作,並幫助你理解其設計選擇背後的理念,讓你成為更有效率的操作者。

7. “Site Reliability Engineering” Book - Chapters 1-6 (2016)

摘要: Google SRE 一書的前幾章建立了 SRE 的核心原則:把維運當成軟體問題、承擔風險、定義 SLI/SLO/SLA,以及消除 toil(重複且低價值工作)。

核心概念: SRE 與 DevOps、容錯預算(Error Budget)、服務水準指標/目標/協議(SLI/SLO/SLA)、toil 的定義與消除、監控與告警哲學。

為什麼要讀: 維運 Kubernetes 叢集需要卓越的營運能力。這些章節教你用可量化的方式思考可靠性,對於為 Kubernetes 工作負載與平台本身建立監控、告警與 SLO 至關重要。

8. “Omega: flexible, scalable schedulers for large compute clusters” (2013)

摘要: Omega 是 Google 在 Borg 之後的下一代排程器設計。它採用共享狀態與樂觀併發控制,允許多個排程器並行運作。

核心概念: 共享狀態排程、優化併發控制、平行排程器、資源分配彈性、任務調度的可擴充性。

為什麼要讀: 雖然 Kubernetes 沒有完整實作 Omega 的架構,但理解這段演進能幫助你欣賞 Kubernetes 排程器的彈性與擴充機制。若你要實作自訂排程器或 scheduler extender,特別有用。

9. “Autopilot: workload autoscaling at Google” (2020)

摘要: Autopilot 描述 Google 自動調整工作負載資源 request/limit 的系統。它透過機器學習與垂直 Pod 自動擴縮(VPA)來最佳化資源使用率。

核心概念: 垂直 Pod 自動擴縮(VPA)、推薦系統、資源最佳化、記憶體與 CPU 的資源適配(rightsizing)、防止擾動的安全機制。

為什麼要讀: 資源管理是 Kubernetes 最難的維運挑戰之一。這篇論文展示 Google 如何解決資源過度配置與配置不足的問題,並直接對應到今天 Kubernetes 的 VPA 與相關自動擴縮功能。

10. “The Tail at Scale” (2013)

摘要: 這篇論文探討服務時間的變異(尾端延遲)在規模下如何成為重大問題,並提出降低延遲波動、提升整體反應速度的技術。

核心概念: 尾端延遲放大、對沖請求(hedged requests)、綁定請求(tied requests)、金絲雀請求(canary requests)、延遲觸發的觀察期(probation)、同步性擾動(synchronized disruption)。

為什麼要讀: 在 Kubernetes 上運行微服務時,尾端延遲足以毀掉使用者體驗。這篇論文教你設計更具韌性的服務網格、設定合理的逾時與重試策略,並理解分散式系統在負載下的行為 — 這些都是 SRE 工作的關鍵。

閱讀順序推薦

可以先從 Borg 論文(#5)與「Borg, Omega, and Kubernetes」(#6)開始,建立 Kubernetes 的來龍去脈。接著深入基礎設施論文(GFS、Bigtable、Chubby),理解儲存與協調的底層基礎。最後再讀 SRE 與營運相關的論文,學習如何在規模下可靠地運行這些系統。

每篇論文都代表著大規模生產環境累積多年的經驗。這些閱讀中的模式、反模式與取捨,能讓你避免重蹈大型企業的錯誤,也能把他們的成功經驗帶進你的 Kubernetes 與分散式系統工作中。

Eason Cao
Eason Cao Eason is an engineer working at FANNG and living in Europe. He was accredited as AWS Professional Solution Architect, AWS Professional DevOps Engineer and CNCF Certified Kubernetes Administrator. He started his Kubernetes journey in 2017 and enjoys solving real-world business problems.
comments powered by Disqus