Kubernetes轉10：它如何在過去十年中指導雲本地計算 - 接下來是什麼

如果從技術領域中移除 Linux、雲端、容器或 Kubernetes，你會發現自己身處一個幾乎無法辨識的世界。Linux 是所有這些技術的基石；雲端為我們提供了存取其龐大資源和應用的途徑；容器為這些應用提供了居所；而 Kubernetes 則讓所有容器保持和諧。若移除其中任何一項，我們將被推回技術的更原始時代。

Kubernetes 尤其在過去十年中徹底重塑了雲原生計算的世界。慶祝其十週年，Kubernetes 是開源協作與創新的光輝典範。從其在 Google 的創始到成為容器編排的首選標準，它已經革命化了我們部署、管理和擴展應用的方式。

你無需僅憑我的說法。Pure Storage 最近的 2024 Kubernetes 專家之聲報告 發現，“未來五年內，80% 的新應用將建於雲原生平台上。” 就我個人而言，我很驚訝這個數字還不更高。

Kubernetes 對計算的影響

Kubernetes 從根本上改變了我們處理計算的方式。正如 Isovalent（一家基於 eBPF 的網絡、安全和可觀測性公司）的首席開源官 Liz Rice 向我解釋，Kubernetes 改變了我們對網絡和安全的方法：

Kubernetes 本質上是動態的。Pod 可以根據需求擴展或縮減，工作負載可以在不同機器上被調度和重新調度。因此，儘管 Kubernetes 工作負載之間的網絡使用 IP 數據包，IP 地址僅在短期內有意義，因為它們會在不同時間被不同工作負載重複使用。這意味著基於端口和 IP 地址識別流量的傳統網絡和安全工具已不再足夠。我們需要將短暫的 IP 地址映射到有意義的 Kubernetes 身份（如 Pod、服務、命名空間和節點）的工具。

讓我們回顧過去十年，看看 Kubernetes 從何開始，如何塑造了雲原生格局，以及未來可能會如何發展。

Kubernetes 的起源

Kubernetes 的故事始於 2010 年代初的 Google，當時工程師們正應對管理大規模容器化應用的挑戰。容器變得越來越重要，急需一個管理解決方案。

在 Google 內部，組織容器的意義已被充分理解。Google 早在 Docker 普及容器之前就已使用容器。當 Google 工程師 Craig McLuckie、Joe Beda 和 Brendan Burns 在 2013 年向當時的 Google 技術基礎設施負責人 Urs Hölzle 提出這個想法時，他回應道：“讓我搞清楚。你們想打造一個 Borg 任務調度器的外部版本。我們最重要的競爭優勢之一。我們甚至不對外談論的東西。而且，你們還想將它開源？”

是的，這正是他們想要的。最終，他們說服了 Hölzle 這是一個好主意。

McLuckie 解釋了他們的理由：

我們一直相信開源 Kubernetes 是正確的選擇，為項目帶來了許多好處。首先，反饋迴路幾乎是即時的——如果有問題或某功能不太好用，我們會立刻知道。但最重要的是，我們能與許多優秀的工程師合作，他們中許多人真正了解需要部署容器的企業需求。這是一個良性循環：優秀工程師的工作帶來了對項目的更多興趣，進而加速了改進和使用的速度。

2014 年 6 月初，在首屆 DockerCon 上，“容器編排戰爭”被點燃。Apache Mesos、Red Hat 的 GearD、Docker Libswarm、Facebook 的 Tupperware 和 Kubernetes 相繼發布。當時 Drone.io 的創始人 Brad Rydzewski 指出：“我在 #dockercon 學到的：每個人都正在打造自己的編排平台。真的。每個人。”

他沒說錯。更多的編排程序很快跟進。

即便在早期，我也相信 Kubernetes 會脫穎而出。它受到 Google 自 2003 年以來使用的 Borg 容器管理程序的啟發，使其擁有其他競爭者所缺乏的成熟度。

Kubernetes 迅速獲得了關注。其名稱 “Kubernetes” 來自希臘語，意為“舵手”或“領航員”，象徵其在引導容器化應用中的角色。Kubernetes 的標誌——一個七輻船舵，致敬了其 Borg 遺產及其最初的名稱 Seven of Nine（《星際迷航》中一個友好的 Borg），後因商標原因放棄了這個名字。

快速採用與社群成長

