跳到主要内容

Borg, Omega, and Kubernetes

Introduction​

Google從Borg，Omega，從這些內部系統的學到的經驗，最後決定Kubernetes的主要架構。

Containerization的好處​

  • 封裝環境，application不需要知道machine的環境和OS
  • 把Operating的焦點從machine-based轉移到application-based

封裝環境​

因為application的環境和dependency都封裝在container裡面，Google只需要運維少數的OS版本，所以只需要少數的人來maintain這些OS。

Machine-based to Application-based​

因為轉成container，monitoring、log等等都已container為單位，而不是已整個machine為單位，可以更清楚知道每個application的stats。

因為Orchestration而需要的相關功能​

  • Naming and service discovery
  • Master election
  • Application-aware load balancing
  • Horizontal and vertical autoscaling
  • Workflow tools
  • Monitoring tools
  • Rollout tools

架構思維​

Borg採用的是centeral monolithic的思維，由一個controller來處理所有的邏輯。Omega是分散式的思維，所有的component各行其是。Kubernetes採取中間的做法，各component各行其事，但有Common API和object-metadata structure來合作。

Google的經驗是，Omega和Kubernetes這種choreography的做法比較容易擴充，像Borg這種centralized ochestration設計上直覺，一開始也比較好開發，但後來比較難擴充。

Things to Avoid​

  • 不要由container system來管理port number
  • 不要把每個replica用數字或數目來管，用label來管理，才可以藉由label來target不同的container
  • 因為採用choreography的架構，要考慮ownership，避免一個controller去干擾其他controller
  • Choreography的架構，controllers透過state來決定自身要採取的行動，不過注意不要直接expose raw state，而是透過API access

Hard Problems​

Configuration​

為了不想hardcode跟config有關的邏輯在application裡面，configuration發展到最後可能支援一些運算，如果要發展到支援度很高，最後config language會turing complete，但不像programming language，這些語法缺少tool去debug，Google的經驗是把data和computation分開，computation還是透過programming language來負責。

Dependency Management​

會很希望container起來的時候，所有的depend services都能自動起來，但現實上有很多狀況，所以這方面目前還是一個open的問題，沒有好的解法。