回首 Kubernetes 發展，為什麼如此出色？

瞭解什麼是 Kubernetes 以及為什麼它對於可靠、可擴充套件的現代應用程式至關重要的初學者指南。

如果你在 IT 行業，你可能經常聽到“Kubernetes”這個名字(在希臘語中意為“飛行員”或“舵手”)。它所做的通常被稱為容器編排，儘管人們有時指出它也不是一個準確的術語。

那麼它到底是什麼?

Kubernetes 確實很受歡迎。根據 CNCF(雲原生計算基金會)釋出的《 2021 年第一季度_雲原生開發狀況報告》，全球有 680 萬雲原生開發者(其中 560 萬使用 Kubernetes，比上一年增長 67%)，執行著 1020 萬個容器。(我們稍後會解釋什麼是容器。)

CNCF 估計全球有 2680 萬開發人員，因此全球約有五分之一的開發人員目前正在使用 Kubernetes。

要了解 Kubernetes 究竟做了什麼以及為什麼它在現代系統操作中如此受歡迎，我們必須快速回顧一下歷史。

單體應用程式

在 2000 年代末，我曾短暫地擔任過 Java 工程師。我們擁有的應用程式都是單體應用程式：它們使用 JavaServer Faces 或 Struts 來呈現網頁，並使用 Spring 和 Hibernate 來查詢資料庫。一切都必須編譯成一個巨大的.war檔案才能在大型 Oracle 伺服器上執行。

在一個更大的專案中，我們有一個大約 30 人的團隊，分為系統分析師、Web 開發人員和服務開發人員。一切都在一開始就計劃好了。然後客戶決定在軟體中增加一個新的功能分支。我們實際上不得不在我們的架構中插眼，因為我們沒有時間修復它，這樣做會導致更多的錯誤和混亂。

顧名思義，一個單體應用程式就像一塊(巨大的)石頭，所有東西都緊密耦合在一個程式碼庫中。如果您有一個小型應用程式，這是一個合乎邏輯的選擇。但隨著專案規模的擴大，一切都開始失控。

一個稱為面向服務架構 (SOA)的概念，試圖透過模組化程式設計來解決這個問題：應用程式的後端與前端分離並拆分為單獨的 Web API(使用 SOAP，簡單物件訪問協議)。這至少使專案開發更容易。

微服務時代

維護一個龐大的單體應用程式的麻煩只是問題的一半：它們也難以擴充套件，或者增加服務量來處理更多的使用者和資料。當然，您可以部署更多伺服器並在它們前面應用負載均衡器/反向代理，但任何更改都會使整個服務中斷一段時間。

在最近的一篇文章中[2]，Mario Izquierdo 解釋了 Twitch 如何在 2010 年代初從 Ruby on Rails 單機應用程式切換到基於 Golang 的微服務架構以解決效能瓶頸。與 SOA 服務仍然是同一後端的一部分不同，微服務本身是獨立的迷你應用程式，通常與自己的資料庫配對。

具有諷刺意味的是，與 SOA 的 SOAP(簡單物件訪問協議)相比，最常見的微服務 API 之一 REST(表示狀態傳輸)也更容易實現且更具可擴充套件性。

現在擴充套件很容易，您只需按需增加微服務的數量。您還可以在一臺伺服器上執行多個微服務例項，因為它們需要的資源更少。

虛擬機器世界

下一個問題是很難在同一臺伺服器上執行不同的應用程式。因為您可能無法為每臺伺服器購買一種型別的應用程式。

例如：您有一個使用 Spring Boot (Java) 編寫的微服務和另一個使用 .NET Core 編寫的微服務。你有一個使用 React 構建的前端應用程式(它可能在 Node.js 中的伺服器上執行)。您甚至可能擁有執行 Flask (Python) 的機器學習服務。嘗試讓它們一起工作會很麻煩，尤其是在不同型別的伺服器上。

