Kubernetes 的核心是API框架而非容器

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

　　越來越多的開發者開始採用容器作為一種標準構建和執行方式。

　　業界也意識到，很容易將這種封裝方式引入計算叢集，透過 Kubernetes 或 Mesos 這樣的編排器來排程計算任務 —— 自此，容器便成為這些排程器最重要的 Workload 型別。

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

　 　API 才是核心

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

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

　　Kubernetes 的成功和價值在於，提供了一種標準的程式設計介面（API），可以用來編寫和使用軟體定義的基礎設施服務（本文所說的“基礎設施”，範圍要大於 IaaS）：

　　Specification + Implementation 構成一個完整的 API 框架 —— 用於設計、實現和使用各種型別和規模的基礎設施服務；

　　這些 API 都基於相同的核心結構和語義：typed resources watched and reconciled by controllers （資源按型別劃分，控制器監聽相應型別的資源，並將其實際 status 校準到 spec 裡期望的狀態）。

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

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

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

　　雲廠商只提供了計算例項、塊儲存、虛擬網路和物件儲存等基礎構建模組，開發者需要像拼圖一樣將它們拼出一個相對完整的基礎設施方案；

　　對於其他雲廠商，重複過程 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 提供了一種管理軟體定義基礎設施（也就是雲）的標準介面。或者說，Kubernetes 是一個針對雲服務（Cloud Services）的標準 API 框架。

　　 Kubernetes API 擴充套件：CRD

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

　　CRD 在 1.7 引入，允許雲廠商和開發者自己的服務複用 Kubernetes 的 spec/impl 程式設計框架。

　　有了 CRD，使用者不僅能宣告 Kubernetes API 預定義的計算、儲存、網路服務，還能宣告資料庫、task runner、訊息匯流排、數字證書……任何雲廠商能想到的東西！

　　Operator Framework 以及 SIG API Machinery 等專案的出現，提供了方便地建立和管理這些 CRD 的工具，最小化使用者工作量，最大程度實現標準化。

　　例如，Crossplane 之類的專案，將廠商資源 RDS 資料庫、SQS queue 資源對映到 Kubernetes API，就像核心 Kubernetes controller 一樣用自己的 controller 來管理網路卡、磁碟等自定義資源。Google、RedHat 等 Kubernetes 發行商也在它們的基礎 Kubernetes 發行版中包含越來越多的自定義資源型別。

　　 小結

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

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

　　因此，Kubernetes 並不是關於容器的，而是關於 API。