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

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

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

API 才是核心

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

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

Kubernetes 的成功和價(jià)值在于，提供了一種標(biāo)準(zhǔn)的編程接口（API），可以用來編寫和使用軟件定義的基礎(chǔ)設(shè)施服務(wù)（本文所說的“基礎(chǔ)設(shè)施”，范圍要大于 IaaS）：

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

為了進(jìn)一步解釋這一點(diǎn)，考慮下 Kubernetes 出現(xiàn)之前的場景。

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

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

• 云廠商只提供了計(jì)算實(shí)例、塊存儲(chǔ)、虛擬網(wǎng)絡(luò)和對(duì)象存儲(chǔ)等基礎(chǔ)構(gòu)建模塊，開發(fā)者需要像拼圖一樣將它們拼出一個(gè)相對(duì)完整的基礎(chǔ)設(shè)施方案；
• 對(duì)于其他云廠商，重復(fù)過程 1，因?yàn)楦骷业?API、結(jié)構(gòu)和語義并不相同，甚至差異很大。

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

Kubernetes 面世：標(biāo)準(zhǔn)化、跨廠商的 API、結(jié)構(gòu)和語義

現(xiàn)在再來看 Kubernetes 從一開始就提供的東西：描述各種資源需求的標(biāo)準(zhǔn) API。例如：

• 描述 Pod、Container 等計(jì)算需求的 API；
• 描述 Service、Ingress 等虛擬網(wǎng)絡(luò)功能的 API；
• 描述 Volumes 之類的持久存儲(chǔ)的 API；
• 甚至還包括 Service Account 之類的服務(wù)身份的 API 等等。

這些 API 是跨公有云/私有云和各家云廠商的，各云廠商會(huì)將 Kubernetes 結(jié)構(gòu)和語義對(duì)接到它們各自的原生 API。因此我們可以說，Kubernetes 提供了一種管理軟件定義基礎(chǔ)設(shè)施（也就是云）的標(biāo)準(zhǔn)接口?；蛘哒f，Kubernetes 是一個(gè)針對(duì)云服務(wù)（Cloud Services）的標(biāo)準(zhǔn) API 框架。

Kubernetes API 擴(kuò)展：CRD

提供一套跨廠商的標(biāo)準(zhǔn)結(jié)構(gòu)和語義來聲明核心基礎(chǔ)設(shè)施（Pod/Service/Volume/ServiceAccount/……）， 是 Kubernetes 成功的基礎(chǔ)。在此基礎(chǔ)上，它又通過 CRD（Custom Resource Definition）， 將這個(gè)結(jié)構(gòu)擴(kuò)展到任何/所有基礎(chǔ)設(shè)施資源。

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

有了 CRD，用戶不僅能聲明 Kubernetes API 預(yù)定義的計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)服務(wù)，還能聲明數(shù)據(jù)庫、task runner、消息總線、數(shù)字證書……任何云廠商能想到的東西！

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

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

小結(jié)

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

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

因此，Kubernetes 并不是關(guān)于容器的，而是關(guān)于 API。