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

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

Borg, Omega and Kubernetes

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

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

容器 (Containers)

回顧歷史，第一個容器只提供 root file system (透過 chroot)。

• FreeBSD jail 進一步延伸出額外的命名空間 (namespace) 例如 process ID。
• Solaris 大幅地探索相關的新功能。
• Linux control groups (cgroups) 吸收這些想法，直到今日仍持續開發。

容器提供資源隔離 (resource isolation)，Google 得以大幅提升資源使用率 (utilization) 超出當時產業平均值，例如

• Borg 使用容器，將批次暫時工作、與面對用戶需要注意延遲的應用，兩者放在同樣的物理機器上。
• 用戶應用需要預留更多額外的資源，來處理突然產生的負載高峰 (load spikes) 以及錯誤處理 (fail-over) ，
• 這些預留的資源常常都不會用到，可以轉讓批次工作使用。

容器提供的資源管理工具實現此類需求，kernel-level 的資源隔離也確保程序之間不會互相干擾。Google 開發 Borg 中，同時也提交新功能給 Linux 容器，來滿足上述的需求。

然而目前的隔離並不完整，如果 Linux kernel 不管理的資源，容器自然也無法隔離，例如

• level-3 的處理器快取 (level-3 processor cache) 與
• 記憶體帶寬 (memory bandwith)，
• 容器還需要增加一層安全保護層 (例如虛擬機器 Virtual Machine) 才能對付公有雲上出現的惡意行為。

現代的容器不只提供隔離機制，更提供映像檔 (image)，在這個檔案上建構容器的應用。Google 使用 Midas Package Manager (MPM) 來建構並部屬容器映像檔，隔離機制與 MPM package 的關係，可以對比 Docker daemon 與 Docker image registry。這個章節描述的「容器」同時包含兩個概念：隔離、映像檔。

應用導向的架構 (Application-oriented infrastructure)

隨著時間證明，容器不只能提供高階的資源使用率，容器化 (containerization) 使資料中心 (data center) 從原本機器導向 (machine-oriented) 變成應用導向 (application-oriented)，這個段落提供兩個例子：

• 容器封裝 (encapsulate) 應用的環境 (environment)，在機器與作業系統的細節上，增加一層抽象層，解藕兩件事情：應用開發、部屬到架構。
• 良好設計的容器與映像檔只專注在單一個應用，管理容器意味管理應用，而不是管理機器。這點差異使得管理的 API，從機器導向變成影用導向，大幅度的改善應用的部屬與監控。

應用的環境 (Application environment)

• 原本 kernel 內的 cgroup、chroot、與命名空間，是用來保護應用不被旁邊其他應用的雜訊影響。
• 將這些工具與容器映像檔一起使用，產生一層抽象層，分離應用、與底下的 (各種不同家的) 作業系統。
• 解藕映像檔與作業系統，進一步提供相同的環境給開發環境 (development) 與生產環境 (production)，降低環境間的不一致性造成的問題，最終提升開發的可靠程度、並加速開發的流程。

建構這層抽象的關鍵是，使用密閉的容器映象檔 (hermetic container image) ，將所有應用有關的依賴 (dependencies) 都打包，整包部屬到容器中。

• 正確執行的話，容器對外部的依賴只剩下 Linux kernel 系統調用介面 (system-call interface)。
• 這層介面大幅改善映象檔的部屬方便性 (protability)，但目前機制仍不完美，應用仍然暴露在某些作業系統的介面上，特別是
  • socket options、
  • /proc、以及
  • ioctl 的調用參數。

Google 希望透過推廣開放容器倡議 (Open Container Initiative) 來清楚界定，上述介面與容器的抽象層。

次外，容器提供的隔離與最小依賴，在 Google 證明非常有效，容器是 Google 架構上唯一的可執行單位 (runnable entity)，進一步使 Google 只提供少數的作業系統版本給所有機器，只需要少數的維護人員來負責管理版本。

密閉容器映想檔有很多方式達成，

• 在 Borg 建構映想檔時，應用的執行檔 (binary) 靜態連結到可用的程序庫 (library) 版本，程式庫在公司內部存放。
• 至此 Borg 容器映像檔還不是完全密閉，底下還有依賴一層基底映象檔 (base image)，直接事先安裝到機器上，而不是隨映像檔部屬，
• 基底映象檔包含通用工具例如 tar 與 libc 程式庫，因此更新基底映象檔仍會影響應用，偶爾會產生大麻煩。

現代的容器映像檔格式，如 Docker 與 ACI，都加強這層抽象、提供更緊密的封裝，移除特定作業系統的依賴性，並要求使用者在分享映象檔內容時，必須明確宣告。

今天只是講古，知道 Kubernetes 的前世今生。文章重點在後面 XD

明日待續：容器作為管理單位 (Container as the unit of management)，資料中心的轉型