時間回到 2013 年。當一條簡單的 docker run postgre 命令就能運行起 Postgre 這樣復雜的傳統(tǒng)服務時，開發(fā)者在震驚之余猶如受到天啟；以 Docker 為代表的實用容器技術的橫空出世，也預示著一扇通往敏捷基礎設施的大門即將打開。此后，一切都在往好的方向迅速發(fā)展：

• 越來越多的開發(fā)者開始采用容器作為一種標準構建和運行方式。
• 業(yè)界也意識到，很容易將這種封裝方式引入計算集群，通過 Kubernetes 或 Mesos 這樣的編排器來調度計算任務 —— 自此，容器便成為這些調度器最重要的 Workload 類型。

但本文將要說明，容器并非 Kubernetes 最重要、最有價值的地方，Kubernetes 也并非僅僅是一個更廣泛意義上的 Workload 調度器 —— 高效地調度不同類型的 Workload 只是 Kubernetes 提供的一種重要價值，但并不是它成功的原因。

API 才是核心

“等等 —— Kubernetes 只是一堆 API？”

“不好意思，一直都是！”

Kubernetes 的成功和價值在于，提供了一種標準的編程接口（API），可以用來編寫和使用軟件定義的基礎設施服務（本文所說的“基礎設施”，范圍要大于 IaaS）：

• Specification + Implementation 構成一個完整的 API 框架 —— 用于設計、實現和使用各種類型和規(guī)模的基礎設施服務；
• 這些 API 都基于相同的核心結構和語義：typed resources watched and reconciled by controllers （資源按類型劃分，控制器監(jiān)聽相應類型的資源，并將其實際 status 校準到 spec 里期望的狀態(tài)）。

為了進一步解釋這一點，考慮下 Kubernetes 出現之前的場景。

Kubernetes 之前：各自造輪子，封裝廠商 API 差異

Kubernetes 之前，基礎設施基本上是各種不同 API、格式和語義的“云”服務組成的大雜燴：

• 云廠商只提供了計算實例、塊存儲、虛擬網絡和對象存儲等基礎構建模塊，開發(fā)者需要像拼圖一樣將它們拼出一個相對完整的基礎設施方案；
• 對于其他云廠商，重復過程 1，因為各家的 API、結構和語義并不相同，甚至差異很大。

雖然 Terraform 等工具的出現，提供了一種跨廠商的通用格式，但原始的結構和語義仍然是五花八門的，—— 針對 AWS 編寫的 Terraform descriptor 是無法用到 Azure 的。

Kubernetes 面世：標準化、跨廠商的 API、結構和語義

現在再來看 Kubernetes 從一開始就提供的東西：描述各種資源需求的標準 API。例如：

• 描述 Pod、Container 等計算需求的 API；
• 描述 Service、Ingress 等虛擬網絡功能的 API；
• 描述 Volumes 之類的持久存儲的 API；
• 甚至還包括 Service Account 之類的服務身份的 API 等等。

這些 API 是跨公有云/私有云和各家云廠商的，各云廠商會將 Kubernetes 結構和語義對接到它們各自的原生 API。因此我們可以說，Kubernetes 提供了一種管理軟件定義基礎設施（也就是云）的標準接口?；蛘哒f，Kubernetes 是一個針對云服務（Cloud Services）的標準 API 框架。

Kubernetes API 擴展：CRD

提供一套跨廠商的標準結構和語義來聲明核心基礎設施（Pod/Service/Volume/ServiceAccount/……）， 是 Kubernetes 成功的基礎。在此基礎上，它又通過 CRD（Custom Resource Definition）， 將這個結構擴展到任何/所有基礎設施資源。

CRD 在 1.7 引入，允許云廠商和開發(fā)者自己的服務復用 Kubernetes 的 spec/impl 編程框架。

有了 CRD，用戶不僅能聲明 Kubernetes API 預定義的計算、存儲、網絡服務，還能聲明數據庫、task runner、消息總線、數字證書……任何云廠商能想到的東西！

Operator Framework 以及 SIG API Machinery 等項目的出現，提供了方便地創(chuàng)建和管理這些 CRD 的工具，最小化用戶工作量，最大程度實現標準化。

例如，Crossplane 之類的項目，將廠商資源 RDS 數據庫、SQS queue 資源映射到 Kubernetes API，就像核心 Kubernetes controller 一樣用自己的 controller 來管理網卡、磁盤等自定義資源。Google、RedHat 等 Kubernetes 發(fā)行商也在它們的基礎 Kubernetes 發(fā)行版中包含越來越多的自定義資源類型。

小結

我們說 Kubernetes 的核心是其 API 框架，但并不是說這套 API 框架就是完美的。事實上，后一點并不（非常）重要，因為 Kubernetes 模型已經成為一個事實標準：開發(fā)者理解它、大量工具主動與它對接、主流廠商也都已經原生支持它。用戶認可度、互操作性 經常比其他方面更能決定一個產品能否成功。

隨著 Kubernetes 資源模型越來越廣泛的傳播，現在已經能夠 用一組 Kubernetes 資源來描述一整個軟件定義計算環(huán)境。就像用 docker run 可以啟動單個程序一樣，用 kubectl apply -f 就能部署和運行一個分布式應用， 而無需關心是在私有云還是公有云以及具體哪家云廠商上，Kubernetes 的 API 框架已經屏蔽了這些細節(jié)。

因此，Kubernetes 并不是關于容器的，而是關于 API。