虛擬機器 (VM) ：機器級虛擬化，使用稱為hypervisor的模擬器來“模擬”同一臺物理機器上的多臺機器。每個虛擬機器都有自己的作業系統、記憶體和 CPU 資源。在 VM 中執行的任何內容都將與另一個 VM 中的應用程式完全分離。有許多雲平臺提供大規模的 VM 託管。

集裝箱化

虛擬機器很棒，但它們也需要大量資源並且啟動速度很慢。Docker 在 2013 年推廣的一個新概念 容器化就是一個解決方案。

Docker 容器實際上是輕量級 Linux 虛擬機器。不同之處在於容器透過容器執行時共享主機作業系統核心和記憶體，只有應用程式和檔案是分開的(作業系統級虛擬化)。容器啟動速度更快，需要的資源更少，因此您可以在同一臺機器上執行更多。

在IBM 於 2021 年進行的一項測試中[3]，具有四臺伺服器(16 x 2.1 GHz 核心和 128 GB 記憶體)的虛擬環境可以執行 8 個 VM 或 33 個容器。多麼大的不同!他們還嘗試比較 32 個虛擬機器與 33 個容器的年度運營成本。後者只需前者的 25%。

Twitch 的 Mario Izquierdo 在接下來的文章[4]中也提到了他們如何逐漸從 Amazon EC2(主機 VM)遷移到 AWS(容器)。被稱為“Tiny Bubbles”的容器化微服務分別由不同的團隊管理。

容器引擎使面向應用程式的基礎設施成為可能：每個容器都是一個包含一個應用程式的氣泡。管理容器本質上與管理應用程式相同。由於容器可以使用映象進行克隆和移植，因此您幾乎可以在任何地方隨意部署和擴充套件任何應用程式。

容器編排

容器比虛擬機器更容易管理，但當然，大規模手動管理任何東西並不容易。如果你必須執行 100 個微服務例項會發生什麼?您必須建立 100 次微服務嗎?你怎麼知道他們中有沒有掛掉的?數以萬計的容器呢?

Kubernetes：一個開源專案，正是為此目的而設計的，它來自谷歌內部管理系統 Borg (2003) 和 Omega (2013) 的 15 年經驗：

儘管對軟體容器的廣泛興趣是一個相對較新的現象，但在 Google，我們十多年來的三個容器管理系統已經大規模管理 Linux 容器十多年，並在那時構建了三個不同的容器管理系統。

Google 開發的第一個統一容器管理系統是我們內部稱為 Borg 的系統。它是為管理長期執行的服務和批處理作業而構建的 Omega 是 Borg 的後代，其驅動力是希望改進 Borg 生態系統的軟體工程。

谷歌開發的第三個容器管理系統是 Kubernetes。它是在外部開發人員對 Linux 容器越來越感興趣的世界中構思和開發的，而谷歌已經開發了一項不斷增長的銷售公共雲基礎設施的業務。

Borg：以星際迷航中虛構的外星種族命名，已經變得如此強大，以至於它已經在谷歌中以令人難以置信的規模運作：

Google 的 Borg 系統執行來自數千個不同應用程式的數十萬個作業，跨越多個叢集，每個叢集擁有多達數萬臺機器。

Kubernetes 1.0 於 2016 年釋出。它已被包括亞馬遜、微軟、谷歌、IBM、甲骨文和紅帽在內的眾多雲提供商廣泛採用。

我們在開頭提到，Kubernetes 所做的被描述為容器編排：它使容器操作自動化，類似於指揮一群音樂家的指揮。

Kubernetes 能做什麼在官方文件[5]中列出如下：

服務發現和負載均衡

儲存編排(新增任何本地或雲伺服器)

自動部署和回滾

自動分配 CPU/記憶體資源

自我修復(需要時啟動新容器)

Secret(安全相關資訊)和配置管理

Kubernetes 是一種宣告性工具：您不必自己執行容器。取而代之的是，您“宣告”一個部署清單(如運輸訂單)以指定在 Kubernetes 環境中執行的容器和數量。

Kubernetes 監控容器，如果其中任何一個崩潰，將建立新容器以匹配您的清單。CPU/記憶體資源是自動分配的。容器作為單個 API 端點繫結在一起。Kubernetes 還提供了自己的負載均衡器，因此您可以透過簡單地更改清單來擴充套件您的服務。

