iT邦幫忙

第 12 屆 iT 邦幫忙鐵人賽

DAY 4
0
DevOps

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

Day 4 - Borg Omega and Kubernetes, 容器作為管理單位 (Container as the unit of management)

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

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

曬貓


Borg, Omega and Kubernetes

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

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


容器作為管理單位 (Container as the unit of management)

圍繞容器建構管理 API,而非圍繞機器,使得資料中心的「Primary key」從機器變成應用。帶來許多好處:

  1. 應用工程師與維運團隊 (operation team) 不需再煩惱機器與作業系統的細節
  2. 架構團隊 (infrastructure team) 獲得更多升版或是調度硬體的彈性,實際對應用與開發團隊的影響非常小
  3. 管理系統收集應用的監測數據 (例如 CPU 與 Memory 使用 metrics),而非機器的監測數據,直接提升應用的監測與自我檢查 (introspection),特別是擴展 (scale-up)、機器錯誤、或是維護時,造成應用移到其他位置時,監測依然可用。

Generic API

容器提供許多切入點給泛用 API (generic API),泛用 API 使資訊在管理系統與應用之間流動,但其實兩者互相不清楚對方的實作細節。

  • 在 Borg 中有一系列的 API 連結到所有容器,例如 /healthz 端點回報應用的健康程度給協調管理者 (orchestrator),當發現不健康的應用,自動終止並重啟應用。
  • 這個自動修復功能是可靠的分散式系統的基礎。(Kubernetes 也提供類似功能,透過 HTTP 端點或是 exec command 來檢查容器內部的應用)

容器提供、或是提供給容器的資訊,可以透過許多使用者介面呈現。

  • Borg 提供可以動態更新的文字狀態訊息,
  • Kubernetes 提供 key-value 的 annotation 存放在給個物件的 metadata,這些都能溝通應用。annotation 可以是容器自行設定、或是由管理系統設定 (例如滾動更新版本時標註新版本)。

容器管理系統可以取得容器內部訊息,例如資源使用狀況、容器的 metadata,並傳播給日誌 (logging) 或是監控 (monitoring),例如

  • 使用者名稱、
  • 監控任務名稱、
  • 用戶身分。甚至
  • 進一步在節點維護時,提早提供安全終止 (graceful-termination) 的警示。

容器有其他方式可以提供應用導向的監測,例如

  • Linux Kernel cgroups 會提供應用的資源使用率,
  • 這些資訊可以擴展,並將客製化的 metrics 構過 HTTP API 送出。
  • 基於這些資料,進一步開發出泛用工具如自動擴展 (auto-scaler) 與 cAdvisor,他們不需要知道應用的規格就可以記錄 metrics。
  • 由於容器本身是應用,因次不需要在實體或虛擬機器、與多個應用之間,做信號多工轉發或多路分配 (multiplex / demultiplex signals)。這樣更簡單、更堅固、並且可以產生精度更高的 metrics 與日誌,並提供更精細的控制操作。
  • 你可以對比使用 ssh 登入機器,並且使用 top 指令監測。雖然工程師可以 ssh 登入容器,但很少需要這樣做。

應用導向變遷在管理架構上產生更多回響,監測只是其中一個。

  • Google 的附載均衡器 (load balancer) 不再根據機器做附載均衡,而是根據應用實體 (application instances)。
  • 日誌會根據應用打上標籤 (key) 而不是機器,因此可以跨機器的收集所有相同應用的日誌,而不會影響其他的應用日誌或是影像作業系統。
  • 我們可以檢測應用失效,更容易的描述錯誤原因,不需要先拆解處理機器的各層信號。
  • 由於容器實體的身分資訊,從基礎上都是由容器管理系統控制,工程師可以明確的指定應用的執行身分,使得應用更容易建構、管理、除錯。

最後,雖然上述都針對容器與應用在一對一的狀況下,但實務上我們需要套裝的容器群 (nested containers),這群容器一起排程到相同機器上,最外層的容器提供資源,內層的容器提供部屬的隔離。

  • Borg 中,最外層容器叫做資源分配 (resource allocation or alloc),
  • 在 Kubernetes 上稱做 Pod。
  • Borg 允許最上層的應用直接跑在外層的 alloc 上,但這點產生了一些不便,所以這點在 Kubernetes 做了調整,
  • Kubernetes 的應用永遠跑在最外層 Pod 的內部,就算只有單一一個容器。

一個常見的使用情境,是一個 Pod 內部跑一個複雜的應用,

  • 大部分的應用都是一個一個子容器 (child containers),
  • 其他的子容器則執行輔助工具,例如 log rotation 或是將日誌移轉到分散式檔案系統。
  • 對比把上述功能都打包到 binary 執行檔中,拆分更容易讓不同團隊各自開發負責的功能,
  • 拆分還提供更好的耐用程度 (就算主要應用終止,子容器仍能成功將日誌移轉出去),
  • 更容易組裝應用 (composability) (由於每個服務都是獨立運作在各自的容器中,因此可以直接增加新的支援服務),
  • 提供更精細的資源隔離 (所有容器資源隔離,所以日誌服務不會搶占主要應用的資源,反之亦然)。

明日待續:容器管理應用,協調管理只是開始,而不是終點 (Orchestration is the beginning, not the end)


上一篇
Day 3 - Borg Omega and Kubernetes, Google 十餘年的容器化技術,應用導向的架構 (Application-oriented infrastructure)
下一篇
Day 5 - Borg Omega and Kubernetes,協調管理只是開始,而不是終點 (Orchestration is the beginning, not the end)
系列文
Kubernetes X DevOps X 從零開始導入工具 X 需求分析*從底層開始研究到懷疑人生的體悟*30

尚未有邦友留言

立即登入留言