作者：Bob Killen（CNCF）、Chris Short（AWS）、Frederico Mu?oz（SAS）、Kaslin Fields（Google）、Tim Bannister（The Scale Factory），以及全球每一位貢獻者。

十年前，即 2014 年 6 月 6 日，Kubernetes 的首個提交被推送到 GitHub。這份包含 250 個文件和 47,501 行 go、bash 和 markdown 的初始提交，開啟了我們如今擁有的項目。誰能預見，十年后，Kubernetes 將成長為迄今為止最大的開源項目之一，擁有超過 88,000 名來自 8,000 多家公司、遍及 44 個國家的貢獻者。

這一里程碑不僅屬于 Kubernetes，也屬于從中蓬勃發展的云原生生態系統。CNCF 內有近 200 個項目，240,000 多名個人貢獻者以及成千上萬的更廣泛生態系統的參與者。沒有他們，沒有 700 多萬開發者，以及更大的用戶社區，Kubernetes 不可能達到今天的地位。

Kubernetes 的起源 — 技術的融合

Kubernetes 背后的理念遠早于首次提交，甚至早于 2013 年的第一個原型。在 2000 年代初，摩爾定律正全面生效。計算硬件以驚人的速度變得越來越強大。相應地，應用程序變得越來越復雜。硬件商品化與應用復雜性的結合指出了進一步抽象軟件與硬件的需求，解決方案開始出現。

像當時許多公司一樣，Google 正在迅速擴展，其工程師對在 Linux 內核中創建隔離形式的想法感興趣。2006 年，Google 工程師 Rohit Seth 在一封郵件中描述了這個概念：

我們使用容器這個詞來表示一種結構，用于追蹤和收費工作負載如內存、任務等系統資源的使用。

Google 的大規模應用編排管理系統 Borg 在 2000 年代中期采用了 Linux 容器。此后，公司還開始研發名為“Omega”的系統新版本。熟悉 Borg 和 Omega 系統的 Google 工程師看到了 Docker 推動的容器化流行趨勢。他們不僅認識到開源容器編排系統的需求，而且正如 Brendan Burns 在這篇博客文章[1]中所述，這是“不可避免”的。2013 年秋天的這一認識激發了一個小團隊開始著手一個項目，后來成為 Kubernetes。該團隊包括 Joe Beda、Brendan Burns、Craig McLuckie、Ville Aikas、Tim Hockin、Dawn Chen、Brian Grant 和 Daniel Smith。

2013 年 3 月，Solomon Hykes 在 PyCon 上進行了一個 5 分鐘的閃電演講，題為“Linux 容器的未來”，介紹了即將推出的名為“Docker”的開源工具，用于創建和使用 Linux 容器。Docker 為 Linux 容器引入了一種可用性水平，使其比以往任何時候都更容易為更多用戶所用，Docker 的普及，從而 Linux 容器的普及，一飛沖天。隨著 Docker 讓 Linux 容器的抽象變得人人皆可訪問，以更加便攜和可重復的方式運行應用程序突然間成為了可能，但規模問題仍然存在。

Kubernetes 的十年歷程

Kubernetes 的歷史始于 2014 年 6 月 6 日的那次歷史性提交，隨后是 Google 工程師 Eric Brewer 在 2014 年 DockerCon 的 6 月 10 日主題演講中宣布該項目（以及相應的 Google 博客）。

在接下來的一年里，主要來自 Google 和紅帽的小型貢獻者社區努力工作，最終在 2015 年 7 月 21 日發布了 1.0 版本。與 1.0 版同時，Google 宣布 Kubernetes 將捐贈給 Linux 基金會的一個新分支 —— 云原生計算基金會（CNCF）。

盡管達到了 1.0 版本，Kubernetes 項目仍然非常難以使用和理解。Kubernetes 貢獻者 Kelsey Hightower 特別注意到了項目的易用性不足，并在 2016 年 7 月 7 日推送了他的著名“Kubernetes the Hard Way”指南的第一個提交。