所以：Kubernetes 可以在幾乎沒有人為干預的情況下實現可靠、可擴充套件和自動化的容器操作。它還可以部署在多個物理或虛擬機器上，這些物理機或虛擬機器可以是雲提供商或任何地方的本地伺服器。它是現代資訊系統大規模管理的關鍵。

Kubernetes 也為開發者帶來了巨大的好處。部署在 Kubernetes 上的應用程式(不僅是微服務，還包括前端應用程式在內的任何應用程式)因其容器性質而具有“雲原生”特性，更容易透過簡單地更新清單來交換或升級。Kubernetes 可以在不停止服務的情況下執行滾動更新。

在雲原生開發狀況報告中，33% 的開發人員報告說他們可以每天釋出生產程式碼，31% 每週釋出。開發團隊現在可以保持競爭力，因為他們可以比其他公司更快地推出新功能。

Kubernetes 叢集的簡化概述

我們不會在本文中過於技術化，但讓我們看看 Kubernetes 叢集內部是什麼，它是部署的 Kubernetes 環境的基本單元(您的應用程式將部署在其中)。根據需要，您可能有多個叢集一起工作。一個叢集基本上有以下幾個部分：

控制平面——Kubernetes 叢集的大腦

工作節點——叢集資料平面中虛擬機器的物理節點

Pods — 每個 Pod 由一個或多個容器組成，這些容器在一個節點中共享相同的儲存和網路

Kubernetes 預設使用 Docker 容器引擎，儘管還有其他選項。

目前，您無需過多擔心控制平面或節點中的較小元件，它們是 Kubernetes 如何管理節點和 Pod 的較低階別的細節。

例如，kubelet是執行一個節點的代理，它就像一個向控制平面報告的組長(控制平面實際上是一個主節點的集合)。kube-proxy是每個節點的網路代理。etcd是控制平面本身的持久化資料庫，節點控制器和 pod 排程器也在控制平面中，依此類推。

Kubernetes 還允許您將自定義資源(CR) 新增到叢集中，該叢集的工作方式類似於 pod 或容器，但具有更大的靈活性。

Pokémon GO 的成功

Pokémon GO 是 GKE(Google Kubernete Engine)最早和最大的使用者之一。它在單個 Kubernetes 叢集中執行容器化的前端應用程式和各種微服務。遊戲公司 Niantic 只有一個小團隊。釋出時最差的估計使用者流量是原始估計的 5 倍。

然而到了 2016 年 7 月 6 日，遊戲在澳大利亞和紐西蘭上線後的 15 分鐘內，這個數字就飆升到了他們目標的50 倍。

Niantic 尋求 Google 的幫助。谷歌迅速將數千個節點新增到叢集中，這已經成為真正的行星規模。遊戲順利透過了萬眾矚目的次日美國上線和日本當月下旬上線(是美國上線的 3 倍)，數以萬計甚至數十萬玩家線上，每天 5~10TB 資料。

儘管 Niantic 沒想到會如此受歡迎，但由於遊戲的容器化設計以及將其部署在雲上的決定，它可以在很短的時間內擴大規模。在某些方面，你可以說他們有點預料到了意外。

今天，企業擁有具有數千個工作節點的叢集並不少見。Bayer Crop Science[6] 在 240,000 個 CPU 核心和 1.48 PiB 的 RAM 中執行一個包含 15,000 個節點(從 4,500 個節點叢集擴大)的叢集，以計算有前景的種子基因型。OpenAI[7]有一個 7,500 個節點叢集來訓練非常複雜的影像和文字 AI 模型。不一定是節點越多越好，但顯然是可以實現的。

Kubernetes 為現代系統帶來了非凡的可靠性和可擴充套件性，因此已成為成功的代名詞。

概括

Google 的 Kubernetes 是一個開源專案，用於可靠、可擴充套件的容器操作，並已大規模應用。

容器化是更輕鬆地部署和擴充套件應用程式(尤其是微服務)的方式。