Google

這是原文翻譯的太長不讀 (TL;DR) 版本。完整翻譯請見Borg Omega and Kubernetes 前世今生浩文完整翻譯 原文：https://storage.googleapis.com/pub-tools-public-publication-data/pdf/44843.pdf 前言 Borg 以前就有應用管理系統，那時還沒有 Linux control group Borg 是第一套統一的 container-management system Borg 仍被大規模的使用，有許多功能而且非常堅固 Omega 繼承 Borg 上成功的設計，並希望改進 Borg 的生態系 Kubernetes 開源 透過 REST API 溝通 client 應用開發導向，著重於開發者的需求，希望能簡單的部署複雜的系統 Container Google 使用 Container 來提昇 utilization 把 batch jobs 跟預留資源的服務 (user-facing app) 放在一起，使用閒置時的資源跑 batch job 現代 container 的定義是 runtime-isolation 與 image Application-oriented infrastructure container 使用久了，不只滿足 utilization 的需求 資料中心從機器導向變成應用導向 Container 封裝環境，把機器與 OS 的依賴抽象化 應用不依賴 部署流程 runtime infrastrcture Container scope 在應用上，專注在應用管理而不是機器管理 Application environment cgroup, chroot, namespace 原本的目的是為了保護應用，不被其他應用影響 混合使用可以在應用與 OS 間產生抽象層，解耦 app 與 OS 提供完全相同的部署環境，避免切換環境(ex. dev, prod)時造成環境差異 進一步把 app 的依賴程式也打包 image container 對 OS 唯一的依賴只剩 Linux kernel system-call interface 大幅增加 app 調度的彈性 然而有些 interface 仍附著 OS 上，ex socket, /prod, ioctl calls 希望透過 Open Container Initiative，清楚定義 interface 與抽象 直接的好處，少數幾種 OS 與 OS Version 就可以跑所有應用，新版本也不影響 Container as the unit of management 資料中心的重心，從管理機器變成管理應用 提供彈性給 infrastructure team 提供統一的架構 收集統一的 metrics Container 統一的介面，讓 management system (ex. k8s) 可以提供 generic APIs REST API, HTTP, /healthz, exec… 統一的 health check 介面，更方便的終止與重啟 一致性 容器提供統一的資訊，ex. status, text message, … 管理平台提供統一設定 (ex. resource limits) ，並進行 logging 與 monitoring 提供更精細的功能 ex. graceful-termination cgroups 提供 app 的資源使用資訊，而不需要知道 app spec，因為 contaier 本身即是 app 提供更簡單，卻更精細且堅固的 logging 與 monitoring 應用導向的 monitoring ，而不是機器導向的 monitoring 可以收集跨 OS 的 app 狀態，進行整合分析，而不會有 OS 不同造成的雜訊 更容易對應用除錯 nested contaiers resource allocation (aka. alloc in Borg, Pod in Kubernetes) Orchestration is the beginning, not the end 原本 Borg 只是要把 workload 分配到共用的機器上，來改善 utilization 結果發現可以做更多事情，來幫助開發與部署 Naming, service discovery Application-aware load balancing Rollout tool Workflow tool Monitoring tool 成功的工具被留下 然而工具都需要各自的 API，副作用是增加部署的複雜度到 Borg 的生態系 Kubernetese 試圖降低複雜度 提供一致的 API ex. ObjectMetadata, Specification, Status Object metadata 是全域共通的 Spec 與 Status 根據 Object 有所不同，但是概念是一致的 Spec 描述 desired state of object Status 提供 read-only 的 current state of object Uniform API 有許多好處 降低學習成本 可以使用 generic 的工具讓所有 workflow 使用 統一使用者的開發流程與開發經驗 Kubernetes 本身模組化，可以使用延伸模組 ex. pod API 讓使用者使用，kubernetes 內部使用，外部自動化工具也使用 使用者可以自己增加 customized API 如何達到 Uniform API decoupling API 切分 API 關注的面向，變成不同 components API. ex. replication controller 確保 desired 數量的 Pod 存在 autoscaler 關注在需求與使用的預測，然後控制 replication controller API higher-level 服務都共用相同的 basic API 切分 API 而外的好處 有關聯但是用途不同的 API 的內容與使用方式十分相似. ex. ReplicationController: 控制長時間運行的 containers 與其複本 DeamonSet: 每個機器上都跑一個 container Job: 一次性執行完畢的 container Common design patterns ex. reconciliation controller loop 在 Borg, Omega, Kubernetes 中大量使用 需求(desired state) 觀察現況(current state) 執行動作，收斂需求與現況(reconcile) loop 由於狀態是基於實際觀測產生，reconciliation loop 非常堅固，可以承受相當的 failure Kubernetes 設計為一連串的為服務系統，以及許多小型的 control loop 對比大型的 centralized orchestration system Things to avoid Google 開發過程中，也發現許多不該做的事情 ...