伴隨著云原生的發(fā)展，從早先的單機版 Docker 到 Kubernetes 的編排領(lǐng)域的一統(tǒng)江湖，再到云上托管 Kubernetes，技術(shù)風(fēng)雨變化。今天我們就沿著歷史的脈絡(luò)，一起看一下 Serverless Kubernetes 的發(fā)展史。

故事，從 Docker 講起

故事雖然從 Docker 講起，但我們不能忽視了 IaaS 先輩們在前面的披荊斬棘，以及云計算大佬們很早就確定的云計算發(fā)展規(guī)劃。

在十幾年前，先輩們從按照用戶使用（云平臺提供能力）維度，將云分為三層：

IaaS：Infrastructure as a Service，基礎(chǔ)設(shè)施即服務(wù)，提供虛擬機或者其他基礎(chǔ)資源作為服務(wù)提供給用戶；

PaaS：Platform as a Service，平臺即服務(wù)，將平臺作為服務(wù)提供給用戶，譬如在平臺中可以隨用隨取各種中間件服務(wù)；

SaaS：Software as a Service，軟件即服務(wù)，將應(yīng)用作為服務(wù)提供給用戶，譬如郵件服務(wù)。

如下圖所示，從 IaaS 到 PaaS，用戶（開發(fā)和運維）越來越少地感知基礎(chǔ)資源，更加關(guān)注到業(yè)務(wù)當(dāng)中。

讓專業(yè)的人做專業(yè)的事情，從而發(fā)揮整體的最大效率。譬如一個初創(chuàng)的互聯(lián)網(wǎng)買菜公司，沒有必要自己去建機房、采購硬件、配置網(wǎng)絡(luò)存儲以及安裝操作系統(tǒng)等與業(yè)務(wù)無關(guān)的事情，更應(yīng)該把精力放到業(yè)務(wù)的開發(fā)和運營上面。

經(jīng)過十幾年的發(fā)展，IaaS 已經(jīng)比較成熟，各種基礎(chǔ)資源，如 ECS、VPC、EBS 等已經(jīng)深入人心，但 PaaS 的發(fā)展卻非常緩慢。

早在 2008 年，Google 就推出了 App Engine 服務(wù)，想打造一個開發(fā)平臺，讓開發(fā)者只需要編寫業(yè)務(wù)代碼就可以在 App Engine 上面運行。這個思想過于超前，開發(fā)者還不能完全接受。除了公有云以外，開源社區(qū) PaaS 平臺也在左突右沖。其中，IBM 的 Cloud Foundry 和 Redhat 的 OpenShift 最為出名，他們都希望提供一個應(yīng)用快速發(fā)布的平臺，但也都是不溫不火，反而因為各種兼容問題越來越難使用。

直到 2013 年 Docker 的誕生，一個對開發(fā)者充分友好、一個命令可以拉起一個服務(wù)，并極致簡單的操作方式，讓 Docker 一下成為社區(qū)最受歡迎的開源項目之一。

Docker 的優(yōu)勢主要體現(xiàn)在：Docker 鏡像將應(yīng)該依賴的環(huán)境和應(yīng)用打包成一個壓縮文件，這個文件可以在任何安裝了 Docker 的機器上面直接運行，解決了應(yīng)用從開發(fā)、測試到生產(chǎn)各個環(huán)節(jié)部署問題，并且能夠保障環(huán)境的一致性。

Docker 的成功在于極致的簡單操作而非技術(shù)的創(chuàng)新，像 cgroup、namespace 這些技術(shù)早就加入內(nèi)核特性了。所以，Cloud Foundry 早先并沒有把 Docker 看做競爭對手，因為這些技術(shù)早就在 Cloud Foundry 上使用了。反而，Dcoker 鏡像這個無心插柳的功能，讓 Docker 真正實現(xiàn)了“Build once, Run anywhere”。

Kubernetes 確定江湖地位

最初的 Docker 是單機版本，面對大規(guī)模部署的場景時需要一套管理平臺，就像 OpenStack 管理 VM 一樣。

容器管理平臺初期也是百家爭鳴，譬如 Mesos、Swarm 等，但它們都沒有脫離 IaaS 固有思維，還是停留在把容器當(dāng)做虛擬機管理。直到 Kubernetes 的出現(xiàn)，才真正開始一統(tǒng)江湖。這里除了 Google 的背書以及脫胎于 Borg 的成熟架構(gòu)以外，更重要的是 Kubernetes 在誕生之初就已經(jīng)想好了容器如何管理（ Replica set）以及如何對外提供服務(wù)（Service）。

其中，最令人惋惜的就是 Docker 公司自家的管理系統(tǒng) Swarm。當(dāng)時的 Docker 雖然已經(jīng)斬落頭角，但 Docker 公司本身卻沒有實現(xiàn)盈利。于是公司推出了 Swarm 企業(yè)版，雖然 Swarm 后期也引入了很多 Kubernetes 的概念，但無奈大勢已去，云原生的生態(tài)已經(jīng)圍繞 Kubernetes 蓬勃發(fā)展。

Kubernetes 雖然由 Google 主導(dǎo)，但卻保持了足夠的開放性，將資源的管理抽象出接口規(guī)范，譬如針對容器運行時的 CRI、針對網(wǎng)絡(luò)的 CNI、針對存儲的 CSI，以及設(shè)備管理 Device Plugins 和各種準入控制、CRD 等。Kubernetes 正逐漸演變成云操作系統(tǒng)，各種云原生組件就是運行在這個操作系統(tǒng)之上的系統(tǒng)組件。

