本文同步刊登於個人技術部落格，有興趣關注更多 Kubernetes、DevOps 相關資源的讀者，請務必追蹤從零開始的軟體工程師之旅，喜歡的話幫我按讚分享、歡迎留言、或是許願想要看的文章。

如果有技術問題也可透過粉絲專頁 討論，技術方面諮詢免錢、需要動手做另計 XD。

Borg, Omega and Kubernetes

這是原文完整版本。好讀版請見 Borg Omega and Kubernetes 前世今生摘要

完整英文原文請見 Borg, Omega, and Kubernetes - Lessons learned from three containermanagement systems over a decade

協調管理只是開始，而不是終點 (Orchestration is the beginning, not the end)

Borg 的初衷只是分配不同的工作附載 (workload) 到相同的機器上，來提升資源使用率。然而 Borg 生態系中，支援系統的快速演化，表明容器管理系統本身只是一個起點：通往一個新的分散式系統開發與管理環境。許多新的系統在 Borg 上打造、嵌入 Borg、或是圍繞 Borg 打造，提升 Borg 的基本容器管理服務，底下是部分服務清單：

• 命名與服務發現 (Naming and service discovery) Borg Name Service (BNS)
• 主節點選舉 (master election) 使用 Chubby
• 應用感知的 (application-aware) 的負載均衡
• 自動水平擴展 (horizontal) 與垂直擴展 (vertical)
• 新的執行檔與設定檔的滾動升級工具 (rollout)
• 工作流程工具 (workflow) (例如在不同工作階段，執行多任務的分析 pipeline)
• 監控工具，可以收集容器資訊、整合統計、在 dashboard 上顯示、並可以觸發告警

這些服務都是用來處理開發團隊面臨的問題，Google 選出成功的服務並廣泛的應用，讓工程師工作更加輕鬆。

然而這些工具大多各自需要特別的 (idiosyncratic) API，例如需要知道檔案的位置，也需要 Borg 的深度整合。產生一個不好的副作用，就是部屬 Borg 生態系變得更複雜了。

Kubernetes 試圖降低這些複雜度，因此導入一致性設計的 API (consistent API)，例如每個 Kubernetes 物件都會有三個基礎內容：

• ObjectMetadata、
• Specification (Spec)、以及
• Status。

所有物件的 ObjectMetadata 都是一樣的，包含

• 物件的名稱、UID、物件的版本 (作為樂觀併發控制 optimistic concurrency control 時使用)、
• 標籤 (key-value label)。

Spec 與 Status 的內容因物件型別有所不同，但核心概念一致：

• Spec 是描述期望狀態 (desired state)，而
• Status 是紀錄物件的當前狀態 (current state)。

統一 API 帶來很多好處，從系統獲取資訊更加簡單：

• 所有物件都有相同的資訊，才可以開發所有物件都適用的泛用工具，而
• 這點更進一步，使工程師開發的使用體驗更加一致。

從 Borg 與 Omega 中的經驗學習，所以 Kubernetes 是一堆組合的區塊打造而成，使用者還可以自行擴展。有統一的 API 以及 object-metadata 結構讓這件事更簡單。例如

• Pod API 用戶可以使用、Kubernetes 內部元件也使用、
• 外部的自動化工具也使用。
• 一致性繼續延伸，Kubernetes 允許用戶動態增加客製化的 API，與 Kubernetes 核心的 API 一起工作。

一致性的促成也仰賴 Kubernetes 自身 API 的解藕。把各自元件的面向拆開，讓更高階的服務共享相同的底層基礎實作。例如

• 拆分 Kubernetes 副本控制器 (replication controller) 與水平自動擴展系統 (horizontal auto-scaling system)，
• 副本控制器確保一個腳色的 (ex. 前端網頁) 存在的數量符合期望的數量，
• 自動擴展器則基於副本控制器的功能，只單純調整 Pods 的期望狀態 (desired state)，而不需負責 Pod 的增減，
• 讓自動擴展器可以實作更多使用上的需求，例如預測使用，並可以忽略底下執行的實作細節。

API 解藕也讓許多關聯，但是不盡相同的元件構成近似。例如 Kubernetes 有三個形式的副本 Pod：

• ReplicationController：持續執行的容器副本 (例如 web server)
• DaemonSet：每個節點都有一個實體 (例如日誌收集器)
• Job：執行到工作完成的控制器，知道如何 (平行的) 啟動工作到結束工作

雖然有各自的執行政策 (policy) ，三個控制器都有相同的 Pod 物件，描述希望執行的容器。

一致性也仰賴 Kubernetes 內部元件的相同設計模式 (design patterns)。控制器調和迴圈 (reconciliation controller loop) 是 Borg、Omega、Kubernetes 都共享的設計理念，為了提升系統的彈性：

• 迴圈不斷比對期望狀態 (要求多少符合 label-selector 的 Pod 存在)、與實際狀態 (控制器實際觀察到的數量)，
• 然後控制器採取行動，盡量收斂 (converge) 實際狀況與期望狀況。
• 由於所有行動都基於觀察結果，而非一個狀態圖，調和迴圈更能承受錯誤、更能抵抗擾亂、更加堅固：當一個控制器出錯，只要重啟，就可以繼續上次中斷的工作。

Kubernetes 設計成一堆微服務 (microservice) 的組合，並透過各個小型的控制迴圈 (control loop)，來達成整體的編排結果 (choreography) 單一個期望的狀態，由各個分散的自動元件，協作達成。這個意識的設計選擇，對比中心化協調管理系統 (centralized orchestration)，後者更容易建構，但面對不可預期的錯誤與變更時，更顯脆弱與僵化。

明日待續：Google 十餘年的容器化技術，前車之鑑 (Things to avoid)