iT邦幫忙

第 12 屆 iT 邦幫忙鐵人賽

DAY 5
0
DevOps

Kubernetes X DevOps X 從零開始導入工具 X 需求分析*從底層開始研究到懷疑人生的體悟*系列 第 5

Day 5 - Borg Omega and Kubernetes,協調管理只是開始,而不是終點 (Orchestration is the beginning, not the end)

本文同步刊登於個人技術部落格,有興趣關注更多 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)


上一篇
Day 4 - Borg Omega and Kubernetes, 容器作為管理單位 (Container as the unit of management)
下一篇
Day 6 - Borg Omega and Kubernetes,Google 十餘年的容器化技術,前車之鑑 (Things to avoid)
系列文
Kubernetes X DevOps X 從零開始導入工具 X 需求分析*從底層開始研究到懷疑人生的體悟*30

尚未有邦友留言

立即登入留言