自最初 1.0 版本發布以來，項目發生了巨大變化；經歷了一系列重大勝利，例如自定義資源定義（CRD）在 1.16 中進入 GA 階段，或在 1.23 中推出完全雙棧支持，以及社區從 1.22 中移除廣泛使用的 Beta API 或 Dockershim 的棄用中學到的“教訓”。

自從 1.0 版本以來的一些重要更新、里程碑和事件包括：

• 2016 年 12 月 - Kubernetes 1.5 引入了運行時插件能力，包括初步的 CRI 支持和 Alpha 階段的 Windows 節點支持。OpenAPI 首次亮相，為客戶端發現擴展 API 鋪平道路。此版本還引入了 Beta 階段的 StatefulSets 和 PodDisruptionBudgets。
• 2017 年 4 月 — 引入基于角色的訪問控制（RBAC）。
• 2017 年 6 月 — 在 Kubernetes 1.7 中，第三方資源（“TPRs”）被 CustomResourceDefinitions（CRDs）取代。
• 2017 年 12 月 — Kubernetes 1.9 中，工作負載 API 成為 GA（General Availability）。發布博客指出：“Deployment 和 ReplicaSet，作為 Kubernetes 中最常用的對象，在經過一年的實際使用和反饋后，現在穩定下來。”
• 2018 年 12 月 — 在 1.13 版本中，容器存儲接口（CSI）達到 GA，用于引導最小可行集群的 kubeadm 工具達到 GA，CoreDNS 成為默認的 DNS 服務器。
• 2019 年 9 月 — Custom Resource Definitions 在 Kubernetes 1.16 中達到 GA。
• 2020 年 8 月 — Kubernetes 1.19 將版本支持窗口增加至 1 年。
• 2020 年 12 月 — Dockershim 在 1.20 中被廢棄。
• 2021 年 4 月 — Kubernetes 的發布節奏從每年 4 次改為每年 3 次。
• 2021 年 7 月 — 廣泛使用的 Beta APIs 在 Kubernetes 1.22 中被移除。
• 2022 年 5 月 — Kubernetes 1.24 中，Beta APIs 默認禁用以減少升級沖突，Dockershim 的移除導致用戶廣泛困惑（我們已經改進了溝通！）
• 2022 年 12 月 — 在 1.26 中，批處理和 Job API 進行了重大改造，為 AI/ML/批處理工作負載提供更好支持。

PS: 想親眼看看項目已經走了多遠？查看由社區成員 Carlos Santana、Amim Moises Salum Knabben 和 James Spurin 創建的教程，學習如何啟動一個 Kubernetes 1.0 集群[2]。

Kubernetes 提供了數不清的擴展點。最初設計只與 Docker 兼容，現在可以插入任何遵循 CRI 標準的容器運行時。還有其他類似的接口：CSI 用于存儲，CNI 用于網絡。而這遠非全部。在過去十年，出現了全新的模式，比如使用 Custom Resource Definitions（CRDs）來支持第三方控制器——現在是 Kubernetes 生態系統的重要組成部分。

構建項目的社區在過去十年中也大幅擴展。通過 DevStats，我們可以看到過去十年中令人難以置信的貢獻量，使 Kubernetes 成為世界第二大開源項目：

• 88,474 位貢獻者
• 15,121 位代碼提交者
• 4,228,347 次貢獻
• 158,530 個問題
• 311,787 個拉取請求

Kubernetes 現狀

從早期開始，項目在技術能力、使用和貢獻方面都經歷了巨大增長。項目仍在積極工作，以改進并更好地服務其用戶。

在即將到來的 1.31 版本中，項目將慶祝一個重要長期項目的完成：刪除內置云提供商代碼。在這次 Kubernetes 歷史上最大的遷移中，大約 150 萬行代碼被移除，核心組件的二進制大小減少了約 40%。在項目早期，很明顯，可擴展性是成功的關鍵。然而，如何實現這種可擴展性并不總是清晰的。這次遷移從核心 Kubernetes 代碼庫中移除了各種供應商特定功能。供應商特定功能現在可以通過其他可插拔的擴展特性或模式更好地提供，比如 Custom Resource Definitions（CRDs）或像 Gateway API 這樣的 API 標準。Kubernetes 也面臨著為龐大用戶群服務的新挑戰，社區正在相應調整。一個例子就是將鏡像托管遷移到新的、社區所有的 registry.k8s.io。為用戶提供預編譯二進制鏡像的出站帶寬和成本變得巨大。這項新的注冊表更改使社區能夠以更經濟高效和性能高效的方式繼續提供這些方便的鏡像。確保你閱讀博客文章[3]并更新任何自動化流程以使用 registry.k8s.io！