公有云托管 Kubernetes

雖然 Kubernetes 確定了領(lǐng)導(dǎo)地位，但 Kubernetes 的運維卻并非那么容易。在這種背景下，公有云嘗試紛紛推出了云上 Kubernetes 托管服務(wù)，比如國內(nèi)的阿里云在 2017 年就推出了托管 Master 的方案：ACK（Alibaba Cloud Container Service for Kubernetes）。

在 ACK 中，Kubernetes 管理組件的安裝和運維托管給公有云，使用 ECS 或者裸金屬作為 Kubernetes 的計算節(jié)點，極大地減少了 Kubernetes 用戶的使用成本。用戶從云平臺獲取一個 kubeconfig 文件便可以直接通過 kubectl 命令行或者 Restful API 管理集群。

如果需要擴容集群容量，只需要調(diào)整 ECS 個數(shù)，新創(chuàng)建的 ECS 會自動注冊到 Kubernetes Master。不僅如此，ACK 還支持一鍵升級集群版本和各種插件。ACK 將繁雜的運維工作轉(zhuǎn)移到云上，并且借助云的彈性能力，可以做到分鐘級別的資源擴展。

將免運維和彈性進行到底

公有云相對私有云更加關(guān)注成本，因為在私有云中，用戶的基礎(chǔ)設(shè)施成本基本是固定的，用戶不可能下線一個服務(wù)后去機房停一臺服務(wù)器。與之相反，公有云則提供了按量付費的模式。

如果集群里面運行任務(wù)大部分都是 long run 并且資源需求是固定的任務(wù)，使用 ACK 沒有問題，但如果是大量 job 類型的任務(wù)或者存在突發(fā)流量的情況，ACK 這種臨時擴容虛擬機在虛擬機上啟用容器方案在彈性方面有所欠缺。

比如某在線教育公司，每天晚上 7-9 點上課高峰期會臨時擴容幾萬個 Pod，如果使用 ACK 就需要預(yù)先評估這些 Pod 的容量，然后再折算成 ECS 的算力，提前購買對應(yīng)數(shù)量的計算節(jié)點加入到 Kubernetes 里面，并且還需要在 9 點之后將這些 ECS 釋放掉，操作非常繁瑣。

那么，有沒有一種既能兼容 Kubernetes 使用方式，又能夠秒級啟動 Pod，并且按照 Pod 維度計費（ACK 按照 Node 維度計費）的方案呢？

AWS 率先提出 Fargate，可以在沒有真實 Node 的情況下，以 Pod 的維度加入到 Kubernetes 集群。阿里云在 2018 年也推出了類似的產(chǎn)品 ECI（Elastic Container Instance），每個 ECI 就是一個 Pod，這不過這個 Pod 是托管在云上的。

Kubernetes 使用 ECI 有兩種方式 ：一種是 ASK（Alibaba Serverless Kubernetes），另一種是 ACK + Virtual Node 的方案。在 ASK 中，計算節(jié)點完全變成了 Virtaul Node。Virtaul Node 是一個虛擬的無限容量的計算節(jié)點，負責(zé) ECI 生命周期管理。Virtaul Node 會注冊到 Kubernetes 里面，對于 Kubernetes 來說，它就是一個普通的 Node 節(jié)點。用戶只需要提交原生的 Kubernetes Yaml 便可以創(chuàng)建出 Pod，完全兼容 Kubernetes 的使用。

Virtaul Node 還可以與普通 ACK 節(jié)點混用，用戶可以將 long run 的任務(wù)調(diào)度到 ECS 節(jié)點上運行，然后利用 ECI 的快速啟動（10s 內(nèi)拉起容器），將突發(fā)或者短周期任務(wù)調(diào)度到 ECI 上面，從而達到成本最優(yōu)。

目前 ECI 已經(jīng)被很多互聯(lián)網(wǎng)以及人工智能公司所采用。在后續(xù)的文章中，我們將逐步分享幾個典型用戶在遷移 ECI 過程中遇到的技術(shù)問題和挑戰(zhàn)。

總結(jié)一下，我們今天從技術(shù)發(fā)展的角度回顧了容器和 k8s 的發(fā)展歷程，可以看到公共技術(shù)正逐漸沉淀到底層，無論是 k8s 還是 ServiceMesh，都在分別嘗試將服務(wù)管理和流量管理下沉到基礎(chǔ)設(shè)施中。但這些組件本身也存在管理成本，所以演化出云上托管。未來，隨著技術(shù)的下沉，云計算提供的能力將不斷上移、提供更加全面和豐富能力，讓開發(fā)專注在業(yè)務(wù)之上。

本文節(jié)選自阿里云技術(shù)專家陳曉宇的《深度揭秘阿里云 Serverless Kubernetes》系列專題。本專欄將主要圍繞如何在 Serverless Kubernetes 場景中實現(xiàn)秒級擴容，以及在大規(guī)模并發(fā)啟動中遇到的各種技術(shù)挑戰(zhàn)、難點以及解決方案，系統(tǒng)地揭秘阿里云 Serverless Kubernetes 的發(fā)展、架構(gòu)以及核心技術(shù)。

審核編輯 ：李倩