本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
Kubernetes 的歷史及其背後的社群
回到波特蘭和 OSCON,與 Kubernetes 社群成員一起站上舞臺,並接受最具影響力開源專案獎,這對我來說意義非凡。僅僅三年前,就在這個舞臺上,我們宣佈了 Kubernetes 1.0 版本,並將該專案新增到了新成立的雲原生計算基金會 (Cloud Native Computing Foundation)。
回想在如此短的時間內我們取得了多大的進步,以及這個專案如何塑造了雲計算格局,這簡直令人驚歎。這一成功證明了這個了不起的開源社群的力量和貢獻。我們全球各地無休止地投入和高質量貢獻的社群的日常熱情,令人無比謙卑。
恭喜 @kubernetesio 榮獲 #OSCON “最具影響力”獎!我非常自豪能成為這個偉大社群的一員!@CloudNativeFdn pic.twitter.com/5sRUYyefAK
— Jaice Singer DuMars (@jaydumars) 2018年7月19日
👏 恭喜 @kubernetesio 社群榮獲 #oscon 最具影響力獎,我們為你驕傲!pic.twitter.com/5ezDphi6J6
— CNCF (@CloudNativeFdn) 2018年7月19日
本週在波特蘭的一次聚會上,我有機會講述了 Kubernetes 的過去、現在以及對未來的展望,所以我想把我說的一些內容寫下來,以便那些未能親自到場的人瞭解。
這一切始於 2013 年秋天,我們三人:Craig McLuckie、Joe Beda 和我正在研究公共雲基礎設施。如果你回想 2013 年的雲計算世界,它與今天的情況大相徑庭。命令式 Bash 指令碼才剛剛開始讓位於使用系統對 IaaS 進行宣告式配置。Netflix 正在推廣不可變基礎設施的概念,但它是透過重量級完整虛擬機器映象來實現的。編排的概念,尤其是容器編排,存在於少數網際網路規模的公司中,但不在雲中,更不在企業中。
Docker 改變了這一切。透過推廣輕量級容器執行時並提供一種簡單的方式來打包、分發和部署應用程式到一臺機器上,Docker 工具和體驗普及了一種全新的雲原生應用程式打包和維護方法。如果不是 Docker 改變了雲開發者的視角,Kubernetes 根本就不會存在。
我想是 Joe 在 2013 年夏天第一次建議我們關注 Docker,當時 Craig、Joe 和我都在思考如何將雲原生應用程式體驗帶給更廣泛的受眾。對我們三人來說,這個新工具的含義立即顯而易見。我們知道它是雲原生基礎設施開發的關鍵組成部分。
但當我們思考時,同樣顯而易見的是,Docker 專注於單個機器,並不是一個完整的解決方案。雖然 Docker 在構建和打包單個容器並在單個機器上執行它們方面表現出色,但顯然需要一個編排器來跨機器叢集部署和管理大量容器。
當我們進一步思考時,Joe、Craig 和我越來越清楚,這樣的編排器不僅是必要的,而且是必然的,而且同樣必然的是,這個編排器將是開源的。這個認識在 2013 年秋末對我們來說變得清晰,因此開始了原型機的快速開發,然後是最終被稱為 Kubernetes 的系統。隨著 2013 年過渡到 2014 年,我們很幸運地加入了一些才華橫溢的開發者,包括 Ville Aikas、Tim Hockin、Dawn Chen、Brian Grant 和 Daniel Smith。
很高興看到 k8s 團隊成員獲得“最具影響力”獎。#oscon pic.twitter.com/D6mSIiDvsU
— Bridget Kromhout (@bridgetkromhout) 2018年7月19日
Kubernetes 榮獲 O'Reilly 最具影響力獎。感謝我們的貢獻者和使用者!pic.twitter.com/T6Co1wpsAh
— Brian Grant (@bgrant0607) 2018年7月19日
這個小團隊的最初目標是開發一個“最小可行編排器”。根據經驗,我們知道這種編排器的基本功能集是:
- 複製,用於部署應用程式的多個例項
- 負載均衡和服務發現,用於將流量路由到這些複製的容器
- 基本健康檢查和修復,以確保系統自愈
- 排程,將多臺機器分組到一個池中並將工作分配給它們
在此過程中,我們還花費了大量時間說服高層領導,將這個專案開源是個好主意。我非常感謝 Craig 撰寫了大量白皮書,也感謝 Eric Brewer 給予我們的早期且強烈的支援,以確保 Kubernetes 能夠面世。
2014 年 6 月 Kubernetes 釋出時,以上列表就是其基本功能集的總和。作為一個早期開源社群,我們花了一年時間構建、擴充套件、完善和修復這個最初的最小可行編排器,最終在 2015 年的 OSCON 上釋出了 1.0 版本。我們非常幸運,OpenShift 團隊很早就加入了我們,他們為專案提供了重要的工程和實際企業專業知識。沒有他們的視角和貢獻,我想我們今天就不會站在這裡。
三年後,Kubernetes 社群呈指數級增長,Kubernetes 已成為雲原生容器編排的代名詞。有超過 1700 人為 Kubernetes 做出貢獻,全球有超過 500 個 Kubernetes 聚會,超過 42000 名使用者加入了 #kubernetes-dev 頻道。更重要的是,我們建立的社群成功地跨越了地理、語言和公司界限。這是一個真正開放、積極參與和協作的社群,本身就是一個了不起的成就。非常感謝所有幫助它走到今天的人。因為你們,Kubernetes 在公共雲中成為一種商品。
但如果 Kubernetes 是一種商品,那麼未來會是怎樣?當然,核心程式碼庫將會有無盡的調整、修改和改進,這些將佔用我們未來幾年的時間,但 Kubernetes 真正的未來是基於這個新的、無處不在的平臺構建的應用程式和體驗。
Kubernetes 大大降低了構建新的開發者體驗的複雜性,並且已經開發或正在開發無數新的體驗,這些體驗在核心 Kubernetes 即服務之上提供了簡化或有針對性的開發者體驗,例如函式即服務。
Kubernetes 叢集本身正在透過自定義資源定義進行擴充套件(我曾在 2015 年從 OSCON 步行到附近一家餐館時首次向 Kelsey Hightower 描述過這些),這些新資源允許叢集操作員啟用新的外掛功能,從而擴充套件和增強其使用者可以訪問的 API。
透過在叢集本身嵌入日誌和監控等核心功能,並使開發人員能夠透過將應用程式部署到叢集中來簡單地利用這些服務,Kubernetes 降低了開發人員構建可擴充套件、可靠應用程式所需的學習成本。
最後,Kubernetes 為表達分散式系統開發的模式和正規化提供了一種新的通用詞彙。這種通用詞彙意味著我們可以更輕鬆地描述和討論構建分散式系統的常見方式,此外,我們還可以構建此類系統的標準化、可重用實現。其最終效果是更快地開發出更高質量、更可靠的分散式系統。
看到 Kubernetes 取得如此大的進步,從西雅圖三個人心中的一個粗略想法,發展成為一個重新定義了我們對全球雲原生開發方式的現象,這真是令人驚歎。這是一段美妙的旅程,但真正讓我驚歎的是,我認為我們現在才剛剛觸及 Kubernetes 將產生的影響的表面。感謝所有幫助我們走到今天的人,也感謝所有將帶領我們走得更遠的人。
Brendan