Kubernetes 的未來

十年過去了，Kubernetes 的未來依然光明。社區優先考慮既能改善用戶體驗又能增強項目可持續性的改變。應用程序開發的世界持續演變，Kubernetes 正準備隨之改變。

2024 年，人工智能的興起將曾經的小眾工作負載類型轉變為至關重要的需求。分布式計算和工作負載調度始終與人工智能、機器學習和高性能計算工作負載的資源密集型需求緊密相關。貢獻者密切關注新開發的工作負載需求以及 Kubernetes 如何最好地滿足它們。新的Serving 工作組[4]就是一個例子，說明社區如何組織起來應對這些工作負載的需求。很可能未來幾年我們將看到 Kubernetes 管理各種類型硬件的能力以及管理大批次風格工作負載調度的能力得到提升，這些工作負載是在硬件上分塊運行的。

圍繞 Kubernetes 的生態系統將繼續增長和進化。未來，維護項目可持續性的舉措，如內置供應商代碼的遷移和注冊表變更，將變得越來越重要。

Kubernetes 的下一個十年將由其用戶和生態系統指導，但最重要的是，由那些為之做出貢獻的人們引導。社區對新貢獻者開放。你可以在我們的新貢獻者指南中找到更多信息，網址是https://k8s.dev/contributors。

我們期待與你一起構建 Kubernetes 的未來！

參考資料

[1] 博客文章: https://kubernetes.io/blog/2018/07/20/the-history-of-kubernetes-the-community-behind-it/

[2] 學習如何啟動一個 Kubernetes 1.0 集群: https://github.com/spurin/kubernetes-v1.0-lab

[3] 博客文章: https://kubernetes.io/blog/2022/11/28/registry-k8s-io-faster-cheaper-ga/

[4] Serving 工作組: https://github.com/kubernetes/community/tree/master/wg-serving

點擊關注不迷路

今年4月時候派拉蒙曾宣布為紀念諾蘭的經典科幻電影《星際穿越》上映十周年，該片將在今年9月再次重返北美院線，其中更讓影迷們感到期待的是本次重映還包括了諾蘭偏愛的IMAX 70毫米的膠片版。

不過本次北美重映的計劃正在發生改變，今日稍早日期有多家外媒爆料本次重映可能將會被取消，原因本次重映的IMAX 70毫米的膠片拷貝早已被派拉蒙銷毀了，外媒甚至爆料其實早在2014年該片首映后派拉蒙便已銷毀了該版本的膠片。

該消息一出也是引起了不少影迷們的熱議，派拉蒙影業隨后也是緊急公關辟謠，派拉蒙影業表示該片的10周年紀念重映仍在推進，但是將推遲至12月6日，仍舊將以IMAX 70毫米格式為影迷呈現。

而根據派拉蒙內部人士的說法，網上傳言的膠片被毀純屬謠言，實際情況是因為膠片放映時間太長導致磨損，目前派拉蒙方面已經在做緊急的修復工作。

這部由諾蘭執導的科幻電影《星際穿越》在2014年正式登陸院線，該片主演包括了馬修·麥康納、安妮·海瑟薇、杰西卡·查斯坦、馬特·達蒙等，該片一經上映并大獲成功，影片當年在全球獲得7.3億美元的票房收入，更是在當屆的奧斯卡上獲得7項提名。

該片除了在上映當年登陸內地院線之外，還在2020年8月時在內地院線進行了一次重映，而本次不知道能否再次重返內地院線，畢竟還是有不少影迷們期待在電影院中再看一遍這部經典之作。

——END——

本文為湯老師看電影的原創

未經允許嚴禁轉載

喜歡的朋友記得點贊關注