本文已超過一年。較舊的文章可能包含過時的內容。請確認頁面中的資訊自發布以來是否已變得不正確。

Kubernetes 的歷史與社群幕後推手

作者：Brendan Burns (Microsoft) |

oscon award

對我來說，能夠回到波特蘭和 OSCON，與 Kubernetes 社群的成員一同站上舞台，並接受這個「最具影響力開源專案」獎項，真是意義非凡。才短短三年多前，我們才在同一個舞台上宣布 Kubernetes 1.0，並且這個專案加入了新成立的雲端原生運算基金會 (Cloud Native Computing Foundation)。

想到在這麼短的時間內我們走了多遠，以及看到這個專案如何塑造雲端運算的格局，簡直令人驚嘆。這項成功證明了這個令人驚嘆的開源社群的力量和貢獻。而我們這個遍布全球、積極參與的社群，每天所展現的熱情和高品質的貢獻，實在令人謙卑。

在本週於波特蘭舉行的一場聚會中，我有機會分享 Kubernetes 的過去、現在，以及對其未來的一些想法，所以我認為我應該將我所說的一些內容寫下來，給那些無法親自到場的人。

這一切始於 2013 年秋天，當時我們三個人：Craig McLuckie、Joe Beda 和我正在研究公有雲基礎架構。如果您回顧 2013 年的雲端世界，那與今天截然不同。命令式 bash 腳本才剛開始讓位於使用系統宣告式組態 IaaS。Netflix 正在普及不可變基礎架構的概念，但它是透過重量級完整 VM 映像來實現的。編排的概念，當然還有容器編排，存在於少數網際網路規模的公司中，但在雲端中並不存在，更不用說企業了。

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。

這個小組的最初目標是開發一個「最低可行協調器」。根據經驗，我們知道這樣一個協調器的基本功能集是

  • 複製，以部署應用程式的多個執行個體
  • 負載平衡和服務發現，以將流量路由到這些複製的容器
  • 基本健康檢查和修復，以確保自我修復系統
  • 排程，將多台機器分組到一個單一集區中，並將工作分配給它們

一路上，我們也花費了大量的時間來說服高階領導層，開源這個專案是一個好主意。我非常感謝 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 即服務之上的 Functions-as-a-Service。

Kubernetes 叢集本身正在透過自訂資源定義 (custom resource definitions) 進行擴展 (這是我在 2015 年從 OSCON 走到附近一家餐廳的路上首次向 Kelsey Hightower 描述的)，這些新資源允許叢集營運商啟用新的外掛程式功能，從而擴展和增強其使用者可以存取的 API。

透過將記錄和監控等核心功能嵌入到叢集本身中，並讓開發人員只需將其應用程式部署到叢集中即可利用這些服務，Kubernetes 降低了開發人員建置可擴展、可靠應用程式所需的學習門檻。

最後，Kubernetes 為表達分散式系統開發的模式和範例提供了一個新的通用詞彙。這個通用詞彙意味著我們可以更輕鬆地描述和討論建置分散式系統的常用方式，而且我們還可以建置這些系統的標準化、可重複使用的實作。這樣做的淨效應是更快地開發更高品質、更可靠的分散式系統。

看到 Kubernetes 從西雅圖三個人的腦海中的一個粗略想法，發展成為一種現象，重新引導了我們思考全球雲端原生開發的方式，真是令人驚嘆。這是一段令人驚嘆的旅程，但對我來說真正令人驚嘆的是，我認為我們才剛剛開始觸及 Kubernetes 將產生的影響的表面。感謝所有幫助我們走到這一步的人，並感謝所有將帶領我們走得更遠的人。

Brendan