Borg Omega and Kubernetes TLDR 摘要翻譯

這是原文翻譯的太長不讀 (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 開發過程中,也發現許多不該做的事情

  • 不要使用 conainer system 來管理 port numbers
    • Borg 會指定 unique port number 給每個 container
      • 必須用其他方法取代 DNS
      • port 也不易嵌入 URL 中,要另外處理轉址
      • 需要而外的系統處理 ip:port
    • Kubernetes 選擇指派 IP 給 Pod
      • 可以直接使用常用 port (ex. 80,443)
      • 可以使用內部 DNS,使用一般常用的工具
      • 大部分公有雲都提供 networking underlays,達成 Ip-per-pod
      • 可以使用 DNS overlay 或是 L3 routing,來控制一台機器上的多個 IPs
  • 不要幫 container 編號,使用 label 來管理大量的 container
    • Borg 會幫 job 從 0 開始編號
      • 很直覺很直接,但稍後就後悔了
        • 如果 job 死了,重啟新的 job 在機器上後,還需要去找上個死掉的 job
        • task 中間會有很多洞 (死掉的 job)
        • 更新版本,要更新 jobs 時會依序重啟 jobs
        • 資料如果也是根據 index 做 sharding,重啟時要復原 index,不然會有資料遺失
    • Kubernetes 使用 label
      • 可以透過 label 管理一組 container
      • 一個 container 可使用多個 labels,更方便的調度
      • 需要的資訊打在 label 上 (ex. role assignments, work-partitioning, sharding…),更容易管理
  • 注意所有權
    • Borg 上,tasks 都綁定在 job 上,產生 job 也產生 tasks
      • 很直覺方便
      • 只剩下一種 group 控制機制
    • Kubernetes 的 pod-lifecycle management (ex. replication controller) 使用 label selector 來控制 pod
      • 可以彈性控制大量 pod
      • 可能有多個上層 controller 控制同一個 pod,要盡量避免這種情況
      • 好處是保留彈性的同時,可以很清楚界定管理的 pod,不會有 orphan / adapt pod
      • 透過 label 進行 service load balance
        • 如果 pod 有問題,可以變更 label,讓流量不要進來,但又保留 Pod debug
  • 不要暴露 raw state
    • Borgmaster 是 monolithic,可見所有的 API Operation
    • Omega 不是 centralized,只保留被動的資訊,使用 optimistic concurrent control
      • state 存到 client store,並基於 state 進行 operation
      • 所有 client 需要使用一樣的 client store library
    • Kubernetes 走中間
      • 所有 state 存取需要透過 centralized API server
      • client components 可以獨立運作

Some open, hard problems

  • configuration
  • dependency management
Che-Chia Chang
Che-Chia Chang
Site Reliability Engineer

My research interests include Site Reliability Engineering, DevOps, Container and Kubernetes.