Kubernetes 的開源性質和強大的功能集使其迅速受到開發者和企業的青睞。到 2015 年，Kubernetes 達到 1.0 版本，Google 與 Linux 基金會合作成立了雲原生計算基金會（CNCF），以 Kubernetes 為其種子技術。這一舉措對於圍繞 Kubernetes 建立一個充滿活力的社群至關重要，促進了快速創新和廣泛採用。

雖然其他容器編排程序仍然存在，但 2017 年，Amazon Web Services（AWS）發布了 Elastic Container Service for Kubernetes（EKS），標誌著 Kubernetes 在雲原生世界的霸主地位。

與此同時，CNCF 培育了 Kubernetes 生態系統。如今，數百個雲原生程序依賴 Kubernetes。沒有哪個主要雲提供商不支援它。它已成為首選的容器編排平台。

轉型雲原生開發

Kubernetes 對雲原生開發的影響不可估量。它引入了部署和管理應用程序的新範式，讓開發者專注於編寫程式碼而非管理基礎設施。Kubernetes 抽象化了容器編排的複雜性，提供了自動化更新與回滾、自我修復和水平擴展等功能。

Kubernetes 的另一大優勢是其可移植性。部署在 Kubernetes 上的應用可以在任何雲提供商或本地基礎設施上運行，使其成為混合雲和多雲環境的理想選擇。這種靈活性對企業來說是一個遊戲規則改變者，讓他們避免了供應商鎖定並優化了雲策略。

多年來，Kubernetes 還催生了一個豐富的工具和項目生態系統，擴展了其能力。這些包括 Helm（Kubernetes 的套件管理器，簡化了應用部署和管理）和 Prometheus（Kubernetes 環境的強大監控和警報工具）。

Kubernetes 的崛起還催生了新的範式，如 GitOps，它利用 Git 作為聲明性基礎設施和應用管理的唯一真相來源。

Kubernetes 的未來

展望未來，Kubernetes 沒有任何放緩的跡象。該平台持續發展，定期新增新功能和改進。Kubernetes 社群正在探索簡化用戶體驗、提升安全性和增強可擴展性的方法。

Chainguard 共同創辦人暨 Kubernetes 創建者之一 Ville Aikas 觀察到：

我們擁有這個蓬勃發展的 CNCF 生態系統，這在為平台團隊提供多樣化的工具和基礎設施選項方面是一件美妙的事情。但我也認為這創造了许多選擇，必須在操作 Kubernetes 時做出決定——這個生態系統已經變得非常龐大。我一直覺得 Kubernetes 之所以如此受歡迎，其核心原因之一是其應用程式介面（API）非常簡單，使用它的認知負擔相對較低。隨著 Kubernetes 持續成熟，它需要以某種方式保持其心智模型的簡單性和 API 的可用性。

平衡 Kubernetes 和雲原生程式設計範式正變得越來越複雜。

Groundcover（一家基於 eBPF 的效能監控公司）的首席執行官兼共同創辦人 Shahar Azulay 指出：

Kubernetes 已證明其有效管理多樣化任務的能力，但其複雜性需要相當多的設置和持續維護。類似於 Linux 發展成為一個可靠的操作系統，我預期 Kubernetes 將轉型為一個更友好的抽象層。隨著 Kubernetes 採用持續增長十年之久，對效率和成本優化的需求變得越來越關鍵。

展望未來，Isovalent 的 Rice 補充道：

我們已經看到 Kubernetes 在混合環境中與傳統工作負載以及邊緣設備一起使用。Cilium 的願景是，應用程式開發者無需知道或關心他們想交互的服務運行在何處：連通性和安全性應全部在平台層處理。

另一個令人興奮的發展是 Kubernetes 與無伺服器計算的整合。像 Kubeless 和 Fission 這樣的項目正將無伺服器功能引入 Kubernetes，讓開發者在其現有 Kubernetes 叢集上構建和部署功能即服務（FaaS）。無伺服器與 Kubernetes 的融合有望為雲原生應用開啟新的可能性。

邊緣計算與 Kubernetes 也正攜手成長。隨著更多設備和應用移向邊緣，Kubernetes 正被適應以支援邊緣部署。Kubernetes 社群正在致力於 KubeEdge、MicroK8s 和 Red Hat Device Edge 等項目，以實現輕量、高效的 Kubernetes 叢集，這些叢集可在邊緣設備上運行。

Kubernetes 的未來一片光明。憑藉持續的創新和蓬勃的生態系統，Kubernetes 將在未來數年繼續塑造雲原生格局。為 Kubernetes 的下一個十年乾杯，充滿創新、協作和容器編排的卓越表現。