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

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

Borg, Omega and Kubernetes

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

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

其他困難的開放問題

多年的容器開發系統開發競豔，Google 仍然有一些問題還沒找到合適的答案，這裡分享一些問題，希望能帶來更多討論與解決方案。

設定 (configuration)

所有面對的問題中，與設定 (configuration) 有關的問題，產生最多的腦力激盪、文件、與許多程式碼。一組數值提供給應用，但不是直接寫死在程式碼中，我們可以就此寫一大篇些不完，但這邊先聚焦幾個重點。

第一，關於應用的設定，容器管理系統沒做，但已經有包羅萬象的實作，Borg 的歷史中包含：

• 範版 (boilerplate) 的精簡 (e.g. 針對不同工作負載，例如服務或是批次任務，提供預設的 task 重啟政策)
• 調整並驗證應用的參數與命令列標籤 (command-line flags)
• 實作 workaround 給還沒有的 API 抽象，例如 package 管理
• 應用的設定樣本程式庫
• 發布管理工具 (release management)
• 映象檔版本規格

為了與上述需求協作，設定管理系統最終產生一套針對特定領域 (domain-specific) 的設定語言，

• 最終變成 Turing 語言，為了在設定資料中進行運算 (e.g. 透過服務的 sharding 數量，還決定調整機器的 memory)，
• 這會造成一種難以理解的設定程式碼 (configuration is code)，
• 而這是應用工程師，透過消滅原始碼中寫死的參數，盡力避免的。
• 這點並沒有降低維運的複雜性，新的語言只是將設定的運算，從應用的程式語言中，移到另外一個新的特定語言，
• 而這個語言往往更缺乏開發工具、除錯工具、與測試框架。

Google 認為目前最有效的辦法，是接受一部分無法避免的程式設定，並且清楚的區分運算的程式與資料。

• 呈現資料的語言應該簡單清楚，例如 JSON 或是 YAML，
• 設定運算的邏輯則需要使用完整的程式語言，才有完整的語法、與好的工具。
• 這點可見於 Angular 前端框架，劃分 markup 資料與 JavaScript 運算邏輯。

依賴管理 (dependency management)

建立服務往往意味著建立一套相關服務 (監控、CI/CD、等等)，如果一個應用依賴其他應用，是否容器管理系統也能自動提供依賴的服務呢？

讓事情更複雜，啟動依賴服務往往不只是啟動新的副本，例如

• 服務啟動後還需要向使用者註冊 (例如 BigTable 服務)，
• 然後傳送身分認證、
• 權限認證、
• 以及其他中介服務的計價資訊。

沒有一個系統可以捕捉、管理、維護、或是暴露這樣的依賴系統資訊。所以開啟一個新服務時，用戶仍需要自己煩惱、部屬新服務仍然困難，而這往往進一步導致使用者沒有跟隨最佳實踐，進而降低服務的可靠性。

一個標準問題是，如果服務是手動提供的，跟上依賴服務更新會很困難。試圖自動化判斷 (e.g. 使用 tracing accesses) 失敗，因為無法取得判讀結果所需要的語法資訊。一個可能的解決方法，是要求應用列舉所有依賴的服務，並且透過架構控制，拒絕其他應用存取 (如同編譯時匯入的程式庫)。這樣可以讓容器管理系統提供自動化的環境設定、提供自動身分認證、並寫自動連接。

不幸的是，這樣描述、分析、使用依賴性的系統太過複雜，還沒被增加到主流的容器管理系統。我們希望有天 Kubernetes 能夠建立起類似的工具，但目前仍是一個尚未完成的挑戰。

結論

十年的經驗打掃容器管理系統，給了我們許多經驗，我們將其實作 Kubernetes 上，Kubernetes 的目的是透過容器，提升工程師的生產力，並減輕手動與自動管理系統的負擔，我們希望你也能加入拓展與探索的行列。

本系列結束。

公有雲省錢大作戰 - 我這邊有一批便宜的好 VM 打三折賣你，Preemptible / Spot Instance 先占節點實戰分享