伴隨著云原生的發展，從早先的單機版 Docker 到 Kubernetes 的編排領域的一統江湖，再到云上托管 Kubernetes，技術風雨變化。今天我們就沿著歷史的脈絡，一起看一下 Serverless Kubernetes 的發展史。

故事，從 Docker 講起

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

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

IaaS：Infrastructure as a Service，基礎設施即服務，提供虛擬機或者其他基礎資源作為服務提供給用戶；

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

SaaS：Software as a Service，軟件即服務，將應用作為服務提供給用戶，譬如郵件服務。

如下圖所示，從 IaaS 到 PaaS，用戶（開發和運維）越來越少地感知基礎資源，更加關注到業務當中。

讓專業的人做專業的事情，從而發揮整體的最大效率。譬如一個初創的互聯網買菜公司，沒有必要自己去建機房、采購硬件、配置網絡存儲以及安裝操作系統等與業務無關的事情，更應該把精力放到業務的開發和運營上面。

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

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

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

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

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

Kubernetes 確定江湖地位

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

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

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

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

公有云托管 Kubernetes

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

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

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

將免運維和彈性進行到底

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

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

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

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

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

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

Virtaul Node 還可以與普通 ACK 節點混用，用戶可以將 long run 的任務調度到 ECS 節點上運行，然后利用 ECI 的快速啟動（10s 內拉起容器），將突發或者短周期任務調度到 ECI 上面，從而達到成本最優。

目前 ECI 已經被很多互聯網以及人工智能公司所采用。在后續的文章中，我們將逐步分享幾個典型用戶在遷移 ECI 過程中遇到的技術問題和挑戰。

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

本文節選自阿里云技術專家陳曉宇的《深度揭秘阿里云 Serverless Kubernetes》系列專題。本專欄將主要圍繞如何在 Serverless Kubernetes 場景中實現秒級擴容，以及在大規模并發啟動中遇到的各種技術挑戰、難點以及解決方案，系統地揭秘阿里云 Serverless Kubernetes 的發展、架構以及核心技術。

審核編輯 ：李倩